深度分析：项目代码分支管理实战指南

从22年10月到24年1月，一直忙于项目建设，终于顺利投产，截止现在，项目需求、项目缺陷持续推进，越发感觉到代码分支管理的重要性。从项目投产最初，一直试图通过查询各种资料，想找到一种合适的策略进行分支管理，但可能是资料过于繁杂未能发现有实际落地价值的资料。通过诸多资料，仅知道了有git工作流，知道有main分支、develop分支、feature分支、bugfix分支、release分支，也通过Sourcetree试用了git工作流的相关命令，但是与实际项目结合，就感觉很奇怪，脑海中有各种各样的疑问。

• 为什么我的新需求要在develop分支创建呢？如果我有需求A已经完成了，按照git flow feature finish命令逻辑会将需求A代码并入到develop内，万一之前并入的分支比我这次的新需求投产晚呢，那我基于develop创建的需求B分支夹杂有需求A的代码，投产怎么拆分呢？
• 我git flow feature start后什么时候进行finish呢，是单元测试过了还是集成测试过了还是业务测试过了呢？
• 这些命令应该在什么阶段进行呢？每个项目阶段应该怎么执行呢？
• 我需求开发完了后发现了缺陷应该在什么分支改呢，因为前面搞不明白，就会遇到这个问题

基于种种疑问，选择了自己从头分析，分析项目遇到的实际问题有哪些，如每个项目阶段代码分支如何使用、投产代码如何确认范围、codereview如何找全变更范围、什么阶段应该执行什么命令。基于自己遇到的问题，结合了解到一般的分支划分方式，制定了适用于我们项目的git分支管理要求，也可能适用于大家，分享共同交流一下。

阅读须知

文章内采用命令及注释方式阐述了分支具体使用用法，不可忽略注释。

分支分类

参考外部资料了解到的内容，将git分支分为5类：

main分支为生产分支，内容与生产完全一致（永久分支，生产最新代码）

develop分支为测试环境版本分支（永久分支）

feature/feature_xxxxx 为需求分支（临时分支）

bugfix/bugfix_xxxxx 为缺陷修复分支（临时分支）

release为生产发布分支/准生产分支（永久分支，上线投产包从release分支输出，在无新需求计划投产情况下release分支与main分支基本一致，有上线变更时，release分支比main分支高一个版本，投产验证完成后main与release再度一致）

项目初始状态

git init后，项目仅有main分支，基于main分支创建develop分支、release分支

#查看当前分支，仅包含main
git branch

#创建develop分支及release分支，执行时git branch结果显示当前选中分支为main分支（git bash带有颜色显示，会将当前分支在目录后追加，如：/d/mp-main/Git分支管理 (main)）
git branch develop
git branch release
#再次git branch时展示main分支、develop分支、release分支

分支动态实战

场景1：需求feature1从开始到投产

1. 需求编码开始

   #切换main分支
   git switch main
   
   #创建需求分支feature1并切换至需求分支
   git switch -c feature/feature1
   
   #如涉及多人开发，则将需求分支推送至远程仓库如gitlab
   git push origin feature/feature1
   

   Coding：在新创建feature1分支进行编码

   //原始代码
   package com.company;
   
   public class Test {
       public static void main(String[] args) {
           System.out.println("Hello");
       }
   }
   

   //需求feature1开发后代码
   package com.company;
   
   public class Test {
       public static void main(String[] args) {
           System.out.println("Hello");
           feature_1();
       }
   
       public static void feature_1(){
           System.out.println("feature_1");
           System.out.println("1+1="+2);
           System.out.println("1+2="+3);
           System.out.println("1+3="+3);
       }
   }
   

   #在需求分支内开发业务代码,coding......
   
   #每日提交
   git add *
   git commit -m "feature1开发完成"
   

2. Test：单元测试，在当前feature1分支进行单元测试及问题修改工作

3. 集成测试、业务测试

   #将需求分支合并至devlope分支，部署至测试环境进行测试
   git switch develop
   git merge feature/feature1
   
   #使用develop分支进行测试环境打版
   

4. 测试bug修复

   #测试发现bug，修改bug
   
   #在对应的需求分支修改缺陷，目的为可通过单一分支汇聚所有这项需求的改造内容
   git switch feature/feature1
   
   #缺陷修复，coding
   
   #缺陷修复提交
   git add *
   git commit -m "feature1缺陷修复"
   
   #缺陷修复打版：将修复代码并入测试环境分支
   git switch develop
   git merge feature1/feature1
   
   #使用develop分支进行测试环境打版
   

