Git工作流最佳实践：从分支策略到代码评审

Git是现在最流行的版本控制工具几乎每个开发团队都在用但是很多团队对Git的使用只停留在cloneaddcommitpushpull的层面没有一个规范的工作流结果分支混乱代码冲突频繁版本管理混乱出了问题不好回滚团队协作效率低。

我经历过几个团队的Git工作流从混乱到规范踩了很多坑也总结了一些经验今天就来分享一下Git工作流的最佳实践从分支策略到提交规范到代码评审到发布流程全面分享。

一、为什么需要规范的Git工作流

先说说为什么需要规范的Git工作流。

很多小团队或者个人项目可能觉得Git工作流不重要随便提交随便push就行但是当团队变大了项目变复杂了多人协作了就会发现没有规范的工作流会有很多问题：

分支混乱： 每个人都随便建分支分支名乱七八糟不知道哪个分支是干什么的哪个分支是最新的哪个分支已经不用了时间长了分支越来越多越来越乱没人敢删分支怕删错了。

代码冲突频繁： 因为没有规范的分支策略和合并流程大家都在同一个分支上改代码或者分支长期不合并导致代码冲突很多合并的时候很痛苦甚至会把别人的代码覆盖掉出bug。

版本管理混乱： 没有规范的标签和发布流程不知道哪个版本上线了哪个commit对应哪个版本出了问题不知道该回滚到哪里也不好追溯问题。

代码质量无法保证： 没有代码评审每个人写完代码就直接合并到主分支代码质量参差不齐bug多可读性差可维护性差时间长了代码越来越烂没人敢改。

团队协作效率低： 因为没有规范的工作流大家沟通成本高经常要问这个改了吗？那个合并了吗？这个分支能用吗？等等效率很低也容易出问题。

所以一个规范的Git工作流对于团队协作代码质量版本管理都非常重要能大大提升团队的开发效率和代码质量。

二、常见的Git工作流

Git有几种常见的工作流各有优缺点适合不同的团队和项目：

1. Git Flow：

Git Flow是最经典的Git工作流由Vincent Driessen提出它定义了五种分支：

master： 主分支存放稳定的可发布的代码只能从其他分支合并不能直接提交。
develop： 开发分支存放最新的开发中的代码所有功能开发都合并到这里。
feature： 功能分支从develop切出开发新功能开发完合并回develop。
release： 发布分支从develop切出用于发布前的测试修复bug发布完合并到master和develop。
hotfix： 热修复分支从master切出用于修复线上的紧急bug修复完合并到master和develop。

Git Flow的优点是规范清晰适合版本发布周期比较固定的项目比如桌面软件APP等等缺点是比较复杂分支多流程长对于快速迭代的互联网项目可能不太适合。

2. GitHub Flow：

GitHub Flow是GitHub用的工作流比较简单只有一个主分支master加上功能分支：

master： 主分支永远是可发布的稳定的。
feature： 功能分支从master切出开发新功能开发完提Pull Request代码评审通过后合并到master然后部署。

GitHub Flow的优点是简单轻量适合快速迭代的互联网项目特别是Web项目随时可以发布缺点是对于多版本并行开发或者需要长期维护旧版本的项目不太适合。

3. GitLab Flow：

GitLab Flow是GitLab推荐的工作流结合了Git Flow和GitHub Flow的优点比Git Flow简单比GitHub Flow多了环境分支和版本分支适合有多个环境（开发测试预发布生产）的项目。

4. Trunk Based Development（主干开发）：

主干开发是一种比较极端的工作流所有人都在主干（master/trunk）上开发不建或者很少建功能分支每个人小步提交频繁合并到主干通过特性开关（Feature Flag）来控制未完成的功能不影响线上。

主干开发的优点是合并冲突少集成快适合高频率小步迭代的团队特别是做持续交付的团队缺点是对团队的工程能力要求高需要有完善的自动化测试CI/CD特性开关等等不然容易出问题。

这几种工作流没有绝对的好坏要根据团队的大小项目的类型发布的频率团队的工程能力等等选择适合自己的工作流不要盲目跟风别人用什么自己就用什么。

对于大部分中小团队的Web项目我个人推荐GitHub Flow或者简化版的Git Flow简单实用容易落地效果也不错。

三、分支策略的最佳实践

不管用哪种工作流分支策略都是核心下面分享一些分支策略的最佳实践：

1. 分支命名要规范：

分支名要有意义能看出这个分支是干什么的谁在做比如：

功能分支：feature/xxx比如feature/user-loginfeature/article-list
bug修复分支：bugfix/xxx比如bugfix/login-error
热修复分支：hotfix/xxx比如hotfix/payment-error
发布分支：release/xxx比如release/v1.2.0

也可以加上开发者或者任务ID比如feature/zhangsan-user-loginfeature/TASK-123-user-login这样更清晰能知道是谁在做对应哪个任务。

