git rebase or merge

https://segmentfault.com/a/1190000019455172

 

1 

在现实的开发过程中，严格禁止在公共分支上 rebase on 其他分支（譬如不允许在 master 分支上直接运行 git rebase branchname）。使用 merge 是最保险的合并分支方式，如果你对时间线清晰度要求不是那么高的话。但是如果你对时间线的清晰程度有比较高的要求，那么在合并分支的时候按第二种方法 rebase 就能帮助形成清晰的线性时间线，但是 rebase 的坏处是丢失了一部分提交操作历史。

$ git checkout feature
$ git rebase master
$ git checkout master
$ git merge feature

 

 

2

除了合并不同分支这种情况，还有一个十分常见的情况，多人在同一个分支上开发，如何保证同一条分支具有清晰的时间线。我们假设有三个人在开发 feature 分支，通常开发习惯是：

checkout feature 分支到本地。
开发，并把开发的内容提交到本地 feature。
使用 pull 把远程仓库中的 feature 和本地 feature 同步（pull 的默认方式是把远程的代码和本地代码做 merge 操作）。
push 同步完的 feature 分支到远程仓库。

因为 pull 默认是通过 merge 远程仓库和本地仓库实现同步的，所以每次 pull 都会多出一个提交记录。但是我们可以通过指定参数来指定 pull 的时候使用 rebase 策略：$ git pull --rebase。

通过图示我们看到，如果使用 pull 的 rebase 模式，那么多人协作同一个分支也可以做到时间线清晰。最后再通过之前提到的 rebase 方式把 feature 合并到 master 分支上。那么整个开发过程时间线就呈现出清晰的时间线。

 

3 总结

和远程仓库同步当前分支的时候使用 pull --rebase 的方式。
合并分支的使用 feature rebase on master，master merge feature 的方式。

 

4 实践

4.1 不同的人在不同的分支

 

 

4.2 不同的人在相同的分支

 

 

4.2.1 git pull 同一个分支，自动merge

 

4.2.2 git rebase后