我试图理解Git中的变基,并且在这种情况下使用变基是否是一种好的做法是个好问题:
我有一个名为'feature'的分支,它从另一个名为'develop'的分支分支出来.我已经在'feature'中做了几次提交,但还没有与'develop'合并,因为该功能仍在开发中,'feature'中的提交也没有被推送到远程存储库.
如果我现在结帐"开发"以进行一些修正,将它重新设置为"功能"分支是否明智,以便"开发"与"功能"同步？
我会在'develop'上修改'feature'(当然,假设'feature'是一个本地分支)
将"develop"合并为"feature"将创建冗余合并提交.但是,使用rebase集成了来自master的所有更改,并允许您在"feature"准备好与"develop"合并之前解决所有冲突,而无需创建任何额外的提交.
当然有些人不同意.但我喜欢干净,可读的历史.我经常做的是,当我完成这个功能时,我rebase,然后我merge --no-ff.这样,历史记录仍然清楚地表明有一个功能分支:
- * - * - - - - - - - * - * -
\ /
* - * - * - *
问题是我喜欢"不断"地解决冲突.每当发生冲突时我都想早点知道它,所以我可以在它变得麻烦之前解决它(类似于持续集成的原因).如果我遵循使用频繁合并的策略,我会有很多合并提交.频繁的反叛我可以避免它们.
有一种替代策略可以让你使用合并但没有合并提交 - 你可以打开git rerere:
git config --global rerere.enabled true
如本文所述,您可以执行中间合并,解决冲突,然后重置合并提交.当您执行"功能"分支的最终合并时,rerere功能将使Git记住冲突解决方案.
| 归档时间： |
|
| 查看次数： |
745 次 |
| 最近记录： |