不要用一些没意义的分支名比如testtmpzhangsannew等等时间长了没人知道这个分支是干什么的。

2. 主分支要保护：

master（或者main）分支是最重要的分支存放稳定的可发布的代码一定要保护起来不能随便直接提交要通过Pull Request（或者Merge Request）代码评审通过后才能合并。

大部分Git托管平台比如GitHubGitLabGitee都支持分支保护可以设置禁止直接push必须通过PR合并必须至少几个人评审通过才能合并必须CI通过才能合并等等一定要开启这些保护。

3. 分支要短期存在及时删除：

功能分支不要长期存在最好几天最多一两周就合并回主分支然后删除分支长期存在的分支会和主分支差异越来越大合并的时候冲突很多很痛苦也容易出问题。

如果一个功能开发周期很长要几周甚至几个月那最好把功能拆小分批合并或者用特性开关先把基础代码合并到主分支用特性开关控制不启用等全部开发完再打开开关这样避免长期分支。

合并完的分支要及时删除不要留着分支太多了会很乱大部分Git平台合并PR的时候可以勾选合并后自动删除分支建议勾选。

4. 从最新的主分支切出：

切功能分支的时候要从最新的主分支（或者develop分支）切出不要从旧的分支切出不然分支的基础代码是旧的合并的时候冲突可能多也可能有已经修复的bug又出现了。

切分支之前先pull一下最新的主分支然后再切分支保证基础代码是最新的。

5. 经常同步主分支的更新：

功能分支开发过程中要经常把主分支的最新代码合并到功能分支或者rebase这样能及时解决冲突避免最后合并的时候冲突一大堆也能及时获取别人的最新代码避免重复开发或者依赖的接口变了不知道。

一般每天至少同步一次或者主分支有大的更新就同步一次。

四、提交规范的最佳实践

Git提交（commit）也要有规范好的提交信息能让别人快速知道这个提交改了什么为什么改也方便后续追溯问题生成变更日志。

1. 提交信息要清晰有意义：

提交信息不要写一些没意义的比如updatefixtest改了一下等等这样别人根本不知道你改了什么后续出了问题也不好追溯。

提交信息要清晰说明这个提交改了什么为什么改比如"修复用户登录时密码错误提示不显示的bug""添加文章列表分页功能""优化首页加载速度减少SQL查询"等等。

2. 遵循Conventional Commits规范：

推荐遵循Conventional Commits规范这是一个比较流行的提交信息规范格式是：

<type>(<scope>): <subject>

<body>

<footer>

type是提交的类型常见的有：

feat： 新功能
fix： 修复bug
docs： 文档修改
style： 代码格式修改不影响逻辑
refactor： 代码重构不是新功能也不是修bug
perf： 性能优化
test： 测试相关
chore： 构建过程或辅助工具的变动

scope是影响的范围比如userarticleorder等等可选。

subject是提交的简短描述不超过50个字符。

body是详细描述可选说明为什么改改了什么等等。

footer是页脚比如关闭的issue不兼容的变更等等可选。

例子：

feat(user): 添加用户登录功能

实现用户登录接口支持用户名密码登录
登录成功后返回token前端存储token用于后续请求。

Closes #123

fix(article): 修复文章列表分页错误的bug

文章列表第2页开始数据重复原因是分页参数计算错误
修复offset计算逻辑添加单元测试覆盖。

Closes #456

遵循这个规范有很多好处：

提交信息结构化清晰易读
可以自动生成变更日志（CHANGELOG）
可以根据type触发不同的CI/CD流程
方便追溯问题知道哪个提交改了什么

很多大团队大项目都在用这个规范推荐大家也用起来。

3. 小步提交一个提交只做一件事：

不要一个提交改一大堆东西又加功能又修bug又改格式这样提交信息不好写后续出了问题也不好定位不好回滚。

要小步提交一个提交只做一件事比如加一个功能是一个提交修一个bug是一个提交改一个格式是一个提交这样提交信息清晰后续也好追溯好回滚。

当然也不要太碎比如改一个字就提交一次也没必要要平衡一个提交是一个完整的小的逻辑单元。

4. 提交前要检查代码：

提交前一定要检查自己的代码看看有没有语法错误有没有debug代码有没有注释掉的代码有没有不相关的改动等等不要把有问题的代码提交上去。

可以用git diff看看自己改了什么确认没问题再addcommit也可以配置pre-commit钩子自动检查代码格式跑单元测试等等有问题就不让提交。

五、代码评审的最佳实践

代码评审（Code Review）是保证代码质量的重要手段也是团队学习知识共享的好方式一定要做而且要做好。

1. 所有代码都要评审：

不管是新功能还是修bug还是重构所有合并到主分支的代码都要经过代码评审不能例外哪怕是很小的改动也要评审因为很多bug都是小改动引起的。

不要觉得自己的代码没问题不用评审也不要觉得别人的代码肯定没问题不用评审每个人都可能犯错评审能发现很多自己发现不了的问题。

