Git是目前最流行的代码管理工具，相信大家也都是在用Git来管理自己团队的源代码。
团队一般为了规范开发，保持良好的代码提交记录以及维护 Git 分支结构清晰，方便后续维护等，都会迫切需要一个比较规范的 Git 工作流。
本文就是在这个背景下诞生的，如果你的团队正好有此需求，那你可以看一下，希望本文能给大家提供一些帮助，建立良好的团队代码流程规范。
我们在实际工作中会创建很多分支以便于不同场景下的开发，但是如果没有分支规范就会造成分支杂乱，大家往往也搞不清楚某一个分支是在做什么，下面我们就介绍一下我们常用的并且推荐大家使用的分支类型。
master 分支
master 为产品主分支，该分支为只读唯一分支，也是用于部署生产环境的分支，需确保master分支的稳定性。master 分支一般由release分支或hotfix分支合并，任何情况下都不应该直接修改master分支代码。产品的功能全部实现后，最终在master分支对外发布，另外所有在master分支的推送应该打标签（tag）做记录，方便追溯。master 分支不可删除。当有一组feature开发完成后，首先开发人员会各自将最新功能代码合并到develop分支。进入提测阶段时，开发组长在develop分支上创建release分支。 如果在测试过程中发现bug需要修复，则直接由开发者在release分支修复并提交。当测试完成后，开发组长将release分支合并到master和develop分支，此时master为最新可发布代码，用作产品发布上线。
以上就是在工作中常用到的6种分支类型，覆盖了开发中的常见场景，大家也可以根据实际工作情况进行调整，重点是让团队小伙伴都能对整个分支的类型及作用了解即可。
分支创建好了，小伙伴们也都开始按照流程开始开发了，但是在日常开发中由于缺少对于commit message的约束，导致填写内容随意、质量参差不齐，可读性低亦难以维护。在项目中引入commit message规范已是迫在眉睫。书写良好的commit message能大大提高代码维护的效率。
在一个团队协作的项目中，开发人员需要经常提交一些代码去修复bug或者实现新的feature。而项目中的文件和实现什么功能、解决什么问题都会渐渐淡忘，最后需要浪费时间去阅读代码。但是好的日志规范commit messages编写有帮助到我们，它也反映了一个开发人员是否是良好的协作者。
编写良好的Commit messages可以达到3个重要的目的：
加快代码view的流程帮助开发人员编写良好的版本发布日志让之后的维护者了解代码里出现特定变化和feature被添加的原因目前，社区有多种 Commit message 的写法规范。来自Angular 规范是目前使用最广的写法，比较合理和系统化。建议使用如下：
具体格式为:
# EN <type>(<scope>): <subject> <BLANK LINE> <body> <BLANK LINE> <footer> # CN <类型>[可选的作用域]: <描述> [可选的正文] [可选的脚注] type: 本次 commit 的类型，诸如 bugfix、docs、style 等，类型说明参见下方。scope: 本次 commit 影响的范围，比如数据层、控制层、视图层等等，视项目不同而不同。subject: 简明扼要的阐述下本次 commit 的主旨，是 commit 目的的简短描述，建议不超过50个字符。body: 在主体内容中我们需要把本次 commit 详细的描述一下，比如此次变更的动机，详细的修改方法或其他需要额外重点说明的内容。footer: 描述下与之关联的 issue 或 break change，详见案例。注：如果一次改动内容较多，包含多个提交类型时，建议拆分成多个提交，分次提交，这样会更清晰。
我们现在已经了解了Git的分支，包括分支有哪些类型，什么情况下使用什么类型的分支，以及提交的格式规范等。不过往往在一个团队人数较多，创建的分支也比较多的时候，还是会带来很多分支操作上的困扰。那有没有一个什么好的流程来规范大家呢，针对这些问题，建议大家使用Git Flow的工作流模式。
1，主分支流程
master分支记录了每次版本发布历史和tag标记。develop分支记录了所有开发的版本历史。develop分支仅第一次创建时从master分支拉取。2，开发流程
feature分支是从develop分支拉取的分支。每个feature完成后需合并到develop分支。3，提测发布流程
release分支是在所有功能开发自测完成后，从develop分支拉取的分支。release分支一旦创建后，通常不再从develop分支拉取，该分支只做bug修复，文档生成和其他面向发布的任务。release分支测试完成，达到上线标准后，需合并回master分支和develop分支。4，bug修复流程
hotfix分支是在线上出现bug之后，从master分支拉取的分支。hotfix分支测试完成后，需合并回master分支和develop分支。Git Flow的流程搞清楚后，我们下面开始实际的项目实战，假设我们现在有一个商城的项目，并且我们已经建好了Git仓库。
我们通过命令行和图形界面的方式分别向大家展示如何使用Git Flow工作流。
大家可以看到，简简单单几行命令就可以完成比较复杂的流程管理，如果对于命令行不太擅长的小伙伴还可以使用图形工具，这里推荐使用sourcetree，sourcetree也是著名的Git管理工具，可以大大方便我们对Git的操作和使用，下面就来介绍一下sourcetree中如何使用Git Flow。
注：以下内容为Windows版本的sourcetree为例，Mac类似。
打开sourcetree，选择想使用Git Flow工作流的项目，在右上角点击Git工作流按钮，如下图所示：
随后会弹出对话框，可以选择产品分支，开发分支以及功能分支等，如下图所示：
点击确定后完成仓库的Git Flow初始化。
点击右上角Git工作流，显示如图界面：
输入本次功能的名称，点击确定创建feature分支
可以看到本地已经有了新建的feature分支，如图所示：
然后就可以在该分支进行功能开发了。
功能开发完成之后，还是点击右上角Git工作流，显示如图界面：
点击完成功能，如下图所示：
这里可以选择将该feature分支删除或保留，可以根据团队的规定来处理即可。
点击确定后，完成feature功能的开发。
至此该流程处理完毕。
同样的，点击右上角Git工作流，选择建立新的发布版本，显示如下：
输入发布版本名称，点击确定，完成release分支的创建。
此时可以看到已经创建的release分支，如下图所示：
测试通过后，可以进行release版本的发布，如下图所示：
输入该发布的标签信息，点击确定进行发布。
至此，我们已经完成了release的发布流程。
hotfix流程与上述流程操作方法类似，再次不再赘述，大家可以通过软件进行操作练习。
好了，到这里，我们关于Git工作流的内容已经全部讲完啦，大家可以根据自己团队的需要进行使用和改进，以让团队的协作更加高效和规范。
如果你喜欢本文,
扫描二维码，关注「我是开发者FTD」公众号 关注开发，更关注开发者！
