浅析GIT分支模型

前几天在大神的wiki里看到了这么一篇文章（https://nvie.com/posts/a-successful-git-branching-model/），抱着学习的态度想对原文进行翻译下，不当之处请大家多多指教。图1是给出的git分支模型，在原文中作者没有讨论任何项目的细节信息，仅仅讨论关于分支策略和release版本管理。

Decentralized but centralized

GIT是一个分布式的版本控制工具，在技术层面是没有中央仓库(不考虑gitlab、github)的概念。但是在此分支模型中，我们在创建使用一个仓库时，设定一个仓库为中央仓库，根据开发者的使用习惯，定义此仓库名称为origin，如图2所示。

项目开发组中的成员都可以在origin分支上拉取上传代码，除了这种集中式的推拉关系外，还可以从项目组的其他成员那儿拉取代码。通过构建不同的子项目组，也就是通过创建不同的分支，可以实现不同功能需求的并行开发，待开发完毕后合并到origin分支上。图2中alice和bob、alice和david、david和clair可以理解为3个不同的子项目组，也可以理解为3个不同的分支。

The main branches

在图3分支模型中，中央仓库在其生命周期中维护着两个分支：master分支和develop分支。master分支上的代码是生产环境稳定运行的代码，开发者不应该在master分支上做任何修改代码的操作；develop分支是新功能迭代中合并的主分支，开发者可以在此分支上进行对应的回归测试和夜构建。当develop分支上的代码达到上线标准并且准备发布时，开发者需要将develop分支上的代码合并到master分支上，并且打上对应的tag。

Supporting branches

除了master分支和develop分支以外，分支模型中需要一些额外的分支来支撑项目中新功能的开发、版本的迭代、线上问题的修复。由于这些分支特有的属性，导致它们的生命周期都比较短暂。在此模型中，我们将这些分支定义为feature分支、relaese分支和hotfix分支。

Feature branches

feature分支用于开发即将推出或未来版本的新功能。如图4所示，feature分支的本质是，只要功能处于开发阶段它就会存在，但最终会被合并到develop分支或丢弃。feature分支的命名规则比较随意，只需要避免”master”、”develop”、”release-“,”hotfix-x“这几类名称就可以。通常我们都从develop分支上创建一个feature分支，

git checkout -b myfeature develop

当完成功能开发时，需要将feature分支合并到develop分支上，

git checkout develop

git merge --no--ff myfeature

git branch -d myfeature

git push origin master

Release branches

release分支是从准上线的状态的develop分支上创建而来，反映了我们对于新版本的期望。在新版中，一些重要的feature需要合并到develop分支上。此外，在release分支上可以进行小问题的修改，并且为发布版本（版本号，构建日期等）提供元数据信息。正是在release分支开始时，即将发布的版本才会被分配一个版本号 。需要说明的是，开发分支仅反映了“下一个版本”的变化，但是尚不清楚这个“下一个版本”是否最终会变为0.3或1.0，首先创建一个release分支：

然后把release分支上的代码进行合并到master分支上，

此外需要将代码合并到develop分支上，

最后删除release分支

Hotfix branches

当生产环境中的代码存在严重bug时，需要从master分支上创建hotfix分支进行bug的修复，修复完毕后在合并到develop分支和master分支上。分支名称一般命名为”hotfix-*”。

总结

以上便是文章中介绍的git分支模型。在我们实际的项目开发中，根据自己项目特点仅使用master、develop和feature分支构成的阉割版的分支模型。总之，代码规范跟自己团队的规模、项目迭代情况、项目组开发者等各种因素相关，我们需要根据以上各种因素选择最合适的gitflow工作流程。