一文读懂Git工作流

Git是目前最流行的代码管理工具，相信大家也都是在用Git来管理自己团队的源代码。

团队一般为了规范开发，保持良好的代码提交记录以及维护 Git 分支结构清晰，方便后续维护等，都会迫切需要一个比较规范的 Git 工作流。

本文就是在这个背景下诞生的，如果你的团队正好有此需求，那你可以看一下，希望本文能给大家提供一些帮助，建立良好的团队代码流程规范。

本文的目录如下

Git主要优点
Git分支管理
Git日志规范
Git Flow工作流
Git Flow实战

Git主要优点

分布式存储，本地仓库包含了远程仓库的所有内容。
安全性高，远程仓库文件丢失了也不怕。
优秀的分支模型，创建/合并分支都非常快速便捷。

Git分支管理

我们在实际工作中会创建很多分支以便于不同场景下的开发，但是如果没有分支规范就会造成分支杂乱，大家往往也搞不清楚某一个分支是在做什么，下面我们就介绍一下我们常用的并且推荐大家使用的分支类型。

Git分支类型

master 分支

master 为产品主分支，该分支为只读唯一分支，也是用于部署生产环境的分支，需确保master分支的稳定性。
master 分支一般由release分支或hotfix分支合并，任何情况下都不应该直接修改master分支代码。
产品的功能全部实现后，最终在master分支对外发布，另外所有在master分支的推送应该打标签（tag）做记录，方便追溯。
master 分支不可删除。

develop 分支

develop 为主开发分支，基于master分支创建，始终保持最新完成功能的代码以及bug修复后的代码。
develop 分支为只读唯一分支，只能从其他分支合并，不可以直接在该分支做功能开发或bug修复。
一般开发新功能时，feature分支都是基于develop分支下创建的。
develop 分支包含所有要发布到下一个release的代码。
feature功能分支完成后, 开发人员需合并到develop分支(不推送远程)，需先将develop分支合并到feature，解决完冲突后再合并到develop分支。
当所有新功能开发完成后，开发人员并自测完成后，此时从develop拉取release分支，进行提测。
release或hotfix 分支上线完成后, 开发人员需合并到develop分支并推送远程。
develop 分支不可删。

feature 分支

feature 分支通常为新功能或新特性开发分支，以develop分支为基础创建feature分支。
分支命名: feature/ 开头的为新特性或新功能分支，建议的命名规则: feature/user_createtime_feature，例如：feature/ftd_20201018_alipay，含义为：开发人员ftd在2020年10月18日时创建了一个支付宝支付的功能分支。
新特性或新功能开发完成后，开发人员需合到develop分支。
feature 分支可同时存在多个，用于团队中多个功能同时开发。
feature 分支属于临时分支，功能完成后可选删除。

release 分支

release 分支为预上线分支，基于本次上线所有的feature分支合并到develop分支之后，从develop分支创建。
分支命名: release/ 开头的为预上线分支，建议的命名规则: release/version_publishtime，例如：release/v2.1.1_20201018，含义为：版本号v2.1.1计划于2020年10月18日时发布。
release 分支主要用于提交给测试人员进行功能测试。发布提测阶段，会以release分支代码为基准进行提测。测试过程中发现的bug在本分支进行修复，上线完成后需合并到develop/master分支并推送远程。
release 分支属于临时分支，产品上线后可选删除。

当有一组feature开发完成后，首先开发人员会各自将最新功能代码合并到develop分支。进入提测阶段时，开发组长在develop分支上创建release分支。
如果在测试过程中发现bug需要修复，则直接由开发者在release分支修复并提交。当测试完成后，开发组长将release分支合并到master和develop分支，此时master为最新可发布代码，用作产品发布上线。

hotfix 分支

hotfix 分支为线上bug修复分支或叫补丁分支，主要用于对线上的版本进行bug修复。
分支命名: hotfix/ 开头的为修复分支，它的命名规则与 feature 分支类似，建议的命名规则: hotfix/user_createtime_hotfix，例如：hotfix/ftd_20201018_alipaybugfix，含义为：开发人员ftd在2020年10月18日时创建了一个支付宝支付bug修复的分支。
hotfix 分支用于线上出现紧急问题时，需要及时修复，以master分支为基线，创建hotfix分支。当问题修复完成后，需要合并到master分支和develop分支并推送远程。
所有hotfix分支的修改会进入到下一个release。
hotfix 分支属于临时分支，bug修复上线后可选删除。

以上就是在工作中常用到的6种分支类型，覆盖了开发中的常见场景，大家也可以根据实际工作情况进行调整，重点是让团队小伙伴都能对整个分支的类型及作用了解即可。

分支创建好了，小伙伴们也都开始按照流程开始开发了，但是在日常开发中由于缺少对于commit message的约束，导致填写内容随意、质量参差不齐，可读性低亦难以维护。在项目中引入commit message规范已是迫在眉睫。书写良好的commit message能大大提高代码维护的效率。

Git日志规范

在一个团队协作的项目中，开发人员需要经常提交一些代码去修复bug或者实现新的feature。而项目中的文件和实现什么功能、解决什么问题都会渐渐淡忘，最后需要浪费时间去阅读代码。但是好的日志规范commit messages编写有帮助到我们，它也反映了一个开发人员是否是良好的协作者。

