Git 的分支管理

在使用Git管理代码时，需要同时维护已上线的v1版本（修复bug）和未完成的v2版本（新功能开发），如何规范、高效地管理这两个版本的代码，避免相互干扰。

一、核心分支管理思路

首先明确Git分支的职责划分，这是避免代码混乱的基础：

分支类型	命名建议	核心职责
主分支	`main`/`master`	存放可上线的稳定代码（v1的正式版本代码）
开发分支	`develop`	存放v2版本的开发中代码（所有v2新功能都合并到这里）
修复分支	`hotfix/v1.0.1`	基于main分支创建，专门修复v1的bug，修复完成后合并回main和develop分支
功能分支	`feature/xxx`	（可选）v2的单个新功能开发分支，完成后合并到develop分支

二、具体操作步骤（以v1修复bug为例）

步骤1：确保本地代码干净且最新

先拉取远程最新代码，避免本地代码过时：

bash 复制代码

# 切换到main分支（v1上线版本）
git checkout main
# 拉取远程最新的main分支代码
git pull origin main

步骤2：创建v1的bug修复分支（hotfix分支）

基于main分支创建独立的修复分支，避免直接修改main/develop：

bash 复制代码

# 创建并切换到hotfix分支（命名规范：hotfix/版本号-问题描述，比如hotfix/v1.0.1-login-bug）
git checkout -b hotfix/v1.0.1

步骤3：在hotfix分支修复v1的bug

在这个分支上只做v1 bug的修复，不添加任何v2的新功能代码，修复完成后提交：

bash 复制代码

# 修复bug后，添加修改的文件
git add .
# 提交修复记录（备注清晰，比如：fix(v1): 修复登录接口返回数据异常的bug）
git commit -m "fix(v1): 修复v1版本登录失败的bug"

步骤4：测试通过后，合并hotfix分支到main（上线v1修复版）

修复完成并测试通过后，将hotfix分支合并回main分支（main始终是可上线的代码）：

bash 复制代码

# 切换回main分支
git checkout main
# 合并hotfix分支到main
git merge --no-ff hotfix/v1.0.1
# 打标签，标记v1.0.1版本（便于后续追溯）
git tag -a v1.0.1 -m "v1版本修复登录bug，发布v1.0.1"
# 推送main分支和标签到远程
git push origin main
git push origin v1.0.1

步骤5：将hotfix分支合并到develop（同步v1修复到v2）

v2版本（develop分支）也需要包含这个bug修复，避免v2上线后复现该问题：

bash 复制代码

# 切换到develop分支（v2开发分支）
git checkout develop
# 拉取远程最新的develop代码
git pull origin develop
# 合并hotfix分支到develop
git merge --no-ff hotfix/v1.0.1
# 推送develop分支到远程
git push origin develop

步骤6：删除已完成的hotfix分支（可选，保持分支整洁）

bash 复制代码

# 删除本地hotfix分支
git branch -d hotfix/v1.0.1
# 删除远程hotfix分支（如果推过远程）
git push origin --delete hotfix/v1.0.1

三、v2版本开发的补充建议

如果v2有多个新功能并行开发，建议为每个功能创建独立的feature分支：

bash 复制代码

# 基于develop分支创建功能分支
git checkout -b feature/user-profile develop
# 功能开发完成后，合并回develop分支（可通过MR/PR代码评审）
git checkout develop
git merge --no-ff feature/user-profile

总结

分支隔离 ：用main存v1稳定代码、develop存v2开发代码、hotfix专门修复v1 bug，避免代码混在一起。
双向同步 ：v1的bug修复既要合并到main（上线），也要合并到develop（同步到v2），确保修复不遗漏。
版本标记 ：修复后给main分支打标签（如v1.0.1），便于后续追溯和回滚。
规范命名 ：分支命名遵循hotfix/版本号、feature/功能名，提升可读性和团队协作效率。