我已经使用Git大约一年了，觉得它很棒，但我刚刚开始开发这个项目的第二个版本，并为它创建了一个新的分支。我有点纠结于如何最好地处理未来的事情。
我有两个分支，分别称为master10(用于v1)和master20(用于v2)。我一直在master10分支上修复v1中的bug，并开发master20的新东西。每当我做一个错误修复，我合并到v2检查master20和做git合并master10。到目前为止一切顺利。
然而，现在我在v1中做了一个我不想在v2中做的更改，但我想继续合并其他错误修复。我如何告诉Git跳过这个特定的提交(或一系列提交)，但我仍然想合并其他错误修复。
我以为我需要的是git rebase，但看了医生，我的头几乎爆炸了。
我想我想要的是一个类似于“git sync”命令的东西，它告诉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.
其他回答
提交包括祖先。如果不合并先前的提交，就不能合并一次提交。
当然，你可以从中挑选。当你有一个处于维护模式的分支时，这是一个很好的流动。
恕我冒犯，最合乎逻辑的做法是合并所有内容，然后使用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
所以你的版本会比另一个版本持久。即使没有错误消息，您仍然可能“恢复”那些不想要的提交，因为它们可能有其他不冲突的更改，而您仍然不想要它们。
如果冲突不仅涉及“要忽略的”提交，那么您应该手动解决它们，并且可能必须在恢复期间再次解决它们。
听起来像是典型的“少不要手”案例。 https://git-scm.com/docs/git-cherry-pick 听起来就是这个意思
在master10而不是master20中为你想要的更改创建第三个分支。始终将master10视为您的“master”，它是所有分支中最稳定的分支。所有其他分支都希望始终与之保持同步的分支。
例如，如果你想合并分支“维护”上的大部分而不是所有的提交到“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中，这样就可以再次进行同步。
