我看到其他人提出关于合并(merge)和变基(rebase)的问题,以及何时使用哪种方法,但我仍有一些问题想问常规GIT用户。首先,让我列出我理解的好的GIT实践: 从现有的A分支创建新分支B 在B分支上添加/提交更改 将A分支的更新进行变基(rebase) 将B分支的更改合并到A分支 就目前我所理解的来看,上述工作流适用于分层分支模型(也就是A = 主分支,B = 用于新功能开发的实验性分支)最佳。简而言之,向下变基是一种很好的实践,而向主分支合并是另一种实践。我的理解正确吗? 现在,如果与其他开发人员一起工作,他们可能会提交/合并对A分支(主分支)的更改,那么我认为最好的做法是,尽可能多地重复步骤2和3,以确保我的B分支上的工作不会与其他用户提交到A分支的任何内容冲突。如果有任何冲突,在B分支上使用变基将重新应用我的提交,并允许我在向A分支合并之前处理这些冲突。我的理解正确吗? 最后,这是我的主要问题:如果我没有与其他开发人员一起工作,并且在完成B分支的新功能之前不会接触A分支,那么我能够跳过变基(步骤3),直接将B分支合并到主分支A中吗?我想即使先进行变基也无妨,但是如果我知道A分支自创建B分支以来没有被修改,那么跳过变基也是可以的。我的理解是否正确? PS.非常感谢您提供的任何指导! 我对GIT很新,在使用GIT之前从未使用过SCM系统。 谢谢, Jesse Leite http://www.aurorafxstudios.com/
过度使用rebase并不是一个好主意。我一开始也是这样做的,但后来只做了合并和重置。看看我的工作流程吧,它基于nvie's。 简而言之,你需要组织好你的工作。将分支A作为分支B的基础将它们联系在一起。如果A中有问题,撤销它可能并不容易,这可能是个坏事。
merge
+--no-ff
是更好的选择,因为您将有一个新的提交要标记。 - redhotvengeance