GitFlow简介

GitFlow简介

---

GitFlow工作流定义了一个围绕项目发布的严格分支模型，它为不同的分支分配了明确的角色，并定义分支之间何时以及如何进行交互。

---

分支说明

1. master分支：存储正式发布的产品，master分支上的产品要求随时处于可部署状态。master分支只能通过与其他分支合并来更新内容，禁止直接在master分支进行修改。
2. develop分支：汇总开发者完成的工作成果，develop分支上的产品可以是缺失功能模块的半成品，但是已有的功能模块不能是半成品。develop分支只能通过与其他分支合并来更新内容，禁止直接在develop分支进行修改。
3. feature分支：当要开发新功能或者试验新功能时，从develop分支创建一个新的feature分支，并在feature分支上进行开发。开发完成后，需要将该feature分支合并到develop分支，最后删除该feature分支。
4. release分支：当develop分支上的项目准备发布时，从develop分支上创建一个新的release分支，新建的release分支只能进行质量测试、bug修复、文档生成等面向发布的任务，不能再添加功能。这一系列发布任务完成后，需要将release分支合并到master分支上，并根据版本号为master分支添加tag，然后将release分支创建以来的修改合并回develop分支，最后删除release分支。
5. hotfix分支：当master分支中的产品出现需要立即修复的bug时，从master分支上创建一个新的hotfix分支，并在hotfix分支上进行bug修复。修复完成后，需要将hotfix分支合并到master分支和develop分支，并为master分支添加新的版本号tag，最后删除hotfix分支。

图片来源：https://fpy.cz/pub/slides/git-workshop/#/step-21

---

分支命名规范

1. master分支：master分支只有一个，名称即为master。
2. develop分支：develop分支只有一个，名称即为develop。
3. feature分支：feature_<版本号>_<功能名>，例如：feature_v1.0.0_login。
4. release分支：release_<版本号>，例如：release_v1.0.0。
5. hotfix分支：hotfix_<版本号>_<问题简述>，例如：hotfix_v1.0.0_username_not_support_chinese。

说明：使用尖括号（<>）括起的内容是需要根据情景进行替换的内容，下同。

---

提交信息规范

提交信息应该描述“做了什么”和“这么做的原因”，必要时还可以加上“造成的影响”，主要由3个部分组成：Header、Body和Footer。提交信息的第一行会被最为Header，其余行会被作为Body（Footer以特定关键字标识）。

---

Header

Header部分只有1行，格式为(): 。

type用于说明提交的类型，共有8个候选值：

1. feat：新功能（feature）
2. fix：问题修复
3. docs：文档
4. style：调整格式（不影响代码运行）
5. refactor：重构
6. test：增加测试
7. chore：构建过程或辅助工具的变动
8. revert：撤销以前的提交

scope用于说明提交的影响范围，内容根据具体项目而定。

subject用于概括提交内容。

---

Body

Body部分是对本次提交的详细描述，可以分成多行。

---

Footer

Footer部分只用于两种情况：不兼容变动和关闭issue。如果本次提交的代码与上一版本不兼容，则Footer部分要以BREAKING CHANGE开头，后面添加对变动的描述、变动理由和迁移方法。如果本次解决了某个issue，那么可以在Footer部分关闭这个issue，格式为Closes #，也可以一次关闭多个issue，多个issue之间使用半角逗号分隔。

说明：revert与其他的提交类型略有不同。revert的Header中没有scope和subject部分，其格式为revert: <被撤销的提交的Header>；revert的Body部分格式也是固定的，需要写成This reverts commit <被撤销的提交的Hash标识码>.

本节参考资料：Angular - Commit Message Guidelines

---

注意事项

• 开始工作前一定要保证选择了正确的分支。
• 开始工作前定义好要做的事情，这将有助于确定从哪个分支开始工作和确定新分支的名称。
• 工单需要包含的内容：
  • 问题：大致描述要解决的问题
  • 原因：为什么要这样做
  • 测试：如何验证问题已得到解决
• Git应该是一个用于记录结果而不是保存工作的工具。这意味着，应该在完成了一个功能模块时才进行提交，而不是每做一点改动就立即提交。过于密集的提交将会使重要的信息分散在大量无意义的信息中，增加管理的难度。