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