当从 master 挑选到分支，然后从分支合并回 master 时，避免重复提交
我在 git 中有两个分支，master/ 和 1.7/。我使用cherry-pick 将一些修复从 master/ 反向移植到 1.7/ 中。 （我没有使用合并，因为我只想要一些更改。）：
$ git checkout 1.7
$ git cherry-pick -x <initial commit SHA>..<master change 2 SHA>
然后，我将 1.7/ 合并回 master/，因为我想要所有已进入 1.7/ 的更改（除了樱桃本身） ）合并回主线：
$ git checkout master
$ git merge 1.7
我的问题是，这会再次将樱桃精选（最初来自 master/）重新提交到 master/ 中：
$ git log --oneline
8ecfe22 Merge branch '1.7'
fe3a60d master change 2 (cherry picked from commit f5cca9296e45d5965a552c45551157ba
9c25f53 master change 1 (cherry picked from commit 8fae2a68a356f5b89faa8629b9a23b23
f5cca92 master change 2
8fae2a6 master change 1
ffa10bf initial commit
在我真正的存储库中，它甚至导致了合并冲突。
所以我的问题是，我可以避免这种情况（如果可以，如何避免）？
重现此行为的命令的完整列表：
$ git init
<create Dialog.js file>
$ git add Dialog.js
$ git commit -am "initial commit"
$ git branch 1.7
<edit Dialog.js file>
$ git commit -am "master change 1"
<edit Dialog.js file>
$ git commit -am "master change 2"
$ git log
$ git checkout 1.7
$ git cherry-pick -x <initial commit SHA>..<master change 2 SHA>
$ git checkout master
$ git merge 1.7
$ git log
I've got two branches in git, master/ and 1.7/. I backport some fixes from master/ into 1.7/, using cherry-pick. (I'm not using merge because I only want some of the changes.):
$ git checkout 1.7
$ git cherry-pick -x <initial commit SHA>..<master change 2 SHA>
Then later on, I merge 1.7/ back to master/, because I want all changes that have gone into 1.7/ (except for the cherry-picks themeselves) to be merged back to the mainline:
$ git checkout master
$ git merge 1.7
My problem is that this re-commits the cherry-picks (originally from master/) into master/ again:
$ git log --oneline
8ecfe22 Merge branch '1.7'
fe3a60d master change 2 (cherry picked from commit f5cca9296e45d5965a552c45551157ba
9c25f53 master change 1 (cherry picked from commit 8fae2a68a356f5b89faa8629b9a23b23
f5cca92 master change 2
8fae2a6 master change 1
ffa10bf initial commit
In my real repository it even caused merge conflicts.
So my question is, can I avoid this (and if so, how)?
The full list of commands to reproduce this behavior:
$ git init
<create Dialog.js file>
$ git add Dialog.js
$ git commit -am "initial commit"
$ git branch 1.7
<edit Dialog.js file>
$ git commit -am "master change 1"
<edit Dialog.js file>
$ git commit -am "master change 2"
$ git log
$ git checkout 1.7
$ git cherry-pick -x <initial commit SHA>..<master change 2 SHA>
$ git checkout master
$ git merge 1.7
$ git log
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
当你选择时，除非你使用快进选项
-ff，否则你正在创建新的提交，当你合并回来时，git必须合并这些提交，即使它们实际上可能是无-操作。在这里，Rebase 可能会帮助你，而不是合并：
然后现在，合并分支（如果需要）。
当你想从要丢弃的分支中获取小的更改时，最好使用 Cherry-pick。您的工作流程应基于适当的合并或变基。
When you cherry pick, unless you are using the fast forward option
-ff, you are creating new commits and when you merge back, git has to merge in those commits, even though they may effectively be no-ops.Rebase might help you here, instead of merge:
and then now, merge the branch ( if needed.)
Cherry-pick is used best when you want to get small changes from a branch that you are otherwise discarding. Your workflow should be based on merge or rebase as appropriate.