我已经使用Git大约一年了，觉得它很棒，但我刚刚开始开发这个项目的第二个版本，并为它创建了一个新的分支。我有点纠结于如何最好地处理未来的事情。
我有两个分支，分别称为master10(用于v1)和master20(用于v2)。我一直在master10分支上修复v1中的bug，并开发master20的新东西。每当我做一个错误修复，我合并到v2检查master20和做git合并master10。到目前为止一切顺利。
然而，现在我在v1中做了一个我不想在v2中做的更改，但我想继续合并其他错误修复。我如何告诉Git跳过这个特定的提交(或一系列提交)，但我仍然想合并其他错误修复。
我以为我需要的是git rebase，但看了医生，我的头几乎爆炸了。
我想我想要的是一个类似于“git sync”命令的东西，它告诉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 听起来就是这个意思
一种对我的项目的广告，它基本上包装了@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考虑您跳过的更改比您所做的更改更老，而不是恢复或选择。
So:
合并要跳过的提交之前的最后一次提交。当然，这将在之前合并所有提交。Git合并CCC 合并要跳过的提交。Git合并FFF—不提交 执行任何合并，取消执行所有更改，撤销所有更改。(也许对此有万无一失的命令，但我只是在UI中完成这部分-无论你知道怎么做) 完成空合并git merge—continue 合并提交后，你想跳过一个。Git合并源代码-分支头
在步骤4之后，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中，这样就可以再次进行同步。
