Git 工作流程最佳实践

愚蠢的问题，把我当作版本控制的完全新手。

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

假设我的软件当前版本是 v1.2，稳定且已发布。

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

设想：

我有两个开发人员，约翰和埃里克。

• John 负责客户报告的错误修复。
• 埃里克（Eric）负责新功能、试验它们并解决问题。

现在是一月份。

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

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

Goal

1. 我可以随时推出稳定、可编译的 v1.2 版本
2. 二月，我希望推出 v1.3，并修复 John 的所有错误，并根据 Eric 是否完成（至少完成基本功能）来发布它。

使用GIT，工作流程是怎样的？

如果我正确理解 GIT，Eric 和 John 都应该创建自己的分支，并在二月份让他们合并与 master 兼容的内容？

Thanks

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

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

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

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

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

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