编写良好的Commit messages可以达到3个重要的目的：

加快代码view的流程
帮助开发人员编写良好的版本发布日志
让之后的维护者了解代码里出现特定变化和feature被添加的原因

目前，社区有多种 Commit message 的写法规范。来自Angular 规范是目前使用最广的写法，比较合理和系统化。建议使用如下：

Commit messages的基本语法

具体格式为:

# 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，详见案例。

Type的类别说明：

# 主要type
feat: 增加新功能
fix: 修复bug# 特殊type
docs: 只改动了文档相关的内容
style: 不影响代码含义的改动，例如去掉空格、改变缩进、增删分号
build: 构造工具的或者外部依赖的改动，例如webpack，npm
refactor: 代码重构时使用
revert: 执行git revert打印的message# 暂不使用type
test: 添加测试或者修改现有测试
perf: 提高性能的改动
ci: 与CI（持续集成服务）有关的改动
chore: 不修改src或者test的其余修改，例如构建过程或辅助工具的变动

Commit messages格式要求

# 标题行：50个字符以内，描述主要变更内容
#
# 主体内容：更详细的说明文本，建议72个字符以内。 需要描述的信息包括:
#
# * 为什么这个变更是必须的? 它可能是用来修复一个bug，增加一个feature，提升性能、可靠性、稳定性等等
# * 如何解决这个问题? 具体描述解决问题的步骤
# * 是否存在副作用、风险?
#
# 如果需要的话可以添加一个链接到issue地址或者其它文档

示例：

# fix：修复支付宝支付bug
#
# 1，修复支付完成后未查询支付状态问题
# 2，增加定时任务保证支付状态完整
#
# link：http://github.com/ftd/shopmall/issue001

注：如果一次改动内容较多，包含多个提交类型时，建议拆分成多个提交，分次提交，这样会更清晰。

Git Flow工作流

我们现在已经了解了Git的分支，包括分支有哪些类型，什么情况下使用什么类型的分支，以及提交的格式规范等。不过往往在一个团队人数较多，创建的分支也比较多的时候，还是会带来很多分支操作上的困扰。那有没有一个什么好的流程来规范大家呢，针对这些问题，建议大家使用Git Flow的工作流模式。

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 Flow的流程搞清楚后，我们下面开始实际的项目实战，假设我们现在有一个商城的项目，并且我们已经建好了Git仓库。

我们通过命令行和图形界面的方式分别向大家展示如何使用Git Flow工作流。

Git Flow 命令示例

开始 Feature

# 创建feature分支
git flow feature start ftd_20201018_wechatpay# 指定当前分支pull的源为develop
git branch --set-upstream-to=origin/develop feature/ftd_20201018_wechatpay

完成 Feature

# 发布feature
git flow feature publish ftd_20201018_wechatpay# 完成feature
git flow feature finish ftd_20201018_wechatpay

开始 Release

git flow release start v1.0_20201031

完成 Release

git flow release finish v1.0_20201031

开始 Hotfix

git flow hotfix start ftd_20201031_bugfix

完成 Hotfix

git flow hotfix finish ftd_20201031_bugfix

大家可以看到，简简单单几行命令就可以完成比较复杂的流程管理，如果对于命令行不太擅长的小伙伴还可以使用图形工具，这里推荐使用sourcetree，sourcetree也是著名的Git管理工具，可以大大方便我们对Git的操作和使用，下面就来介绍一下sourcetree中如何使用Git Flow。

注：以下内容为Windows版本的sourcetree为例，Mac类似。

初始化GitFlow

打开sourcetree，选择想使用Git Flow工作流的项目，在右上角点击Git工作流按钮，如下图所示：

随后会弹出对话框，可以选择产品分支，开发分支以及功能分支等，如下图所示：

点击确定后完成仓库的Git Flow初始化。

开始 Feature

点击右上角Git工作流，显示如图界面：

输入本次功能的名称，点击确定创建feature分支

可以看到本地已经有了新建的feature分支，如图所示：

然后就可以在该分支进行功能开发了。

完成 Feature

功能开发完成之后，还是点击右上角Git工作流，显示如图界面：

点击完成功能，如下图所示：

这里可以选择将该feature分支删除或保留，可以根据团队的规定来处理即可。

点击确定后，完成feature功能的开发。

至此该流程处理完毕。

开始 Release

同样的，点击右上角Git工作流，选择建立新的发布版本，显示如下：

输入发布版本名称，点击确定，完成release分支的创建。

此时可以看到已经创建的release分支，如下图所示：

完成 Release

测试通过后，可以进行release版本的发布，如下图所示：

输入该发布的标签信息，点击确定进行发布。

至此，我们已经完成了release的发布流程。

Hotfix

hotfix流程与上述流程操作方法类似，再次不再赘述，大家可以通过软件进行操作练习。

结语

好了，到这里，我们关于Git工作流的内容已经全部讲完啦，大家可以根据自己团队的需要进行使用和改进，以让团队的协作更加高效和规范。

如果你喜欢本文,

扫描二维码，关注「我是开发者FTD」公众号

关注开发，更关注开发者！