问题：
当多个人在同一个开发分支上工作的时候，会出现一些冗余的难以接受的历史记录
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
- git fetch
- git merge FETCH_HEAD
git pull --rebase
- git fetch
- git rebase FETCH_HEAD
仅仅是使用rebase 代替了合并
其他
大家对rebase操作敬而远之，大部分原因都是道听途说会有副作用。然后就把持着反正不用rebase也能好好活着的方针，继续避而不用。
就上面这种情况，我们来分析一下
小红哈希值变了，会有什么影响，先来个灵魂拷问
- 小红哈希值变的是哪几次提交？
- 推送到远端仓库了吗？
如上所示，小红哈希值变的是自己本地的2次提交，并未推送。
那么会有副作用吗？不会。
什么情况下会有副作用呢？
举个栗子：
呃。。。
简而言之就是不影响其他人的修改（不变更已推送到远程仓库的提交）都不会有副作用。
有副作用的情况会在后续系列更新。