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

超、凢脫俗 2022-09-04 07:52 4阅读 0赞

# 一 背景介绍 #

使用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!**  
![在这里插入图片描述][a37e645361604cc1a4547feb78d78c3a.png]

# 二 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.

以上知识了解后，言归正传；下面开始正式介绍：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM5NDYzMTc1_size_16_color_FFFFFF_t_70]

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

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

再来说一下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).

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM5NDYzMTc1_size_16_color_FFFFFF_t_70 3]  
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 命令在公共分支。以下面这个图说明：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM5NDYzMTc1_size_16_color_FFFFFF_t_70 4]  
使用rebase 命令在公共分支后，细心的读者会发现（前后2张图对比），your main 分支在分支历史开头了，

[参考文章][Link 1]

[a37e645361604cc1a4547feb78d78c3a.png]: /images/20220829/e30deb7df1044d21a55e30a488c480de.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM5NDYzMTc1_size_16_color_FFFFFF_t_70]: /images/20220829/7a0a4230bdff44c08d9fd2473a893026.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM5NDYzMTc1_size_16_color_FFFFFF_t_70 1]: /images/20220829/199d10e741ed4291ab51e9ab0bc8ef0a.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM5NDYzMTc1_size_16_color_FFFFFF_t_70 2]: /images/20220829/3429d6185b324fd8998e22b5dc0f16c1.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM5NDYzMTc1_size_16_color_FFFFFF_t_70 3]: /images/20220829/39b91dc3e65e4d8f9de82d19eaefb212.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM5NDYzMTc1_size_16_color_FFFFFF_t_70 4]: /images/20220829/a8c336a1ee934f53ab7407d259edf2a4.png
[Link 1]: https://www.atlassian.com/git/tutorials/merging-vs-rebasing#the-golden-rule-of-rebasing