你是否曾经因为版本控制混乱而抓狂？或者在处理临时 bug 时感到无所适从？别担心！今天我们将深入探讨 Git 分支管理及命名规范，帮助你在日常功能开发、周期bug修复、紧急 bug 修复等场景中游刃有余。本文将带你轻松入门，让你成为 Git 分支管理的高手！
为什么需要分支管理？
在软件开发中，版本控制是必不可少的。版本控制可以记录代码的每一次改动，并允许开发人员在不同版本之间切换。
Git 分支管理是 Git 中一项重要的功能，它使开发人员能够在同一个代码库中并行开发多个任务，而不会相互冲突。分支管理可以带来以下好处：
- 提高开发效率： 开发人员可以同时在多个功能上进行开发，而无需担心冲突。
- 提高代码质量： 分支可以隔离不同的代码变更，从而更容易发现和修复 Bug。
- 增强团队协作： 多个开发人员可以同时在同一个代码库上工作，而无需担心踩踏彼此的代码。
- 简化发布流程： 通过合理的分支管理，可以轻松地将新功能发布到生产环境。
分支命名规范
在开始分支管理之前，首先要了解分支命名规范。一个好的命名规范能让团队成员清楚地了解每个分支的用途，提高工作效率。
常见的命名约定
- 主分支（main/master）：这是生产代码所在的分支，永远保持稳定和可发布状态。
- 开发分支（develop）：这是用于集成开发的分支，所有的新功能都会在这里合并。
- 功能分支（feature/）：每个新功能都有一个独立的分支。
- 修复分支（bugfix/）：用于修复功能 bug。
- 发布分支（release/）：准备发布的代码会被放到这个分支上，进行最后的测试和预发布。
- 热修复分支（hotfix/）：紧急修复生产环境中的严重 bug。
分支命名示例
- main
- develop
- feature/login-page
- bugfix/navbar-not-responsive
- release/v1.0
- hotfix/critical-security-patch
Git 分支管理策略
1. 日常的开发任务
日常的开发任务主要是在 feature 分支上进行。让我们以开发一个新的登录页面为例。
创建功能分支
git checkout -b feature/login-page main这条命令创建了一个名为 feature/login-page 的新分支，并基于 main 分支。
提交代码
# 编辑代码后提交
git add .
git commit -m "Add login page UI"合并到开发分支测试
# 切换到 develop 分支
git checkout develop
# 合并 feature 分支
git merge feature/login-page
# 功能上线后，删除功能分支
git branch -d feature/login-page合并到发布分支
develop 分支，应该具有项目最新的功能代码，在多人协作，多个任务同时进行的情况下，有可能还包括其他人提交的代码，其他人开发的功能如果不和我们在一个版本发布的话，那就不能将 develop 分支合并到发布分支（release/）上，这就需要我们将功能分支重新合并到发布分支，进行预发布测试。
2. 周期的 Bug 修复
假设我们的系统在使用过程中发现了一些小的问题，但不影响主体功能使用，又避免频繁的发布，这时就需要需要在 bugfix 分支上进行修复。
创建修复分支
git checkout -b bugfix/navbar-not-responsive main修复 Bug 并提交代码
# 编辑代码后提交
git add .
git commit -m "Fix navbar responsiveness issue"合并到开发分支
# 切换到 develop 分支
git checkout develop
# 合并 bugfix 分支
git merge bugfix/navbar-not-responsive
# 功能上线后，删除修复分支
git branch -d bugfix/navbar-not-responsive3. 紧急 Bug 修复
紧急修复生产环境中的问题需要用到 hotfix 分支。假设我们发现一个关键的安全漏洞需要立即修复。
创建热修复分支
git checkout -b hotfix/critical-security-patch main修复 Bug 并提交代码
# 切换到 release/v1.1 分支并合并，测试
git checkout release/v1.1
git merge hotfix/critical-security-patch
# 测试通过后，切换到 main 分支并合并
git checkout main
git merge release/v1.1
# 删除热修复分支
git branch -d hotfix/critical-security-patch合并到发布分支，发布分支合并到主分支
# 切换到 release/v1.1 分支并合并，测试
git checkout release/v1.1
git merge hotfix/critical-security-patch
# 测试通过后，切换到 main 分支并合并
git checkout main
git merge release/v1.1
# 删除热修复分支
git branch -d hotfix/critical-security-patch实践中的建议
- 保持分支短暂：分支应尽量短暂，不要让功能分支长期存在，以免合并时产生冲突。
- 频繁提交：频繁的小提交可以让你更好地管理和追踪更改。
- 使用 Pull Request（PR）：通过 PR 进行代码审查，可以提升代码质量，确保代码合并前经过检查。
- 写好提交信息：清晰的提交信息有助于理解每次更改的目的和内容。
- 合并最新版本代码：每次生产环境发版结束后，需要将 main 分支合并到所有正在进行的分支中，确保每个分支都是最新版本代码。
- 先拉取再提交：多人协同开发时，一定要记住每次提交代码前要先拉取下最新代码，避免代码冲突。