当参与一个工程的开发的人多了起来以后，就需要对代码的分支进行管理，目前常见的有两种分支模型，话不多说我们一一介绍。
一、Git Flow 分支模型
2010 年 1 月份提出的一种 Git 分支模型，后被业界所认可，很多软件开发团队都在使用该 git 分支模型进行代码提交和版本控制。
1.1 master 和 develop 分支
在 git flow 模型中，master 和 develope 分支是远程仓库中的常驻分支，是最根本的两个分支。
如果只有两个分支，那么就是在 develop 上进行开发，开发完成后合并到 master 上，并且打上版本标签。
(图片出自网络)
这是 git flow 的核心要点，即 master 上的每一次 merge 都是一次版本更新，从而做到版本控制。
只能通过合并的方式更新master代码，不能在该分支上直接开发。
1.2 辅助/补充 分支
光是有 development 肯定是不够的，一旦开发人员多了、版本需求较大要拆分成多个功能时就会造成代码开发和代码提交上的混乱，这也是这次引入某种规范的
git 版本管理模型的原因。
git flow 提出除了上述的两个主要分支外，还需要一些 supported branches：
-
Feature 分支
-
Release 分支
-
Hotfix 分支
1.2.1 Feature 分支
用于开发新功能的分支，主要用于实现新功能和进行相关的测试和开发工作。在 Feature 分支上进行的修改包括新功能的添加和相关的测试和开发工作。
一般从 develop 分支检出，但一定是合并到 develop 分支；
原则上命名可以是 master, develop, release-*, or hotfix-* 以外的所有名字，但建议 feature/* 格式。
流程：
- 创建新 feature 分支：
shell
$ git checkout -b feature/myfeature develop - 合并到 develop 分支：
shell
$ git checkout develop
$ git merge --no-ff feature/myfeature
$ git branch -d feature/myfeature
$ git push origin develop 上面是 git flow 给出的建议，实际上操作时并不一定要这么做，比如我们往往希望在网页端通过 Merge Request (Pull Request) 的方式去合并代码------有时候需要 Code Review。
并且也不需要立即把 feature 删掉，因为现在要开发一个功能，往往要在 feature 上开发，合并到 develop 上测试，这不可能一蹴而就。
在本地合并的时候，最好带着 --no-ff参数；gitlab 中的 Merge Request 在完成合并后也是自动执行 git merge --no-ff，会将在feature/myfeature 中的多次 commit 转为一次，从而想要回滚向上回滚一次即可（github 中的 PR 同理）。所以我个人建议最好在网页端以 Merge Request 的方式进行代码合并。
带不带该参数的merge比较：
Feature 分支的生命周期，如图所示：
那么当测试完成后，如何发布呢？
1.1.2 Release 分支
用于准备发布新版本的分支，是在最后一刻进行微调和修正。在 Release 分支上进行的修改只包括小的 bug 修复和文档更新等，不包括新功能的添加。
Release 分支通常从 develop 分支上创建，完成后会合并到 master 分支和 develop 分支上；命名建议为 release/*。
release 分支流程图：
⚠️⚠️⚠️ 具体操作的步骤略，几个注意点：
-
一般 release 分支向 master 合并完成后，要打上标签，从而做到版本管理；
-
本地 master 分支下使用 "git tag -a 版本号"
-
或者在网页端进行 tag 的创建------建议采用该方法。
-
合并到 master 后，也别忘记合并回 develop 分支中
-
当然当从 develop 中检出 release 后再无任何修改，就不需要这一步了
-
合并时仍采用 --no-ff 或者 MR 的方式。
1.1.3 Hotfix 分支
用于修复线上紧急 bug 的分支，主要用于快速响应线上问题和进行紧急修复工作。在 Hotfix 分支上进行的修改只包括紧急 bug 修复和文档更新等，不包括新功能的添加。
Hotfix 分支通常从 master 分支上创建，完成后会合并到 master 分支和 develop 分支上；命名建议为 hotfix/* 。
hotfix 分支流程图：
⚠️⚠️⚠️ 具体操作的步骤略，几个注意点：
-
合并时仍采用 --no-ff 或者 MR 的方式
-
合并到 Master 后，实际上版本号应该发生变动，需要重新打标签
祝大家很少用到该分支。
1.3 相关文章
上述文章中的内容，大体出自这两篇文章：
Git Flow - A successful Git branching model
www.cnblogs.com/cnblogsfans...
二、GitHub Flow 分支模型
正如前文中说，Vincent Driessen 于 2010 年 1 月提出了 Git Flow，但在 2020 年 5 月份的时候，他谈到他不希望 git flow 成为一种教条，必须死板地去遵守该规范，当软件需要持续交付、快速迭代的时候，他建议可以采用 GitHub flow 的 Git 分支管理风格。
下面以一个新功能的开发为例，简单介绍整个流程：
shell
git checkout main
git pull --rebase
# 基于main分支的 checkout 分支进行某个新功能的开发
git checkout -b feature/personal-dev 
上面是一个 feature 分支的示例，除此外还有 bugfix、refactor 等分支概念。
GitHub Flow 简单、灵活和快速迭代，分支管理更加简单和清晰，最重要的是各自的 feature 分支发布线上不需要相互等待。
但缺少版本管理的概念，适合快速迭代的项目。
实际上我个人更倾向于 GitHub Flow 的分支模型，其次以上两种模型只是两种常见的模型，两者也可以进行融合互补，不必要太拘泥于一种，可以灵活使用。