这是一个创建于 4363 天前的主题，其中的信息可能已经有所发展或是发生改变。
我是用 gitflow 的模式来开发, 每次都是从 develop 创建 branch A, B, C, 然后每个完成后单独合回到 develop
但是由于周期比较长, 比如 A 只用了一天完成, B 用了 1周, C 可能要好几个月, 会不会 B 和 C 合并之前用 rebase 一下比较好? 优点在哪里呢? 因为但我 merge B 和 C 回去的时候, 也没啥大问题.
但是由于周期比较长, 比如 A 只用了一天完成, B 用了 1周, C 可能要好几个月, 会不会 B 和 C 合并之前用 rebase 一下比较好? 优点在哪里呢? 因为但我 merge B 和 C 回去的时候, 也没啥大问题.
 | 1 Anran 2014 年 3 月 17 日  3 |
 | 2 tunetoystory 2014 年 3 月 17 日 周期长的话 rebase 很难受吧，相当于先将 B, C 分支上的提交拿出来，将他们更新到 develop 的最新版，再将之前拿出的提交打上去，如果周期太长了，可能会有很多冲突，而且这个过程是不可逆的，rebase 之前先分一个备份分支出去。 |
 | 3 skydiver 2014 年 3 月 17 日 via Android 一直用rebase代替merge，感觉比merge干净一些 |
 | 4 mcfog 2014 年 3 月 17 日 你说的情景我的理解是应该A完成功能进dev，经过测试后发布，进master B和C不定期无脑从master合并代码到自己的分支即可，包括A的新功能和期间可能的bugfix等 我的理解是rebase最大的用处是，如果A和B开发的功能异常耦合，各种改相同的文件(其实应该避免的)，那么B合A可能很痛苦，B上10个提交和A上3个提交各种冲突，这时候rebase可以温柔一点，一个个提交来解决冲突 |
 | 5 lightening 2014 年 3 月 17 日 via iPhone Rebase against master 可以经常做的。 另外，每次合并到master前，用 rebase --interactive 该一个所有 commit，做到原子提交。 |
 | 6 undeflife 2014 年 3 月 17 日 @lightening 这个操作在master下 git merge --squash dev 更简单吧 |
 | 7 xi_lin 2014 年 3 月 18 日 rebase以后develop的树长得好看:) |
| 8 lightening 2014 年 3 月 30 日 @undeflife 我们不允许直接在 master 做任何修改。Master 只能在 github 上点 merge。 |
Select Language