大家什么时候会用 rebase?

› GitX

This topic created in 4445 days ago, the information mentioned may be changed or developed.

我是用 gitflow 的模式来开发, 每次都是从 develop 创建 branch A, B, C, 然后每个完成后单独合回到 develop

但是由于周期比较长, 比如 A 只用了一天完成, B 用了 1周, C 可能要好几个月, 会不会 B 和 C 合并之前用 rebase 一下比较好? 优点在哪里呢? 因为但我 merge B 和 C 回去的时候, 也没啥大问题.

rebase

develop

merge

8 replies • 1970-01-01 08:00:00 +08:00

Anran

Mar 17, 2014

这里有个不错的教程 http://pcottle.github.io/learnGitBranching/

tunetoystory

Mar 17, 2014

周期长的话 rebase 很难受吧，相当于先将 B, C 分支上的提交拿出来，将他们更新到 develop 的最新版，再将之前拿出的提交打上去，如果周期太长了，可能会有很多冲突，而且这个过程是不可逆的，rebase 之前先分一个备份分支出去。

skydiver

Mar 17, 2014 via Android

一直用rebase代替merge，感觉比merge干净一些

mcfog

Mar 17, 2014

你说的情景我的理解是应该A完成功能进dev，经过测试后发布，进master
B和C不定期无脑从master合并代码到自己的分支即可，包括A的新功能和期间可能的bugfix等

我的理解是rebase最大的用处是，如果A和B开发的功能异常耦合，各种改相同的文件(其实应该避免的)，那么B合A可能很痛苦，B上10个提交和A上3个提交各种冲突，这时候rebase可以温柔一点，一个个提交来解决冲突

lightening

Mar 17, 2014 via iPhone

Rebase against master 可以经常做的。
另外，每次合并到master前，用 rebase --interactive 该一个所有 commit，做到原子提交。

undeflife

Mar 17, 2014

@lightening 这个操作在master下 git merge --squash dev 更简单吧

xi_lin

Mar 18, 2014

rebase以后develop的树长得好看:)

lightening

Mar 30, 2014

@undeflife 我们不允许直接在 master 做任何修改。Master 只能在 github 上点 merge。