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. 2月,我希望v1.3被推出所有John的错误修复,并且取决于Eric是否完成(至少已完成基本功能),同时发布它.

有了GIT,工作流程是什么？

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

谢谢

Answer 1

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

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

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

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

这同样适用于约翰.如果,例如,约翰必须解决两个问题(比如,issue1和issue2)他应该有分支机构修复,issue1和修复,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分支稳定分支.