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

问题：

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

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次提交，并未推送。

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

什么状况下会有反作用呢？

举个栗子：

呃。。。

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

有反作用的状况会在后续系列更新。