我已经使用Git大约一年了，觉得它很棒，但我刚刚开始开发这个项目的第二个版本，并为它创建了一个新的分支。我有点纠结于如何最好地处理未来的事情。
我有两个分支，分别称为master10(用于v1)和master20(用于v2)。我一直在master10分支上修复v1中的bug，并开发master20的新东西。每当我做一个错误修复，我合并到v2检查master20和做git合并master10。到目前为止一切顺利。
然而，现在我在v1中做了一个我不想在v2中做的更改，但我想继续合并其他错误修复。我如何告诉Git跳过这个特定的提交(或一系列提交)，但我仍然想合并其他错误修复。
我以为我需要的是git rebase，但看了医生，我的头几乎爆炸了。
我想我想要的是一个类似于“git sync”命令的东西，它告诉git两个分支现在是同步的，将来只合并从这个同步点开始的提交。
感谢任何帮助。
当前回答
在这种情况下，您需要让git考虑您跳过的更改比您所做的更改更老，而不是恢复或选择。
So:
合并要跳过的提交之前的最后一次提交。当然，这将在之前合并所有提交。Git合并CCC 合并要跳过的提交。Git合并FFF—不提交 执行任何合并，取消执行所有更改，撤销所有更改。(也许对此有万无一失的命令，但我只是在UI中完成这部分-无论你知道怎么做) 完成空合并git merge—continue 合并提交后，你想跳过一个。Git合并源代码-分支头
在步骤4之后，git会认为你的分支比上次提交的要更新，因为你已经处理过它了(通过选择保留你的版本)。
其他回答
提交包括祖先。如果不合并先前的提交，就不能合并一次提交。
当然，你可以从中挑选。当你有一个处于维护模式的分支时，这是一个很好的流动。
在master10而不是master20中为你想要的更改创建第三个分支。始终将master10视为您的“master”，它是所有分支中最稳定的分支。所有其他分支都希望始终与之保持同步的分支。
你可以用git-cherry pick来表示:
git cherry-pick $(git merge-base HEAD origin/branch)..$(git rev-parse <offending-commit-hash>^)
git cherry-pick <offending-commit-hash>..$(git rev-parse origin/branch)
它会从当前HEAD和origin/branch的最后一次公共提交中选择所有的提交，直到提交被忽略(注意^告诉cherry-pick停止在该提交的父节点)。
第二个命令从< offense -commit-hash>和其余的origin/branch中选取所有内容。
请注意，如果需要跳过提交来合并其他补丁，可能仍然需要进行一些修补(git将停止选择并告诉您解决冲突)。
在这种情况下，您需要让git考虑您跳过的更改比您所做的更改更老，而不是恢复或选择。
So:
合并要跳过的提交之前的最后一次提交。当然，这将在之前合并所有提交。Git合并CCC 合并要跳过的提交。Git合并FFF—不提交 执行任何合并，取消执行所有更改，撤销所有更改。(也许对此有万无一失的命令，但我只是在UI中完成这部分-无论你知道怎么做) 完成空合并git merge—continue 合并提交后，你想跳过一个。Git合并源代码-分支头
在步骤4之后，git会认为你的分支比上次提交的要更新，因为你已经处理过它了(通过选择保留你的版本)。
一种对我的项目的广告，它基本上包装了@araqnid所描述的过程。
它是一种助手，引入以下GIT流程:
每天/每周都会有一个关于从维护分支到开发/主分支的待处理合并的通知 分支维护者检查状态并自己决定是否所有的提交都是必需的，然后要么阻止一些提交，要么让开发人员阻止他们自己。最后，维护部门合并到上游部门。
项目页面上的一句话:
Depending on the workflow it's possible to have maintenance or customer-specific branches along with the master branch. These branches are also called LTS branches. Oftentimes the hot fixes go into the branches where the bug was reported and then the commit is merged back into the master branch. General practice is to have all branches perfectly synchronized with the master, i.e. you want to see a clear delta between a particular branch and master to understand whether the master contains all features and bugfixes. However sometimes you don't want particular commits because they are customer-specific and shall not be visible by other users. Or your master branch diverged that much that it requires completely different approach to fix the issue, or even better, the problem is not anymore present there. Also in case of cherry-pick from master into the maintenance branch the resulting commit shall be blocked in master.