5. 投产发布前CodeReview

   #基于feature分支及release分支差异进行codereview，可通过gitlab可视化界面或者是命令开发工具查看
   

6. 投产包准备，CoreReview通过则进行投产包准备，若不通过需整改，则继续在feature分支修改测试

   #切换release分支：基于release分支创建发布版本
   git switch release
   git merge feature/feature1
   

7. 投产：基于release分支进行投产包打包，打包完成后生产环境验证，验证无误投产完成

8. 发布完成，一般为投产后D+1日进行操作

   #基于release投产完成后，将release分支并入main分支、其余需求分支、bugfix分支，如：
   
   #main分支保鲜，始终与生产一致
   git switch main
   git merge release
   
   git switch feature2
   git merge release
   ...
   
   #删除feature1本地分支
   git branch -d feature1
   
   #通过gitlab界面删除远程分支，可视化界面操作，百度一搜即可知道
   
   #通过gitlab tag标记已发布版本，可视化界面操作，百度一搜即可知道，Tag名称标准可自行制定，如P_20240527，如果是APP版本或者小程序，可按照对外版本名称命名，如v1.0.1
   

场景2：bug从发现到投产

非紧急缺陷修复可按照需求分支过程推进，仅分支名称不一致（feature/feature1变成了bugfix/bug1），紧急情况可能出现创建分支修改后直接发布的情况，中间区别主要为测试阶段的分支变化，到投产发布及投产后动作与需求保持一致

非紧急缺陷分支变化过程见需求分支变化过程

紧急缺陷修复git分支管理示例

1. 发现缺陷

   git switch main
   git switch -c bugfix/bugfix_20240527
   

2. 缺陷修复

   #coding......
   
   git add *
   git commit -m "xxx缺陷修复"
   

3. 缺陷修复投产

   #基于bugfix分支release分支差异进行codereview后，merge bugfix分支到release分支
   git switch release
   git merge bugfix/bugfix_20240527
   

4. 发布完成

   #基于release投产完成后，将release分支并入其他所有分支，如main、develop、其他需求分支等：
   
   #main分支保鲜，始终与生产一致
   git switch main
   git merge release
   
   git switch develop
   git merge release
   
   git switch feature/feature2
   git merge release
   ...
   
   #删除feature1本地分支
   git branch -d bugfix/bugfix_20240527
   
   #通过gitlab界面删除远程分支，可视化界面操作，百度一搜即可知道
   
   #通过gitlab tag标记已发布版本，可视化界面操作，百度一搜即可知道，Tag名称标准可自行制定，如P_20240528，如果是APP版本或者小程序，可按照对外版本名称命名，如v1.0.1
   

场景3：多需求、Bug同行

1. 一个新需求则基于main分支创建一个feature分支

2. 一个bug则基于main分支创建一个bugfix分支

3. 单需求投产则谁先投产谁将投产内容并入release分支，多个同时投产则创建临时release_temp分支，同时merge所有本次投产内容，并在临时分支解决冲突内容，解决后将release_temp分支提交merge请求并入release分支进行投产版本准备

4. 投产完成后将release分支并入main分支及各feature分支、develop分支，然后删除已投产临时feature分支、bugfix分支及release_temp分支

5. 投产完成基于gitlab标记tag

6. #实操模拟
   
   #1. 20240527新需求feature1需开发
   git switch main
   git switch -c feature/feature1
   #coding...
   
   #2. 20240601新需求feature2需开发
   git switch main
   git switch -c feature/feature2
   
   #3. 20240620两个需求进行测试阶段
   git switch develop
   git merge feature/feture1
   git merge feature/feture2
   #develop分支打包测试环境
   
   #4. 20240701需求feature2投产
   git switch relase
   git merge feature/feature2
   #基于release分支创建发布包
   
   #5. 发布包验证通过，准备发布投产，发现紧急缺陷bug1
   git switch main
   git switch -c bugfix/bug1
   
   #6. 需求feature2和bug1同步投产
   git switch relase
   git merge bugfix/bug1
   
   #7. 基于最新的release分支准备发布包
   
   #8. 发布验证无误，将release并入main、develop、feature1
   git switch main
   git merge release
   
   git switch develop
   git merge release
   
   git switch feature/feature1
   git merge relase
   
   #9. 删除已投产临时分支
   git branch -d feature/feature2
   git branch -d bugfix/bug1
   
   #10. tag标记main，完成一次分支管理
   

注意事项

在进行git分支管理时，需将main分支、release分支纳入gitlab保护范围，仅允许merge，不允许push，在进行投产时，开发人员提交merge request到有权审核人，codereview通过后同意merge，然后打包投产验证。