Git Workflow最佳实践

Question

愚蠢的问题，并将我视为完全是版本控制的新手。

我是Git的新手（之前我曾经使用过subversion，但只是基础知识）我理解Git及其分支命令的基础知识，我有一个想象的情况需要你的建议。

假设我的软件目前处于v1.2，稳定并已发布。

My Software
       v1.0
       v1.1
       v1.1.1
       v1.2 <- Current, Compilable and Released

情景：

我有两个开发人员，John和Eric。

• John负责客户报告的错误修复。
• Eric负责新功能，试验它们并解决问题。

现在是1月份。

John正在根据v1.2版本开发许多错误修复程序。每天他都需要将代码提交回存储库（GitHub），软件可能无法根据其状态进行编译。

Eric正在尝试这个新的wiki功能，从基本功能（如添加WYSIWYG编辑器）到高级功能（如差异/版本控制），再次，他需要将代码提交回存储库，软件可能无法编译，这取决于他的位置在。

目标

1. 在任何时候，我都可以提供稳定，可编辑的v1.2版本
2. 二月，我希望v1.3能够被所有John的错误修复推出，并且取决于Eric是否完成（至少已完成基本功能），同时发布它。

使用GIT，工作流程是什么？

如果我正确理解GIT，Eric和John都应该创建自己的分支，并且在2月，让他们合并与主人合作的东西吗？

由于

Answer 1

我会在主存储库中设置两个集成分支：

1. master：新功能的集成分支（由Eric维护）
2. 1.2-stable：用于错误修复的集成分支（由John维护）

请注意，这些分支仅应用于集成目的，即用于将完成的工作与其他所谓的功能分支合并。开发和错误修复应该在功能分支中完成。在此工作流程中，集成分支中的代码始终有效。

两个开发人员都应该为他们要完成的每项任务分配一个功能分支。在你的情况下，Eric会有一个名为wysiwyg的分支，它从master分支的顶端开始。当该功能准备好进入开发主线时，Eric可以简单地将所见即所得分支合并到主服务器中。

这同样适用于约翰。例如，如果John必须修复两个问题（例如，issue1和issue2），他应该有分支fix-issue1和fix-issue2。这些分支应该从1.2稳定分支的尖端开始。在解决了其中一个问题之后，比如问题1，John可以将分支fix-issue1合并回1.2-stable。如果master和1.2-stable分支中的代码没有太大分歧，那么Eric可能偶尔会将分支1.2-stable合并到master中，以便将累积的修复程序合并到下一个版本的产品中。

什么时候发布1.3 Eric应该确保1.2-stable分支和ready功能分支中的累积修复都已合并到master中。然后他可以简单地标记v1.3并创建一个新的1.3-stable分支。

Answer 2

对于谁来维护主题分支从问号和kaitanie-Question Mark推荐John在master上工作而kaitanie推荐Eric在master上工作的相反建议 - 展示了Git的工作流程灵活性。

就Chris Nicola建议变基而不是合并而言，我会提供Pro Git by Scott Chacon中的read free online同样的警告，"Branching Workflows"可以使用，我强烈建议，“不要改变你的承诺已推到公共存储库。“由于“每天[约翰都需要将他的代码提交回存储库（GitHub）”，我可能会远离变基，除非John和Eric在本地使用它。

我建议您阅读 Pro Git 的"Distributed Workflows"部分，其中介绍了长期运行的分支和主题分支。您还应该查看{{3}}部分，其中介绍了集中式工作流程，集成管理器工作流程以及独裁者和中尉工作流程。

Answer 3

GIT非常灵活，您可以根据具体情况定制使用方式。也就是说，我喜欢每个功能的分支方法，我也更喜欢“重新定位”到合并。

每个功能分支意味着您为正在处理的每个功能或缺陷创建分支。通常，分支仅在开发时存在，并且在与主服务器合并/重新绑定后将被删除。

Rebase意味着不是让分支与主服务器合并，而是实际从主服务器中提取更改，并将它们放在您在分支中所做的所有更改之前。实质上，它将HEAD与分支更改的开头合并。这使得您似乎在最新的HEAD修订版之后开始合并所有更改。

将分支机构推送到远程存储库也是一种很好的做法，以防其他人需要查看或使用分支机构，同时它还会为您的工作提供备份。再次当你完成一个分支我建议清理后删除旧 分支。

最后，最后一个最佳实践是保持您的提交较小，特定于一个特定任务或操作，以便其他人可以轻松检查每个提交以及快速理解的内容。然后，提交可以用来记录您的进度和活动。

Answer 4

  

如果我正确理解GIT，Eric和John都应该创建自己的分支，并且在2月，让他们合并与主人合作的东西吗？

是

Answer 5

John应该在master上工作，Eric应该在名为WYSIWYG的分支上工作，或者在某个分支上正确命名。

如果你想检查什么是1.3版本，你应该将John的主分支推送到一个名为stable的新分支，如果你还没有它，如果你已经有一个稳定的分支，只需将master再次合并到stable中，每次你想发布一些错误修复时都会这样做。

如果Eric在wysiwyg分支上完成了，那么将其合并，然后你就可以获得可编译的版本了。然后归档/销毁/忽略wysiwyg分支，因为它不再需要。