这是一个关于版本控制的问题，假设软件当前的版本为v1.2。有两名开发人员John和Eric，John负责修复客户报告的缺陷，Eric则负责实验新特性并解决其中的问题。要求在任何时候都能拉出稳定可编译的v1.2版本，并在二月份发布包含John修复的所有缺陷的v1.3版本以及Eric完成的基本功能版本。
使用GIT，应该如何操作呢？正确的工作流程是：John和Eric各自创建自己的分支，在二月份将他们的工作合并到主干上。这样可以确保每个人的工作不会影响其他人的进度，同时也保证了稳定可靠的版本。
Git工作流程最佳实践
13
- Liming
1
哇，感谢大家提供这么多好的答案，也感谢Brian重新格式化我的帖子。非常感谢你们在这个主题上的见解，至于Re-base v.s Merging，我会像Mathew建议的那样再读一些相关内容。总的来说，我现在已经有了一个清晰的想法。再次非常感激。 - Liming
5个回答
8
我会在主代码库中设置两个集成分支：
两位开发人员应该为他们想要完成的每个任务拥有一个功能分支。在您的情况下，Eric将拥有一个名为wysiwyg的分支，该分支从master分支的顶端开始。当该功能准备好进入开发的主线时，Eric可以将wysiwyg分支简单地合并到master中。
对于John也是如此。例如，如果John必须解决两个问题（比如issue1和issue2），他应该有fix-issue1和fix-issue2分支。这些分支应该从1.2-stable分支的顶端开始。解决其中一个问题后，例如issue1，John可以将fix-issue1分支合并回1.2-stable分支。如果master和1.2-stable分支中的代码没有分歧太大，那么Eric偶尔合并1.2-stable分支到master中以将积累的修复合并到产品的下一个版本中可能是个好主意。
当到了发布1.3的时候，Eric应确保已将1.2-stable分支和准备好的功能分支中的累积修复合并到master中。然后他可以简单地标记v1.3并创建一个新的1.3-stable分支。
- master：新功能的集成分支（由Eric维护）
- 1.2-stable：漏洞修复的集成分支（由John维护）
两位开发人员应该为他们想要完成的每个任务拥有一个功能分支。在您的情况下，Eric将拥有一个名为wysiwyg的分支，该分支从master分支的顶端开始。当该功能准备好进入开发的主线时，Eric可以将wysiwyg分支简单地合并到master中。
对于John也是如此。例如，如果John必须解决两个问题（比如issue1和issue2），他应该有fix-issue1和fix-issue2分支。这些分支应该从1.2-stable分支的顶端开始。解决其中一个问题后，例如issue1，John可以将fix-issue1分支合并回1.2-stable分支。如果master和1.2-stable分支中的代码没有分歧太大，那么Eric偶尔合并1.2-stable分支到master中以将积累的修复合并到产品的下一个版本中可能是个好主意。
当到了发布1.3的时候，Eric应确保已将1.2-stable分支和准备好的功能分支中的累积修复合并到master中。然后他可以简单地标记v1.3并创建一个新的1.3-stable分支。
- kaitanie
3
Question Mark和kaitanie对于谁来维护主分支的相反建议——Question Mark建议John在主分支上工作，而kaitanie建议Eric在主分支上工作——展示了Git的工作流程的灵活性。
至于Chris Nicola建议使用rebase而不是merge，我会提供与Scott Chacon的Pro Git中发现的相同警告，该书可以免费在线阅读，我强烈推荐：“不要rebase已经推送到公共存储库的提交。”由于“每天[John]都需要将他的代码提交回存储库（GitHub）”，除非仅在John和Eric本地使用，否则我可能会避免使用rebase。
我建议您阅读《Pro Git》的"分支工作流程"章节，其中描述了长期运行的分支和主题分支。您还应该查看"分布式工作流程"章节，其中描述了集中式工作流程、集成管理器工作流程和独裁者和副手工作流程。- Matthew Rankin
2
GIT非常灵活，您可以根据自己的特定情况来定制使用方式。尽管如此，我喜欢采用“分支-特性”方法，并且更喜欢“变基（rebasing）”而不是合并。
“分支-特性”意味着您为每个正在处理的特性或缺陷创建一个分支。通常，该分支只在开发期间存在，并在与主分支合并/变基后被删除。
“变基”意味着您不是将分支与主分支合并，而是实际上将来自主分支的更改拉下来，并将它们放在您分支所做所有更改的最前面。本质上，它将HEAD与您的分支更改的开始合并。这使得似乎您要合并的所有更改都是在最新的HEAD修订版之后开始的。
将您的分支推送到远程仓库也是一个好习惯，以防其他人需要查看或处理该分支，同时还提供了对您工作的备份。同样，当您完成一个分支时，建议清理并删除旧分支。
最后，一个最佳实践是保持提交的小型化，专注于一项特定任务或操作，以便他人可以轻松地检查每个提交并快速理解所做的工作。提交可以记录您的进度和活动。
- Chris Nicola
1
如果我理解GIT正确的话，Eric和John应该各自创建自己的分支，然后在2月份将有效的部分与主分支合并，对吗？
是的。
是的。
- Antony Hatchkins
1
John 应该在主分支上工作，Eric 应该在一个名为 WYSIWYG 或者其他合适的分支上工作。
如果你想要检出可能是版本 1.3 的内容，你应该将 John 的主分支推送到一个叫做 stable 的新分支上，如果你还没有这个分支，如果你已经有了 stable 分支，只需将主分支合并到 stable 中即可。每次你想发布一些 bug 修复时都需要这样做。
如果 Eric 在 wysiwyg 分支上完成了工作，请将其合并，然后你就可以编译发布了。然后你可以归档/销毁/忽略 wysiwyg 分支，因为它不再需要。
- Question Mark
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接