Git 工作流最佳实践

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 负责新功能，对它们进行试验并解决问题。

现在是一月份。

John 正在研究基于 v1.2 版本的大量错误修复。每天他都需要将代码提交回存储库 (GitHub)，根据他的状态，软件可能无法编译。

Eric 正在试验这个新的 wiki 功能，从添加 WYSIWYG 编辑器等基本功能到比较/版本控制等高级功能，同样，他需要将代码提交回存储库，软件可能无法编译，这取决于他在哪里在。

目标

1. 在任何时候，我都可以推出一个稳定的、可编译的 v1.2 版本
2. 2 月，我希望 v1.3 与 John 的所有错误修复一起推出，并根据 Eric 是否完成(至少完成基本功能)，也发布它。

GIT 的工作流程是什么？

如果我对 GIT 的理解正确，Eric 和 John 都应该创建自己的分支，并在 2 月让他们 merge 与 master 一起工作的分支？

谢谢

Answer 1

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

1. master:新功能的集成分支(由 Eric 维护)
2. 1.2-stable:错误修复的集成分支(由 John 维护)

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

两个开发人员都应该为他们试图完成的每项任务创建一个功能分支。在你的情况下，Eric 会有一个名为 wysiwyg 的分支，它从 master 分支的顶端开始。当功能准备好进入开发主线时，Eric 可以简单地将 wysiwyg 分支 merge 到 master 中。

这同样适用于约翰。例如，如果 John 必须解决两个问题(比如 issue1 和 issue2)，他应该有分支 fix-issue1 和 fix-issue2。这些分支应该从 1.2-stable 分支的顶端开始。解决其中一个问题后，比如 issue1，John 可以将分支 fix-issue1 merge 回 1.2-stable。如果 master 和 1.2-stable 分支中的代码没有太大分歧，那么 Eric 偶尔将分支 1.2-stable merge 到 master 中可能是个好主意，以便将累积的修复 merge 到产品的下一个版本中。

当发布 1.3 时，Eric 应该确保 1.2-stable 分支和准备好的特性分支中积累的修复已经全部 merge 到 master 中。然后他可以简单地标记 v1.3 并创建一个新分支 1.3-stable。