Git分支管理 - 技术栈

前言

从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分支

shell 复制代码

#查看当前分支，仅包含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从开始到投产

需求编码开始

shell 复制代码

#切换main分支
git switch main

#创建需求分支feature1并切换至需求分支
git switch -c feature/feature1

#如涉及多人开发，则将需求分支推送至远程仓库如gitlab
git push origin feature/feature1

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

java 复制代码

//原始代码
package com.company;

public class Test {
    public static void main(String[] args) {
        System.out.println("Hello");
    }
}

java 复制代码

//需求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);
    }
}

shell 复制代码

#在需求分支内开发业务代码,coding......

#每日提交
git add *
git commit -m "feature1开发完成"

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

集成测试、业务测试

shell 复制代码

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

#使用develop分支进行测试环境打版

测试bug修复

shell 复制代码

#测试发现bug，修改bug

#在对应的需求分支修改缺陷，目的为可通过单一分支汇聚所有这项需求的改造内容
git switch feature/feature1

#缺陷修复，coding

#缺陷修复提交
git add *
git commit -m "feature1缺陷修复"

#缺陷修复打版：将修复代码并入测试环境分支
git switch develop
git merge feature1/feature1

#使用develop分支进行测试环境打版

投产发布前CodeReview

shell 复制代码

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

投产包准备，CoreReview通过则进行投产包准备，若不通过需整改，则继续在feature分支修改测试
shell 复制代码
```
#切换release分支：基于release分支创建发布版本
git switch release
git merge feature/feature1
```
投产：基于release分支进行投产包打包，打包完成后生产环境验证，验证无误投产完成

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

shell 复制代码

#基于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分支管理示例

发现缺陷

shell 复制代码

git switch main
git switch -c bugfix/bugfix_20240527

缺陷修复

shell 复制代码

#coding......

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

缺陷修复投产

shell 复制代码

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

发布完成

shell 复制代码

#基于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同行

一个新需求则基于main分支创建一个feature分支
一个bug则基于main分支创建一个bugfix分支
单需求投产则谁先投产谁将投产内容并入release分支，多个同时投产则创建临时release_temp分支，同时merge所有本次投产内容，并在临时分支解决冲突内容，解决后将release_temp分支提交merge请求并入release分支进行投产版本准备
投产完成后将release分支并入main分支及各feature分支、develop分支，然后删除已投产临时feature分支、bugfix分支及release_temp分支
投产完成基于gitlab标记tag

shell 复制代码

#实操模拟

#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，然后打包投产验证。