我已经使用Git大约一年了，觉得它很棒，但我刚刚开始开发这个项目的第二个版本，并为它创建了一个新的分支。我有点纠结于如何最好地处理未来的事情。
我有两个分支，分别称为master10(用于v1)和master20(用于v2)。我一直在master10分支上修复v1中的bug，并开发master20的新东西。每当我做一个错误修复，我合并到v2检查master20和做git合并master10。到目前为止一切顺利。
然而，现在我在v1中做了一个我不想在v2中做的更改，但我想继续合并其他错误修复。我如何告诉Git跳过这个特定的提交(或一系列提交)，但我仍然想合并其他错误修复。
我以为我需要的是git rebase，但看了医生，我的头几乎爆炸了。
我想我想要的是一个类似于“git sync”命令的东西，它告诉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将停止选择并告诉您解决冲突)。
例如，如果你想合并分支“维护”上的大部分而不是所有的提交到“master”上，你可以这样做。这需要一些工作----如上所述，通常的用例是合并来自分支的所有内容——但有时发生的情况是，您对发布版本进行了更改，而不应该集成回去(也许该代码已经在master中被取代了)，那么您如何表示呢?这里是……
因此，让我们假设maint应用了5个更改，其中一个(maint~3)没有合并回master，尽管所有其他更改都应该合并。您可以分三个阶段完成此操作:合并之前的所有内容，告诉git将maint~3标记为已合并(即使它没有合并)，然后合并其余部分。神奇之处在于:
bash <master>$ git merge maint~4
bash <master>$ git merge -s ours maint~3
bash <master>$ git merge maint
第一个命令在您麻烦的维护提交到master之前合并所有内容。默认的合并日志消息将解释您正在合并“分支'maint'(早期部分)”。
The second command merges the troublesome maint~3 commit, but the "-s ours" option tells git to use a special "merge strategy" which, in fact, works by simply keeping the tree you are merging into and ignoring the commit(s) you are merging completely. But it does still make a new merge commit with HEAD and maint~3 as the parents, so the revision graph now says that maint~3 is merged. So in fact you probably want to use the -m option to git merge as well, to explain that that maint~3 commit is actually being ignored!
最后一个命令只是将其余的maint (maint~2..maint)合并到master中，这样就可以再次进行同步。
在master10而不是master20中为你想要的更改创建第三个分支。始终将master10视为您的“master”，它是所有分支中最稳定的分支。所有其他分支都希望始终与之保持同步的分支。
听起来像是典型的“少不要手”案例。 https://git-scm.com/docs/git-cherry-pick 听起来就是这个意思
恕我冒犯，最合乎逻辑的做法是合并所有内容，然后使用git revert (commit_you_dont_want)删除它。
例子:
git merge master
git revert 12345678
如果你有多个“to-ignore”提交，或者想编辑回复消息:
git merge master
git revert -n 123456
git revert -n abcdef
git commit -m "... Except commits 123456 and abcdef"
那么你的履历可能是这样的:
| ... Except 123456 and abcdef
|\ Merge branch 'master' into 'your_branch'
如果你的冲突只涉及这些“to-ignore”提交，你可以使用:
git merge master -X ours
所以你的版本会比另一个版本持久。即使没有错误消息，您仍然可能“恢复”那些不想要的提交，因为它们可能有其他不冲突的更改，而您仍然不想要它们。
如果冲突不仅涉及“要忽略的”提交，那么您应该手动解决它们，并且可能必须在恢复期间再次解决它们。
