git代码分支管理策略

分支管理策略

参考 ：https://www.ruanyifeng.com/blog/2015/12/git-workflow.html

绍三种广泛使用的工作流程：

• Git flow

• Github flow

• Gitlab flow

一、Git flow

官方 https://nvie.com/posts/a-successful-git-branching-model/

分支特点 五大分支

主干分支:

具有无限生命周期的主要分支

1. master ：首先，代码库应该有一个、且仅有一个主分支。所有提供给用户使用的正式版本，都在这个主分支上发布,和线上补丁的修复。
2. develop： 主分支只用来分布重大版本，日常开发应该在Develop分支上完成。

其他临时分支/支持分支

一旦完成开发，它们就会被合并进develop或master，然后被删除。

1. 功能分支（feature branch）:最后必须合并到 develop ；用于为即将发布或遥远的未来版本开发新功能
2. 补丁分支（hotfix branch） :最后 必须合并到 master 和 develop ;用于修复线上bug
3. 预发分支（release branch）：develop 测试的差不多后 checkout release

流程特点

1. 从 master checkout develop 分支
2. develop 进行新功能的开发
3. develop -> 预发分支 relaese 版本进行 最后的测试
4. relaese -> 合并到 master,master 打一个 tag 稳定包 发布上线。
5. relaese -> 合并到 delelop 保留在发布分支中所做的更改
6. 线上的tag 包有问题，master -> hotfix 进行修复。
7. hotfix 进行修复完成 hotfix 合并到 master，和 develp 打一个 tag 包 发布上线 。删除 hotfix
8. 清理掉 hotfix relaese ，feature 登录分支

git flow更多的的特性和建议：

1. 注意：功能分支通常仅存在于开发人员存储库中，而不存在于origin.(远程版本库)

   # 从 develop 切 一个 新分支 myfeature
   $ git checkout -b myfeature develop 
   # 功能开发完成后，把 myfeature 合并到 develop 并推送
   $ git checkout develop 
   $ git merge myfeature
   $ git push origin develop
   

2. 没有分支保护概念，任何开发人员都可以 对 develop 进行合并，和推送

3. 去中心化，每个开发人员一个单独一个分支开发，或者 两个或者多个一起开发一个大的新功能

4. 提出了主干分支，支持分支

二，GitHub flow

官方 https://docs.github.com/cn/get-started/quickstart/github-flow#address-review-comments

分支特点

1. 一个 main 长期分支
2. n 多个临时的 feature （功能）分支

流程特点

1. 新建分支（Create a branch）；从main 主干分支 checkout 一个 xxx-feature (每人一个/或者多个人一个)分支
2. 提交修改（Mack changes）；在 xxx-feature 完成你功能开发
3. 创建合并请求（Create a Pull Request）；把 xxx-feature 分支 合并到 main
4. 代码评审（Address review comments）-代码管理员进行 code reviwe 和评审和提出代码建议，可以通过，也可以拒绝这次合并请求
5. 合并（审核通过或者重新修改后 merge your pull request）-评审通过后合并；
6. 删除分支（delete your branch）；删除 xxx-feature 分支

特点：

1. 是Git flow的简化版。它只有一个长期分支，就是main， 和临时功能分支 feature. 对于"持续发布"的产品，可以说是最合适的流程。以部署为中心的开发模式

2. Pull Request 阶段可以进行 code review,和一些自动检测，质量会得到很大的保证

3. 但是官方没有对多主干分支数量作出说明。一个分支不够用

4. 要保证高质量，对于贡献者的素质要求很高，换句话说，如果代码贡献者素质不那么高，质量就无法得到保证。

5. github flow这一套对于库、框架、工具这样并非最终应用的产品来说，没问题，但是，如果如果一个产品是“最终应用”，github flow可能就不合适了。

三, Gitlab flow

官网 https://docs.gitlab.com/ee/topics/gitlab_flow.html#introduction-to-gitlab-flow

1. Gitlab flow 是 Git flow 与 Github flow 的综合。它吸取了两者的优点，既有适应不同开发环境的弹性，又有单一主分支的简单和便利。它是 Gitlab.com 推荐的做法。

2. Gitlab flow 的最大原则叫做”上游优先”（upsteam first），即只存在一个主分支master，它是所有其他分支的”上游”。只有上游分支采纳的代码变化，才能应用到其他分支。

3. 对于”持续发布”的项目，它建议在master分支以外，再建立不同的环境分支。比如，”开发环境”的分支是 master，”测试环境”的分支是pre-production，”生产环境”的分支是 production。

分支特点

1. 只有一个主分支 master;
2. 上游优先 upsteam first，只有上游分支采纳的代码变化，才能应用到其他分支。 必须先合并到 master 后才是其他
3. 可以建立其他不同环境的分支，如： pre-production，production
4. 版本发布流程，不是采用tag 的形式，而是从master 创建出分支 比如2-3-stable、2-4-stable等等。注意master分支上的代码是稳定。
5. 线上bug 修复 重从 master 创建修复版本 后， git cherry-pick commitId 到 master ,再部署对应的环境

分支流程

1. 用master分支创建一个开发新功能的分支 feature-xxx
2. 开发完成 feature-xxx 请求合并到 master
3. 发布 master 进行自测
4. 自测有bug 再从 master 创建修复分支，然后再请求合并，重复这个过程直到自测通过
5. 预发布： 用master分支创建出一个分支，命名为pre-production。
6. 上游优先- 预发布有bug 从 pre-production 创建分支 修复 fixbug .
7. fixbug 修复后 先合并 到master ,master 发布到 自测环境，通过后再 合并到 pre-production 再发布到 发布环境
8. pre-production 创建 分支 production 部署到正式环境
9. 上游优先 -线上bug 修复 从 production 创建分支 fixbug 修复后 合并到 master,master 发布到 自测， 合并到 pre-production 发布到 预发布环境进行测试。最后才是 合并到 production

特点：

1. 每一次的合并就有一次发布和 测试
2. 下游bug 的修复 必须 从bug 版本创建修复分支，修复后 优先合并第一级上游 ,每一次合并都意味着要发布和测试 通过后 再合并 二级上游， 依次类推

Gitlab 推荐的

1. 多使用rebase,代替 merge ,使用 rebase 合并自己的提交
2. 减少功能分支中的合并提交
3. 经常提交和经常推送
4. 主干分支保护,不能直接推送，必须合并请求 pull request

四，一些优秀的功能

1. Pull Request 提交请求 （Gitlab里面叫做 Merge Request）:提供代码审核，自动代码质量检查和自动化测试
2. Protected branch：分支保护，不是每个人都可以修改主干分支，新功能必须得到审核/code view
3. 合并分支时，merge ,多用 rebase ；修改记录可以展示一条直线

五，推荐的git规范

综合上面的介绍，我们决定采用gitlab flow，按照版本发布的模式实施，具体来说：

1. 新的迭代开始，所有开发人员从主干dev 拉个人分支开发特性, 分支命名规范 dev-name
2. 开发完成后，在迭代结束前，发起 pull request 合入 dev 分支
3. dev 分支 合并后，自行 cicd到dev环境进行自测
4. 开发自测通过后，从master拉取要发布的分支，release，将这个分支部署到测试环境进行测试
5. 测出的bug，通过从release拉出分支 release-name 进行修复，修复完成后，发起 pull request 合入release
6. 正式发布版本，如果上线后，又有bug，根据5的方式处理
7. 等发布版本稳定后，将release反合入主干 dev