Git 分支工作流实战：从功能开发到合并上线的完整流程

很多个人项目只有一条 master 分支，改到哪算哪，等到功能一多、上线一急，才发现提交历史乱成一团，连版本回滚都无从下手。本文给出一套轻量的 Git 分支工作流，覆盖功能分支创建、提交推送到合并审查、发布热修的完整路径。

一、为什么要用分支工作流

1. 只有一条主分支的代价

改动全部直接提交到 master 会踩到三个坑：未完成的功能与稳定代码混在一条线上，线上出故障时无法只回滚某一个功能；提交历史夹杂调试与格式噪音，定位问题要一行行翻；多人协作时后提交的人必须先解决别人遗留的冲突。分支的本质，是把「正在开发的代码」与「可以上线的代码」隔离开。

2. 三种主流工作流的取舍

Git Flow 分支最多，有 main、develop、feature、release、hotfix 五类，适合有固定发布周期、需维护多个版本的团队。GitHub Flow 只保留 main 加功能分支，改动经合并请求回到 main 后立即部署。Trunk Based 提交直接进主干，靠特性开关控制功能可见性，对自动化测试要求最高。

二、从功能开发到合并的完整流程

1. 分支命名与创建

先约定前缀，让人一眼看出用途：feature/ 是新功能，fix/ 是缺陷修复，hotfix/ 是线上紧急修复。务必从最新主干拉出，避免基于过期代码开工：

git checkout main && git pull origin main
git checkout -b feature/seo-sitemap

2. 提交与推送

提交信息用祈使句写标题，一行说清做了什么，空一行再写原因。标题控制在 50 字符内，超出挪到正文，git log --oneline 才不会折行：

git commit -m "feat: 新增 sitemap 自动生成脚本"
git push -u origin feature/seo-sitemap

-u 会把本地分支与远程同名分支绑定，之后直接 git push 即可。

3. 合并前同步主干与处理冲突

功能分支放置几天后，主干通常已有新提交。合并前先把主干合进来，把冲突解决在功能分支里：

git fetch origin && git rebase origin/main
# 有冲突时：编辑文件删除冲突标记后
git add 冲突文件 && git rebase --continue
git checkout main
git merge --no-ff feature/seo-sitemap && git push origin main

rebase 把功能分支的提交挪到主干最新提交之后，适合尚未共享的本地分支；一旦分支已推送、有人基于它开发，就改用 git merge origin/main，避免改写公共历史。合并加 --no-ff 会生成合并提交，保留分支边界，git log --graph 能看清某功能包含哪些提交。

三、发布与热修复的收尾

1. 合并后打标签

代码回到主干后打一个注释标签，版本回滚时按标签切回即可，并删除已融入主干的功能分支：

git tag -a v1.2.0 -m "发布 1.2.0"
git branch -d feature/seo-sitemap

2. hotfix 紧急修复

线上出现严重问题时，从 main 直接切 hotfix 分支，只做最小改动，验证通过后合回 main：

git checkout -b hotfix/login-500 main
git checkout main && git merge --no-ff hotfix/login-500

关键配置提示

• 主干合并统一用 --no-ff，保留分支历史，便于定位功能边界与整体回滚
• 在托管平台开启受保护分支，禁止直接 push main，改动走合并请求
• 提交前跑一次格式化与自检，让 diff 只体现真实逻辑变更