消除同一个分支中的合并记录（git pull --rebase）

2024年5月3日 223次阅读 来源: 小青虫

问题：

当多个人在同一个开发分支上工作的时候，会出现一些冗余的难以接受的历史记录

 Merge branch 'feature/x' of github.com:xxx/learn-git into feature/x

翻译过来就是把远程仓库分支feature/x合并到本地分支feature/x。

emmm…

大家都在一个分支，自己分支和自己分支有什么好合并的(远程分支和本地分支)？

那我们一起来看一下是什么操作造成了这种局面吧

问题重现

有一天公司需要开发一个新功能

开发人员是小明和小红

小明从master拉了一个分支出来，分支名是 feature/x

从此小明和小红共同在这个分支上愉快的开发。

有小改动 就通过git commit提交

小明推送前的日志是这样子的

* 2a68d81 (HEAD -> feature/x) 小明第三次提交
* 53b261a 小明第二次提交
* 71a5262 小明第一次提交
* 3021c2e (origin/master, origin/feature/x, master) first commit

小红推送前的日志是这样子的

* 0266f4f (HEAD -> feature/x) 小红第二次提交
* 260fa38 小红第一次提交
* 3021c2e (origin/master, origin/feature/x, origin/HEAD, master) first commit

小明率先推送了

小红改完也想推送了

这个时候远端已经更新了（小明的推送），所以小红想推送(push)必须先拉取代码（git pull ）

*   17771aa (HEAD -> feature/x) Merge branch 'feature/x' of github.com:zq741235/learn-git into feature/x
|\  
| * 2a68d81 (origin/feature/x) 小明第三次提交
| * 53b261a 小明第二次提交
| * 71a5262 小明第一次提交
* | 0266f4f 小红第二次提交
* | 260fa38 小红第一次提交
|/  
* 3021c2e (origin/master, origin/HEAD, master) first commit

（此处有点题），如何避免这种合并记录呢？

如果这个时候使用rebase 模式操作，就是另外一番景象了：

$ git pull --rebase

结果如下：

* 9cd6d58 (HEAD -> feature/x) 小红第二次提交
* 01cd7cf 小红第一次提交
* 2a68d81 (origin/feature/x) 小明第三次提交
* 53b261a 小明第二次提交
* 71a5262 小明第一次提交
* 3021c2e (origin/master, origin/HEAD, master) first commit

这两种方式有什么区别呢 ？

除了历史记录变成了一条直线，可以看见的区别就是小红提交记录的哈希值变了。

我们来看一下git pull 和git pull --rebase 有什么区别

git pull

  1. git fetch
  2. git merge FETCH_HEAD

git pull –rebase

  1. git fetch
  2. git rebase FETCH_HEAD

仅仅是使用rebase 代替了合并

其他

大家对rebase操作敬而远之，大部分原因都是道听途说会有副作用。然后就把持着反正不用rebase也能好好活着的方针，继续避而不用。

就上面这种情况，我们来分析一下

小红哈希值变了，会有什么影响，先来个灵魂拷问

  1. 小红哈希值变的是哪几次提交？
  2. 推送到远端仓库了吗？

如上所示，小红哈希值变的是自己本地的2次提交，并未推送。

那么会有副作用吗？不会。

什么情况下会有副作用呢？

举个栗子：

呃。。。

简而言之就是不影响其他人的修改（不变更已推送到远程仓库的提交）都不会有副作用。

有副作用的情况会在后续系列更新。

    原文作者：小青虫
    原文地址: https://segmentfault.com/a/1190000021004562
    本文转自网络文章，转载此文章仅为分享知识，如有侵权，请联系博主进行删除。
点赞