git代码合并，真是通俗易懂啊！

以下文章来源于李哥技术笔记 ，作者我是李同学

如有侵权，联系删除

在开发社区里，有许多关于merge和rebase的讨论。git rebase 这个命令经常被人认为是一种git巫术，初学者应该避而远之。但如果使用得当的话，它能给你的团队开发省去太多烦恼。

git merge

git使用merge进行分支合并主要有两种方式：fast-forward和no-fast-forward。

1.Fast Forward

Fast Forward意为“快进模式”。主要使用在多分支合并的情况下。即当前分支合并另一个分支的时候，如果合并的过程中没有conflict的时候，则会通过直接移动两个分支的指针，来达到合并的过程，这个过程就叫做Fast Forward。

如果当前的分支与要合并的分支相比没有任何额外的提交，我们使用merge时，git默认采用fast-forward，即将我们正在合并的分支上的提交合并到当前分支中，且不产生新的提交。

1(dev)$ git checkout main
2(main)$ git merge dev
3(main)$ git push origin main

2.no-fast-forward

如果当前的分支与要合并的分支相比有额外的提交，也就是说本地需要进行pull操作，那么git会通过no-fast-forward进行分支合并，并在活动分支上创建一个新的合并提交。提交的父提交同时指向活动分支和我们要合并的分支。

1(dev)$ git checkout main
2(main)$ git merge dev
3(main)$ git push origin main

1(dev)$ git checkout main
2(main)$ git merge dev
3解决冲突
4(main)$ git add .
5(main)$ git commit -m "message"
6(main)$ git push origin main

git rebase

与 merge 会保留修改内容的历史记录不同，rebase 是在原有提交的基础上将差异内容反映进去。git rebase会复制当前分支的所有提交，并移动当前分支到要合并分支的最新提交上，并改变当前分支所有提交的hash值（C3'）。

其实git rebase 和git merge 做的事是一样的。它们都被设计用来将一个分支的更改并入另一个分支，只不过方式有些不同。

merge vs rebase

merge:

• 优点：分支合并后，原分支会保留，较为安全，操作简单
• 缺点：会引入一次不必要的commit，如果团队庞大，提交树会变得杂乱无章

rebase:

• 优点：rebase会使项目提交树很干净，所有的提交都在一条线上
• 缺点：rebase后会改变commit的hash值，改变了提交树的历史

到底该使用 merge 还是 rebase 是有争议的。

有一种观点认为，仓库的提交历史是记录实际发生过什么，是针对历史的文档，本身就有价值，不能乱改。从这个角度看来，改变提交历史是一种亵渎，你使用谎言掩盖了实际发生过的事情。如果由合并产生的提交历史是一团糟怎么办？既然事实就是如此，那么这些痕迹就应该被保留下来，让后人能够查阅。

另一种观点则正好相反，他们认为提交历史是项目过程中发生的事。 没人会出版书的第一版草稿，软件维护手册也是需要反复修订才能方便使的。持这一观点的人会使用 rebase 及 filter-branch 等工具来编写故事，怎么方便后来的读者就怎么写。

总的原则是，只对尚未推送或分享给别人的本地修改执行变基操作清理历史，从不对已推送至别处的提交执行变基操作，这样，你才能享受到两种方式带来的便利。