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

与 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.合并多个提交