工作流
Git 最强大的就是其分支功能，但是如何分支才能更有效的提高开发效率，减少因为代码合并带来的问题，需要一个分支模型来规范，其实在 Git Flow 出现之前，已经有分支模型理论流程，当时是根据此理论，手动的按照规范操作分支，Git Flow 出现之后，将一部分操作流程简化为命令，并没有增加新的功能，只是简化了操作。
import React from 'react';
import img from '../../assets/git/git-flow.png';
export default () => <img alt="Git Flow" src={img} width="640" />;
统一团队的 Git 工作流，包括分支使用、Tag 规范、Issue 等
统一团队的 Git Commit 日志标准，便于后续代码 Review，版本发布以及日志自动化生成
分支管理
Git Flow 管理方式把项目分为 5 条线，通常会是下面的管理方式。
- Master：作为稳定主分支，用于部署生产环境的分支，长期有效。不可以在此分支进行任何提交，只能接受从 Hotfix 分支或者 Release 分支发起的 Merge Request，该分支上的每一个提交都对应一个 Tag 提交标签。
- Develop：开发主分支，长期有效。不可以在此分支上做任何提交，只接受从 Feature 分支发起的 Merge Request。所有的 Alpha Release 都应该在这个分支发布。
- Feature：功能分支，生命周期为产品迭代周期，每个分支对应一期的需求。开发新功能时，以 develop 为基础创建 feature 分支。分支命令规则
feature/user_module、feature/cart_module。可以mergeRelease 分支的代码，生命周期结束后，需要merge回 Develop 分支。方式需要采用 Merge Request。 - Release：发布分支，声明周期从新需求的预发布到正式发布，每一个分支对应一个新版本的版本号。只可以从 Develop 分支 Kick Off。声明周期结束后，需要 Merge 回 Master 及 Develop 分支，方式同样需要采用 Merge Request。所有的 Beta Release 均需要在该分支发布。
- Hotfix：热修复分支，生命周期对应一个或者多个需要紧急修复并上线的 Bug，每一个分支对应一个小版本号。只可以从 Master 分支进行 Kick Off。声明周期结束后，需要 merge 回 Master 分支和 Develop 分支，方式当然也是采用 Merge Request。
在研发流程中分支通常对应不同的部署环境：
tag-> 生产环境（Production）master-> 预发布/灰度环境（Pre-Production/Staging）develop-> 测试环境（Test）
实际上，如果你熟悉 Git 的话，你会很快发现上面的管理方式会存在历史提交非常混乱的缺点，但觉得不失为一个 Git 分支管理的经典。实际上，我们可以用 rebase 去替换 merge 让 commit 看起来更加清晰。对 rebase 和 merge 的优劣对比这里暂不做讲解，感兴趣的可以直接 Google 搜索。
提交规范
业界使用比较广泛的代码提交规范是：Angular Git Commit Guidelines
<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>
占位标签解析：
type：代表某次提交的类型，比如是修复了 BUG 还是新增了 Featurescope：说明 Commit 影响的范围，根据项目而定。例如在业务项目中可以依据菜单活功能模块划分；如果是组件库开发，则可以依据组件划分。subject：Commit 的简短描述body：提交代码的详细描述footer：如果代码的提交是不兼容变更或关闭缺陷，则 Footer 必需，否则可以省略
提交类型
| 类型 | 说明 |
|---|---|
| feat | 特性：新功能 |
| fix | 修复：修复错误 |
| docs | 文档：文档修改（比如 README.md、CHANGELOG、CONTRIBUTE 等等） |
| style | 格式：格式修改（不影响代码运行的变化，如空白、格式化、缺少分号等） |
| refactor | 重构：代码重构（既不新增功能，也不是修改错误的代码变动） |
| perf | 优化：改进性能的代码更改 |
| test | 测试：测试用例，包括单元测试、集成测试（添加缺失测试或更正现有测试） |
| chore | 工具：构建过程或辅助工具的变动（或者增加依赖库、工具等） |
| revert | 回滚：回滚到上一个版本 |
示例：
特性: 添加头像功能
特性: 添加收藏功能
修复: 在 Android 机器上传崩溃问题解决
文档: 修改 README，增加了使用说明
优化: 首页图片加载缓慢优化
重构: 对头像功能进行封装重构
格式要求
Git Commit 代码提交的标题、内容的格式要求。
# 标题行：50个字符以内，描述主要变更内容
#
# 主体内容：更详细的说明文本，建议72个字符以内。 需要描述的信息包括:
#
# * 为什么这个变更是必须的? 它可能是用来修复一个bug，增加一个feature，提升性能、可靠性、稳定性等等
# * 他如何解决这个问题? 具体描述解决问题的步骤
# * 是否存在副作用、风险?
#
# 如果需要的话可以添加一个链接到 issue 地址或者其它文档
辅助工具
用于约束 commit 的插件工具：
commitizen：一个格式化 commit message 的工具commitlint：检查 commit message 是否符合常规的提交格式conventional-changelog-cli：每次 commit 后产生 CHANGELOG 日志文件@commitlint/config-conventional：一些常规的 commitlint 规则，如果不满足，将产生一个非零的退出代码，退出当前执行程序
辅助工具：
husky：Git Hooks
标签版本管理
项目标签版本管理的规范有多种多样，这里我们讲述的是 版本语义化版本 2.0.0 的规范。
版本格式：主版本号.次版本号.修订号，版本号递增规则如下：
- 主版本号：当你做了不兼容的 API 修改
- 次版本号：当你做了向下兼容的功能性新增
- 修订号：当你做了向下兼容的问题修正
先行版本号及版本编译元数据可以加到 主版本号.次版本号.修订号 的后面，作为延伸。
命名规范：
- 新功能开发使用第二位版本号，BUG 修复使用第三位版本号
- 首版本号是全新的功能类，功能模块上线才做的调整
参考资料：
- 工作流
- 版本控制
- 更新日志
钩子
Git 钩子（hooks）是在 Git 仓库中特定事件（certain points）触发后被调用的脚本。通过钩子可以自定义 Git 内部的相关（如 git push）行为，在开发周期中的关键点触发自定义的行为。Git 含有两种类型的钩子：客户端的和服务器端的。客户端钩子由诸如提交和合并这样的操作所调用，而服务器端钩子作用于诸如接收被推送的提交这样的联网操作。
Git 钩子最常见的使用场景包括根据仓库状态改变项目环境、接入持续集成工作流等。由于脚本是可以完全定制，所以你可以用 Git 钩子来自动化或者优化你开发工作流中任意部分。
作用域
Git 钩子是对本地仓库相关操作影响，对于任何 Git 仓库来说钩子都是本地的，初始的钩子都是从 Git 默认模板目录中自动安装。
在开发团队中为了保持团队所使用钩子一致，维护起来算是比较复杂的，因为 .git/hooks 目录不随你的项目一起拷贝，也不受版本控制影响。
客户端钩子
客户端钩子分为很多种。 下面把它们分为：提交工作流钩子、电子邮件工作流钩子和其它钩子。
需要注意的是，克隆某个版本库时，它的客户端钩子 并不 随同复制。 如果需要靠这些脚本来强制维持某种策略，建议你在服务器端实现这一功能。
提交工作流钩子
前四个钩子涉及提交的过程。
pre-commit
pre-commit 钩子在执行 git commit 命令时，键入提交信息前运行。 它用于检查即将提交 commit 的快照，例如，检查是否有所遗漏，确保测试运行，以及核查代码。 如果该钩子以非零值退出，Git 将放弃此次提交，不过你可以用 git commit --no-verify 来绕过这个环节。 你可以利用该钩子，来检查代码风格是否一致（运行类似 lint 的程序）、尾随空白字符是否存在（自带的钩子就是这么做的），或新方法的文档是否适当。
prepare-commit-msg
prepare-commit-msg 钩子在启动提交信息编辑器之前，默认信息被创建之后运行。 它允许你编辑提交者所看到的默认信息。 该钩子接收一些选项：存有当前提交信息的文件的路径、提交类型和修补提交的提交的 SHA-1 校验。 它对一般的提交来说并没有什么用；然而对那些会自动产生默认信息的提交，如提交信息模板、合并提交、压缩提交和修订提交等非常实用。 你可以结合提交模板来使用它，动态地插入信息。
commit-msg
commit-msg 钩子接收一个参数，此参数即上文提到的，存有当前提交信息的临时文件的路径。 如果该钩子脚本以非零值退出，Git 将放弃提交，因此，可以用来在提交通过前验证项目状态或提交信息。常用于校验提交说明是否标准。
post-commit
post-commit 钩子在整个提交过程完成后运行。 它不接收任何参数，但你可以很容易地通过运行 git log -1 HEAD 来获得最后一次的提交信息。 该钩子一般用于邮件通知、提醒之类的事情。
电子邮件工作流钩子
你可以给电子邮件工作流设置三个客户端钩子。 它们都是由 git am 命令调用的，因此如果你没有在你的工作流中用到这个命令，可以跳到下一节。 如果你需要通过电子邮件接收由 git format-patch 产生的补丁，这些钩子也许用得上。
pplypatch-msg
第一个运行的钩子是 applypatch-msg 。 它接收单个参数：包含请求合并信息的临时文件的名字。 如果脚本返回非零值，Git 将放弃该补丁。 你可以用该脚本来确保提交信息符合格式，或直接用脚本修正格式错误。
下一个在 git am 运行期间被调用的是 pre-applypatch 。 有些难以理解的是，它正好运行于应用补丁 之后，产生提交之前，所以你可以用它在提交前检查快照。 你可以用这个脚本运行测试或检查工作区。 如果有什么遗漏，或测试未能通过，脚本会以非零值退出，中断 git am 的运行，这样补丁就不会被提交。
post-applypatch
post-applypatch 运行于提交产生之后，是在 git am 运行期间最后被调用的钩子。 你可以用它把结果通知给一个小组或所拉取的补丁的作者。 但你没办法用它停止打补丁的过程。
其他客户端钩子
服务端钩子
除了客户端钩子，作为系统管理员，你还可以使用若干服务器端的钩子对项目强制执行各种类型的策略。 这些钩子脚本在推送到服务器之前和之后运行。 推送到服务器前运行的钩子可以在任何时候以非零值退出，拒绝推送并给客户端返回错误消息，还可以依你所想设置足够复杂的推送策略。
pre-receive
处理来自客户端的推送操作时，最先被调用的脚本是 pre-receive。 它从标准输入获取一系列被推送的引用。如果它以非零值退出，所有的推送内容都不会被接受。 你可以用这个钩子阻止对引用进行非快进（non-fast-forward）的更新，或者对该推送所修改的所有引用和文件进行访问控制。
update
update 脚本和 pre-receive 脚本十分类似，不同之处在于它会为每一个准备更新的分支各运行一次。 假如推送者同时向多个分支推送内容，pre-receive 只运行一次，相比之下 update 则会为每一个被推送的分支各运行一次。 它不会从标准输入读取内容，而是接受三个参数：引用的名字（分支），推送前的引用指向的内容的 SHA-1 值，以及用户准备推送的内容的 SHA-1 值。 如果 update 脚本以非零值退出，只有相应的那一个引用会被拒绝；其余的依然会被更新。
post-receive
post-receive 挂钩在整个过程完结以后运行，可以用来更新其他系统服务或者通知用户。 它接受与 pre-receive 相同的标准输入数据。 它的用途包括给某个邮件列表发信，通知持续集成（continous integration）的服务器， 或者更新问题追踪系统（ticket-tracking system） —— 甚至可以通过分析提交信息来决定某个问题（ticket）是否应该被开启，修改或者关闭。 该脚本无法终止推送进程，不过客户端在它结束运行之前将保持连接状态， 所以如果你想做其他操作需谨慎使用它，因为它将耗费你很长的一段时间。
参考资料：