小白专场: Merge the incoming changes into the current branc和Rebase the current branch on top of the ...

一 背景介绍

使用idea更新代码时，有2个选项，一个是Merge the incoming changes into the current branch， 另一个是Rebase the current branch on top of the incoming changes。由于是多人多分支开发，笔者经常用的是Rebase这个选项。也不知道为什么用这个，看着别人也是用这个，不懂为什么要用rebase，而不用merge；在后面介绍过程中，会涉及到git merge的使用，以及git rebase对应的黄金规则，优缺点等等，对于git merge的初步学习和深入理解还是很有必要的。

总之，新手用merge！
老手用rebase!
老手用rebase!
老手用rebase!

二 Merge the incoming changes into the current branch

merge这个命令我比较熟悉，就是合并分支，自己也经常用过。那我们就从merge介绍开始，然后在说rebase。
一般在开发过程中，具体的步骤如下（下面是一个简单说明）：
1 下载项目代码
git clone xxxx
2 新建一个自己的分支(dev)
git checkout -b dev
3 然后在自己本地进行开发测试

4 现在需要合并团队的最新代码（默认在master上）, 下面命令是把master的代码合并到dev上，如果有冲突就解决冲突。
git merge master
5 最后git push dev, 执行MR,即执行合并请求，master分支主人同意后，你的更新代码就上去了。

Merge the incoming changes into the current branch:
select this option to perform merge during the update. This is equivalent to running git fetch and then git merge, or git pull --no-rebase.

以上知识了解后，言归正传；下面开始正式介绍：

现在你在Feature分支，其他团队人员在main分支上进行开发，他们也会进行代码更新和commit等等操作。现在你开始merge main.

Main分支代码更新到你的分支了。
好处：merge 是非常好的，因为它是非破坏性的操作。现有的分支不会以任何方式改变。这避免了rebase(将在下面讨论)的所有潜在缺陷。
坏处：如果main分支是非常活跃的(即更新频繁)，这可能会污染你的featue分支, 因为提交的commit历史很多。虽然使用高级的git log选项可以缓解这个问题，但它会让其他开发人员难以理解项目的历史。

这个坏处比较难理解，笔者用实际例子说明：现在A项目有7个分支，每个分支的历史本来应该是不同的，因为不同的人在不同分支。
但是现在，项目历史特别乱,多个分支历史互相交叠，每个分支上历史基本上都是一样的（这就是merge的坏处）：

再来说一下rebase, 这个命令会始终把你最新的修改放到最前头。比如你对主branch进行rebase以后, 你的所有修改就会在主branch当前所有的修改之前。你会更有信心保证你的代码运行畅通无阻。通过你自己的测试以后, 你就可以放心的把代码合并到主的branch里面了。

三 Rebase the current branch on top of the incoming changes

关于git rebase，首先要知道的是，它解决的是与git merge相同的问题。这两个命令的设计目的都是将一个分支的更改合并到另一个分支——它们只是采用了不同的方式。
1 切换到feature分支
git checkout feature
2 合并main分支内容到feature
git rebase main

Rebase the current branch on top of the incoming changes:
select this option to perform rebase during the update. This is equivalent to running git fetch and then git rebase, or git pull --rebase (all local commits will be put on top of the updated upstream head).

The major benefit of rebasing is that you get a much cleaner project history.
First, it eliminates the unnecessary merge commits required by git merge. （历史信息少了）
Second, as you can see in the above diagram, rebasing also results in a perfectly linear project history—you can follow the tip of feature all the way to the beginning of the project without any forks. This makes it easier to navigate your project with commands like git log, git bisect, and gitk. （项目开发历史更线性，方便其他操作，如查看历史）
该命令会合并分支的commit历史，以达到简化历史信息的作用。

下面是关于如何平衡安全性和可追踪行介绍：
there are two trade-offs for this pristine commit history: safety and traceability.
If you don’t follow the Golden Rule of Rebasing, re-writing project history can be potentially catastrophic for your collaboration workflow. And, less importantly, rebasing loses the context provided by a merge commit—you can’t see when upstream changes were incorporated into the feature.（个人理解：使用rebase命令会合并其他分支的历史进入到feature分支，失去了合并前的上下文信息，可能会带来潜在的灾难，因为你不知道合并前，main分支的修改到底做了什么，因为一些信息被合并了（缩减了提交历史））

小节：

当我们开发一个功能时，可能会在本地有无数次commit，而实际上，你只想master分支上显示一次提交记录就好了，其他的提交记录并不想保留在你的master分支上，那么使用rebase吧，rebase可以将本地多次的commit合并成一个commit，还可以修改commit的描述等

四 rebase使用的黄金规则

The Golden Rule of Rebasing，即什么时候适合用rebase

The golden rule of git rebase is to never use it on public branches. 不要使用rebase 命令在公共分支。以下面这个图说明：

使用rebase 命令在公共分支后，细心的读者会发现（前后2张图对比），your main 分支在分支历史开头了，

参考文章