GIT合并和衍合工作流确认？

Question

我看到其他人提出关于合并（merge）和变基（rebase）的问题，以及何时使用哪种方法，但我仍有一些问题想问常规GIT用户。首先，让我列出我理解的好的GIT实践：

1. 从现有的A分支创建新分支B
2. 在B分支上添加/提交更改
3. 将A分支的更新进行变基（rebase）
4. 将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/

- Jesse Leite

Answer 1

过度使用rebase并不是一个好主意。我一开始也是这样做的，但后来只做了合并和重置。看看我的工作流程吧，它基于nvie's。

简而言之，你需要组织好你的工作。将分支A作为分支B的基础将它们联系在一起。如果A中有问题，撤销它可能并不容易，这可能是个坏事。

- Adam Dymitruk

---

使用所有合并将创建不必要的提交。然而，如果您正在从主分支衍生的功能分支中工作，则重新设置可以保持您的历史记录清洁。但是，如果您要合并到发布分支中，则我同意使用merge + --no-ff是更好的选择，因为您将有一个新的提交要标记。 - redhotvengeance

谢谢回复！rebase 本质上是通过将当前分支替换为来自主分支的最新代码，然后重新应用您的特定分支提交，从而重置当前分支吗？我粗略地浏览了一下你的文章，但是这个GIT的东西对我来说还很新，所以一半的术语让我无法理解:(不过我会花些时间重新阅读你的文章。看起来你提出了一些不错的观点。也许我去读一下nvie的文章。你的文章与nvie的有什么不同？ - Jesse Leite

每个版本发布的功能都从同一点开始。Nvie的流程允许分支从已经集成了其他功能的点开始。这使它们相互耦合，而我的流程则不会。 - Adam Dymitruk

我刚刚阅读了nvie的工作流程文章和你的工作流程。我理解nvie的工作流程，但我仍然对你的工作流程有一些疑问。当你说“每个版本的所有功能都从同一点开始”时，是指在版本发布之间不允许在develop分支上提交（按照nvie的术语）吗？这意味着所有功能分支基本上都被强制从上一个发布版本开始，对吗？ - Jesse Leite

另外，我的第二个问题是：当一个功能分支完成后，是否允许立即合并回开发分支？我从您的工作流程中了解到，新功能应保留在各自的分支上，并且在准备好下一个发布版本时，负责发布的开发人员可以挑选要包含在最终发布版中的功能。他/她会从开发分支还是从功能分支本身获取这些功能呢？PS. 我很想看到您发布像nvie那样的可视化模型图；它真的帮助我理解他的工作流程。 - Jesse Leite

Answer 2

你的理解是正确的。如果没有改动A，那么你的rebase将不会有任何操作。A不变的好处是你知道不会有冲突！

- Graham Perks