从22年10月到24年1月，一直忙于项目建设，终于顺利投产，截止现在，项目需求、项目缺陷持续推进，越发感觉到代码分支管理的重要性，从项目投产最初，一直试图通过查询各种资料，想找到一种合适的策略进行分支管理，奈何可能是资料过于繁杂未能发现有实际落地价值的资料，通过诸多资料，仅知道了有git工作流，知道有main分支、develop分支、feature分支、bugfix分支、release分支，也通过Sourcetree试用了git工作流的相关命令，但是与实际项目结合，就感觉很奇怪，脑海中有各种各样的疑问，诸如：
- 为啥我的新需求要develop分支创建呢，如果我有需求A已经finish了，按照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分支
需求编码开始
#切换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开发完成"
Test：单元测试，在当前feature1分支进行单元测试及问题修改工作
集成测试、业务测试
#将需求分支合并至devlope分支，部署至测试环境进行测试
git switch develop
git merge feature/feature1
#使用develop分支进行测试环境打版
测试bug修复
#测试发现bug，修改bug
#在对应的需求分支修改缺陷，目的为可通过单一分支汇聚所有这项需求的改造内容
git switch feature/feature1
#缺陷修复，coding
#缺陷修复提交
git add *
git commit -m "feature1缺陷修复"
#缺陷修复打版：将修复代码并入测试环境分支
git switch develop
git merge feature1/feature1
#使用develop分支进行测试环境打版
投产发布前CodeReview
#基于feature分支及release分支差异进行codereview，可通过gitlab可视化界面或者是命令开发工具查看
投产包准备，CoreReview通过则进行投产包准备，若不通过需整改，则继续在feature分支修改测试
#切换release分支：基于release分支创建发布版本
git switch release
git merge feature/feature1
投产：基于release分支进行投产包打包，打包完成后生产环境验证，验证无误投产完成
发布完成，一般为投产后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
非紧急缺陷修复可按照需求分支过程推进，仅分支名称不一致（feature/feature1变成了bugfix/bug1），紧急情况可能出现创建分支修改后直接发布的情况，中间区别主要为测试阶段的分支变化，到投产发布及投产后动作与需求保持一致
非紧急缺陷分支变化过程见需求分支变化过程
紧急缺陷修复git分支管理示例
发现缺陷
git switch main
git switch -c bugfix/bugfix_20240527
缺陷修复
#coding......
git add *
git commit -m "xxx缺陷修复"
缺陷修复投产
#基于bugfix分支release分支差异进行codereview后，merge bugfix分支到release分支
git switch release
git merge bugfix/bugfix_20240527
发布完成
#基于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
一个新需求则基于main分支创建一个feature分支
一个bug则基于main分支创建一个bugfix分支
单需求投产则谁先投产谁将投产内容并入release分支，多个同时投产则创建临时release_temp分支，同时merge所有本次投产内容，并在临时分支解决冲突内容，解决后将release_temp分支提交merge请求并入release分支进行投产版本准备
投产完成后将release分支并入main分支及各feature分支、develop分支，然后删除已投产临时feature分支、bugfix分支及release_temp分支
投产完成基于gitlab标记tag
#实操模拟
#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，然后打包投产验证。