git merge rebase cherry-pick分别什么时候用？一文解惑

一、git merge

1.使用

• 将分支切换到 master 上去：git checkout master
• 将分支 feature 合并到当前分支（即 master 分支）上：git merge feature

2.特点

• 只处理一次冲突
• 引入了一次合并的历史记录，合并后的所有 commit 会按照提交时间从旧到新排列

• 所有的过程信息更多，可能会提高之后查找问题的难度

二、git rebase

1.使用

与 git merge 一致，git rebase 的目的也是将一个分支的更改并入到另外一个分支中去。

• 执行 git rebase master 的操作，意味着让当前分支 feature 相对于 分支 master 进行变基
• 遇到冲突，进行对比的双方分别是 master 分支的最新内容和 feature 分支的第一次提交的内容。

• 在我们解决了冲突之后，需要执行 git rebase --continue 来继续变基的操作。
• 执行之后又遇到了冲突，这次是与 feature 分支的第二次提交进行对比出现的冲突，意味着我们需要多次解决同一个地方的冲突。

2.特点

• 改变当前分支从 master 上拉出分支的位置
• 没有多余的合并历史的记录，且合并后的 commit 顺序不一定按照 commit 的提交时间排列

• 可能会多次解决同一个地方的冲突（有 squash 来解决）
• 更清爽一些，master 分支上每个 commit 点都是相对独立完整的功能单元

3.交互模式

git rebase -i HEAD~4
复制代码

指定了对当前分支的最近四次提交进行操作。

中间红框内有一些命令，可以用来处理某次提交的，可以使用 squash 来将所有的 commit 合并成一次提交，编辑并保存之后会出现编辑提交的信息的提示，编辑提交即可。

4.git rebase和git merge的区别

• rebase 会把你当前分支的 commit 放到公共分支的最后面,所以叫变基。就好像你从公共分支又重新拉出来这个分支一样。
• 而 merge 会把公共分支和你当前的 commit 合并在一起，形成一个新的 commit 提交

优劣：

• git merge 优点是分支代码合并后不破坏原分支代码的提交记录，缺点是会产生额外的提交记录并进行两条分支的合并
• git rebase 优点是可以将对象分支的提交记录续道目标分支上，形成线性提交历史记录，review时更加直观

5.什么时候使用rebase

• 不能在一个共享的分支上进行git rebase操作

• • 因为往后放的这些 commit 都是新的,这样其他从这个公共分支拉出去的人，都需要再重新merge，导致提交记录混乱

如下图：

总结

• 合代码到公共分支上时用git merge
• 合代码到个人分支时用git rebase，形成线性提交历史记录

三、git cherry-pick

1.基本使用

• git cherry-pick 的使用场景就是将一个分支中的部分的提交合并到其他分支

git checkout master 
git cherry-pick  
复制代码

使用以上命令以后，这个提交将会处在master的最前面

2.合并多个提交

git cherry-pick       // 合并两个提交
git cherry-pick ..    // 合并从A到B两个提交中到所有提交，但不包含A
git cherry-pick ^..   // 合并从A到B两个提交中到所有提交，包含A
复制代码

3.pick以后产生了冲突

当执行了cherry-pick 命令如果有冲突，就会报冲突错误

git cherry-pick --continue  // 1. 解决完冲突以后，继续下一个 cherry-pick
git cherry-pick --abort   // 2. 如果不想解决冲突，要放弃合并，用此命令回到操作以前
git cherry-pick --quit   // 3. 不想解决冲突，放弃合并，且保持现有情况，不回到操作以前
复制代码

4.转移到另一个代码库

git remote add target git://gitUrl //添加一个远程仓库target
git fetch target                   //远程代码抓取到本地
git log target/master              //获取该提交的哈希值
复制代码

5.应用场景

想要合并某些内容，但又不想包含整个分支。这时用cherry-pick来合并单次提交