愚蠢的问题，把我当作版本控制的新手。
我是Git的新手（我以前使用过Subversion，但只是基础知识），我了解Git及其分支命令的基础知识，我有一个需要您建议的虚拟情况。
假设我的软件目前是v1.2，稳定并发布了。
我的软件
V1.0
V1.1
V1.1.1
v1.2脚本：
我有两个开发人员，约翰和埃里克。
John负责客户报告的错误修复。
Eric负责新功能，对它们进行实验，并解决各种问题。
现在是一月。
约翰正在研究基于v1.2版本的许多错误修复。每天他都需要将代码提交回存储库（Github），软件可能不会编译，这取决于他的状态。
Eric正在试验这个新的wiki功能，从添加Wysiwyg编辑器等基本功能到diffing/version control等高级功能，同样，他需要将代码提交回存储库，软件也可能不会编译，这取决于他在哪里。
目标
在任何时候，我都可以推出一个稳定的、可编译的v1.2版本
2月，我希望v1.3能被所有约翰的bug修复程序推出，这取决于Eric是否完成了（至少已经完成了基本功能），也要发布它。
对于Git，工作流是什么？
如果我正确理解Git，Eric和John都应该创建自己的分支，并且在2月份，让他们将与大师合作的内容合并起来吗？
谢谢
最佳答案
我将在主存储库中设置两个集成分支：
主：新功能集成分支（由Eric维护）
1.2-稳定：缺陷修复的集成分支（由John维护）
请注意，这些分支只应用于集成目的，即合并其他所谓的功能分支的已完成工作。开发和错误修复应该在特性分支中完成。在此工作流中，集成分支中的代码始终有效。
两个开发人员对于他们试图完成的每个任务都应该有一个特性分支。在您的情况下，Eric会有一个名为wysiwyg的分支，从主分支的顶端开始。当特性准备好进入开发主线时，Eric可以简单地将所见即所得分支合并到master中。
这同样适用于约翰。例如，如果John必须解决两个问题（例如，issue1和issue2），那么他应该有fix-issue1和fix-issue2分支。这些分支应该从1.2稳定分支的顶端开始。在解决了其中一个问题（比如issue1）之后，john可以将分支fix-issue1合并回1.2-stable。如果master和1.2-stable分支中的代码没有太多分歧，那么Eric可能会偶尔将branch 1.2-stable合并到master中，以便将累积的补丁合并到产品的下一个版本中。
当需要发布1.3版本时，Eric应该确保1.2稳定分支和就绪功能分支中的累积修复都已合并到master中。然后他可以简单地标记v1.3并创建一个新的分支1.3-stable。