2. 评审要及时：

代码评审要及时别人提了PR要尽快评审不要拖几天都不看那样会阻塞别人的开发也会让分支长期存在合并冲突多。

一般PR提出来最好当天或者第二天就评审完不要超过两天如果忙可以和对方说一下大概什么时候能评审让对方有预期。

3. 评审要对事不对人：

代码评审是评审代码不是评审人要对事不对人不要因为是新人的代码就挑剔也不要因为是大佬的代码就不敢提意见大家的目标都是提升代码质量不是挑刺也不是面子问题。

提意见的时候要客气尊重用建议的语气比如"这里是不是可以考虑用xxx方式会更好一些？"而不是"这里写得太烂了赶紧改"尊重别人别人才愿意接受你的意见。

被评审的人也要虚心接受意见不要觉得别人挑刺要把评审当成学习的机会提升自己的机会有道理的意见就改觉得没道理的可以讨论沟通达成共识。

4. 评审要关注重点：

代码评审不是要把每一行代码都挑出问题也不是只看代码格式要关注重点：

逻辑是否正确： 有没有逻辑错误边界条件考虑了吗？异常处理了吗？并发有问题吗？
安全性： 有没有安全漏洞比如SQL注入XSSCSRF权限问题等等。
性能： 有没有性能问题比如N+1查询循环里查数据库大循环等等。
可维护性： 代码清晰吗？命名合理吗？注释够吗？结构合理吗？好改吗？
可读性： 别人能看懂吗？有没有太复杂的逻辑能不能简化？

代码格式命名规范这些尽量用自动化工具检查比如ESLintPrettierPHP_CodeSniffer等等不要在评审的时候花太多时间讨论格式问题那是浪费时间。

5. 评审要有结论：

评审完要有明确的结论是通过可以合并还是需要修改修改完再评审不要模棱两可让对方不知道该怎么办。

如果需要修改要明确指出哪里要改为什么要改怎么改让对方清楚知道该怎么改改完再提评审通过后再合并。

六、发布流程的最佳实践

最后说说发布流程的最佳实践。

1. 版本号要规范：

版本号推荐遵循语义化版本（Semantic Versioning）格式是主版本号.次版本号.修订号比如1.2.3：

主版本号： 不兼容的API修改大的架构变更
次版本号： 向下兼容的功能性新增
修订号： 向下兼容的问题修正

这样别人一看版本号就知道这个版本大概改了什么有没有不兼容的变更要不要谨慎升级。

2. 打标签记录版本：

每次发布都要在Git里打标签（tag）记录这个版本对应的commit比如v1.2.3这样后续出了问题能快速找到这个版本的代码也能对比不同版本的差异。

标签要和版本号一致比如v1.2.3不要随便打标签也不要不打标签不然不知道哪个commit是哪个版本。

3. 发布前要充分测试：

发布前一定要充分测试单元测试集成测试功能测试等等都要跑过没问题才能发布不要没测试就直接上线那样很容易出问题。

有条件的最好有测试环境预发布环境先在测试环境测没问题再到预发布环境测没问题再到生产环境发布层层把关减少线上bug。

4. 灰度发布小流量验证：

重要的发布最好用灰度发布先给一小部分用户用比如1%5%观察一段时间没问题再逐步扩大流量直到全量这样即使有问题也只影响一小部分用户不会影响所有用户。

灰度发布需要有流量调度的能力比如Nginx负载均衡网关等等可以根据用户IDIP等等分配流量。

5. 发布后要监控观察：

发布后不要觉得完事了要密切监控系统的状态比如错误率响应时间CPU内存数据库等等有没有异常用户有没有反馈问题等等有问题及时处理必要时快速回滚。

一般发布后至少观察半小时到一小时没问题才能放心。

6. 有问题快速回滚：

发布后如果发现有严重问题要快速回滚到上一个稳定版本不要纠结要不要修先回滚保证系统稳定用户不受影响然后再慢慢排查问题修复重新发布。

回滚要提前准备好方案和脚本保证能快速回滚不要出了问题才想怎么回滚那样太慢了影响时间长。

七、写在最后

Git工作流最佳实践：从分支策略到代码评审。

Git工作流看起来是小事但是对团队的开发效率代码质量协作体验都有很大的影响一个好的Git工作流能让团队协作更顺畅代码质量更高版本管理更清晰出了问题更好处理。

当然Git工作流也不是越复杂越好要根据团队的实际情况选择适合自己的简单实用能落地才是最好的不要盲目追求复杂完美结果团队执行不了反而不好。

希望这篇分享能帮大家建立规范的Git工作流提升团队的开发效率和代码质量。

最后用一句话结尾：

"工具是为人服务的Git工作流也是不要为了流程而流程要让流程帮助我们更好地协作更好地写代码这才是最重要的。"

祝大家都能用好Git团队协作顺畅代码质量高高！