cherry-pick工作后git如何合并?

内容来源于 Stack Overflow,并遵循CC BY-SA 3.0许可协议进行翻译与使用

  • 回答 (2)
  • 关注 (0)
  • 查看 (88)

有一个master分支。

然后我们创建一个newbranch

git checkout -b newbranch

并做出两项新的承诺newbranch委员会1委员会2

然后我们转到cherry-pick

git checkout master
git cherry-pick hash_of_commit1

调查gitk我们看到了委员会1而且它的樱桃选择版本有不同的哈希,所以从技术上讲,它们是两种不同的提交。

最后我们合并newbranchmaster:

git merge newbranch

GIT是否在合并时对提交的内容进行了明智的分析,并决定不应该应用两次更改,或者这些提交在内部被标记为链接在一起?

提问于
用户回答回答于

与SVN 1不同,Git不以增量格式存储提交,而是基于快照2,虽然SVN会尝试将每个合并的提交应用于修补程序,但Git通常能够处理此场景。

合并时,Git将尝试将两个头提交的快照合并到一个新的快照中。如果代码或文件的一部分在两个快照中是相同的,则Git不会碰它。

用户回答回答于

在git cherry-pick之后的git merge:避免重复的提交 想象一下,我们有主分支和分支b: o --- X < - 主 \ b1 --- b2 --- b3 --- b4 < - b 现在我们迫切需要master中的提交b1和b3,而不是b中的其余提交。所以我们要做的是签出主分支和樱桃挑选提交b1和b3: $ git checkout master $ git cherry-pick“b1的SHA” $ git cherry-pick“b3的SHA” 结果是: o --- X --- b1'--- b3'< - 主 \ b1 --- b2 --- b3 --- b4 < - b 假设我们对master进行了另一次提交,我们得到: o --- X --- b1'--- b3'--- Y < - 主 \ b1 --- b2 --- b3 --- b4 < - b 如果我们现在将分支b合并到主设备中: $ git merge b 我们会得到以下结果: o --- X --- b1'--- b3'--- Y --- M < - 主 \ / b1 ---- b2 ---- b3 ---- b4 < - b 这意味着b1和b3引入的更改会在历史记录中出现两次。为了避免这种情况,我们可以改变而不是合并: $ git rebase master b 这会产生: o --- X --- b1'--- b3'--- Y < - 主 \ b2 --- b4 < - b 最后: $ git checkout master $ git merge b 给我们: o --- X --- b1'--- b3'--- Y --- b2 --- b4 < - 主,b

扫码关注云+社区