Git是现在最流行的版本控制工具几乎每个开发者都在用但是很多人只是会用简单的commitpushpull对Git工作流分支策略代码评审等等没有太多的了解导致团队协作的时候经常出现问题比如代码冲突分支混乱版本管理不清等等。

其实Git有很多成熟的工作流和最佳实践能让团队协作更高效代码质量更高版本管理更清晰。我用Git很多年了在不同的团队用过不同的工作流踩了一些坑也总结了一些经验今天就来分享一下Git工作流的最佳实践从分支策略到代码评审全面分享希望能帮大家更好地使用Git提高团队协作效率。

一、Git工作流概述

先说说什么是Git工作流。

Git工作流就是团队在使用Git进行版本控制和协作开发的时候遵循的一套规范和流程包括分支怎么建代码怎么提交怎么合并怎么发布怎么做代码评审等等一套好的Git工作流能让团队协作更顺畅代码质量更高版本管理更清晰避免很多不必要的问题。

常见的Git工作流有几种：

  1. Git Flow： 最经典的工作流分支比较多包括masterdevelopfeaturereleasehotfix等等适合有明确发布周期的项目。
  2. GitHub Flow： 比较简单的工作流只有master和feature分支适合持续部署的项目Web应用常用。
  3. GitLab Flow： 介于Git Flow和GitHub Flow之间有环境分支比如productionstaging等等适合有多个环境的项目。
  4. Trunk Based Development： 主干开发所有人都在主干上开发小步提交适合CI/CD成熟的团队。

不同的工作流有不同的特点和适用场景团队要根据自己的项目特点团队规模发布周期等等选择合适的工作流没有最好的只有最合适的。

二、分支策略

分支策略是Git工作流的核心下面详细说说常见的分支类型和策略。

1. 主干分支（master/main）

主干分支是项目的主分支存放的是稳定的可发布的代码随时都能从这个分支发布上线所以主干分支的代码必须是稳定的经过测试的不能直接在主干分支上开发也不能把没测试的代码合并到主干分支。

一般主干分支是受保护的不能直接push只能通过Pull Request（PR）或者Merge Request（MR）经过代码评审通过后才能合并这样能保证主干分支的代码质量。

2. 开发分支（develop）

Git Flow里有develop分支是日常开发的分支所有的feature分支都从develop切出来开发完合并回developdevelop分支的代码是最新的开发中的代码可能不稳定等develop的功能积累到一定程度要发布了再从develop切出release分支测试没问题再合并到master和develop。

develop分支适合有明确发布周期的项目比如两周一个迭代一个月一个版本等等如果是持续部署的项目可能不需要develop分支直接用GitHub Flow就行。

3. 功能分支（feature）

功能分支是用来开发新功能的分支每个新功能一个feature分支从develop（或者master看工作流）切出来开发完测试通过再合并回develop（或者master）然后删除feature分支。

功能分支的命名一般是feature/功能名或者feature/任务编号比如feature/user-loginfeature/123-add-search等等清晰明了一看就知道这个分支是干什么的。

功能分支的生命周期要短不要一个分支开发几个月那样合并的时候会有很多冲突很难合并要小步开发一个功能拆成小的任务每个任务一个分支或者一个分支开发完尽快合并不要长期存在。

4. 发布分支（release）

Git Flow里有release分支是用来准备发布的分支当develop的功能积累到一定程度要发布了就从develop切出release分支在release分支上做发布前的测试修bug准备发布文档等等测试没问题就把release分支合并到master打tag发布同时也合并回develop然后删除release分支。

release分支的命名一般是release/版本号比如release/1.0.0release/2.1.0等等。

release分支的好处是发布的时候不影响develop的日常开发开发人员可以继续在develop上开发下一个版本的功能release分支只做发布前的准备和修bug互不影响。

5. 热修复分支（hotfix）

热修复分支是用来修复线上紧急bug的分支当线上出现了紧急的bug需要马上修复就从master切出hotfix分支修复bug测试通过合并到master打tag发布同时也合并回develop（或者release）然后删除hotfix分支。

hotfix分支的命名一般是hotfix/版本号或者hotfix/bug描述比如hotfix/1.0.1hotfix/fix-login-error等等。

hotfix分支是紧急修复用的优先级最高要尽快修复尽快上线不能影响线上的用户。

三、提交规范

除了分支策略提交规范也很重要好的提交规范能让提交历史更清晰更易读也方便生成变更日志版本发布等等。

1. Commit Message 规范

Commit Message就是每次提交的说明很多人写Commit Message很随意比如"更新""修复""改了一下"等等这样的提交历史很乱以后想找某个修改都找不到所以Commit Message要规范。

常用的Commit Message 规范是Conventional Commits格式是：

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

<body>

<footer>
  • type： 提交类型比如feat（新功能）fix（修复bug）docs（文档）style（格式不影响代码运行）refactor（重构）perf（性能优化）test（测试）chore（构建过程或辅助工具的变动）等等。
  • scope： 影响范围可选比如userorderapi等等说明这个提交影响了哪个模块。
  • subject： 提交目的简短描述不超过50字。
  • body： 详细描述可选说明为什么这么改改了什么等等。
  • footer： 备注可选比如关闭了哪个issue破坏性变更说明等等。

比如：

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

- 添加用户名密码登录
- 添加邮箱验证码登录
- 添加登录状态保持

Closes #123
fix(order): 修复订单支付失败的问题

支付接口超时时间设置太短导致网络慢的时候支付失败
把超时时间从5秒改成15秒。

Closes #456

这样的Commit Message很清晰很规范一看就知道这个提交是干什么的影响了什么也方便生成变更日志自动发布等等。

2. 小步提交

提交要小步不要一次提交一大堆改动一个提交只做一件事比如修复一个bug添加一个功能改一个格式等等不要把多个不相关的改动放在一个提交里那样以后想回滚某个改动都不好回滚也不好看提交历史。

小步提交的好处是提交历史清晰容易理解出了问题容易定位也容易回滚代码评审也更方便所以要养成小步提交的习惯。

3. 提交前检查

提交前要检查一下自己的改动确保没有问题比如代码能正常运行没有语法错误没有调试代码没有敏感信息等等不要把有问题的代码提交上去影响别人。

可以用Git Hook在提交前自动运行代码检查单元测试等等确保提交的代码没有问题比如pre-commit hook能在提交前运行eslintphpunit等等有问题就阻止提交这样能保证提交的代码质量。

四、代码评审

代码评审（Code Review）是Git工作流中非常重要的一环能有效提高代码质量发现bug分享知识统一代码风格等等所以团队一定要做代码评审。

1. Pull Request / Merge Request

代码评审一般是通过Pull Request（PRGitHub）或者Merge Request（MRGitLab）来做的开发人员把feature分支推到远程然后创建PR/MR请求把feature分支合并到目标分支（比如develop或者master）然后其他开发人员review代码没问题再合并。

PR/MR里要写清楚这个PR是干什么的改了什么怎么测试的有没有关联的issue等等方便review的人理解这个改动。

2. 代码评审要点

代码评审不是挑刺不是找别人的毛病而是一起提高代码质量所以要注意方式方法下面是一些代码评审的要点：

  • 功能是否正确： 首先看功能是否实现了需求逻辑是否正确有没有边界情况没考虑到有没有bug。
  • 代码是否可读： 代码是否清晰易懂命名是否合理注释是否清楚结构是否良好有没有太复杂的逻辑能不能简化。
  • 是否有安全问题： 有没有SQL注入XSSCSRF等等安全漏洞有没有敏感信息泄露有没有权限问题。
  • 性能是否有问题： 有没有性能问题比如N+1查询循环里查数据库大的循环没有缓存等等能不能优化。
  • 是否符合规范： 代码是否符合团队的代码规范风格是否统一有没有多余的代码有没有重复的代码能不能抽取公共方法。
  • 测试是否充分： 有没有写单元测试测试用例是否覆盖了主要的场景边界情况有没有测到。

3. 代码评审注意事项

代码评审要注意这些：

  • 对事不对人： 评审的是代码不是人不要人身攻击不要说"你怎么这么写"要说"这里是不是可以这么写更好"要尊重别人友好沟通。
  • 及时review： PR创建了要及时review不要拖几天才看那样影响开发进度一般当天或者第二天就要review完。
  • 小的PR： PR不要太大一个PR改几千行代码review的人根本看不过来也不容易发现问题要小步提交小的PR一个PR只做一件事最好不超过400行改动。
  • 要有讨论： review的时候有不同意见要讨论不要一方说了算大家一起讨论找到最好的方案达成共识再合并。
  • 作者要虚心接受： 代码的作者要虚心接受别人的意见不要觉得别人挑刺有则改之无则加勉一起提高代码质量。

五、常用Git命令和技巧

分享一些常用的Git命令和技巧能提高效率：

1. 常用命令

# 查看状态
git status

# 查看提交历史
git log
git log --oneline  # 一行显示一个提交
git log --graph  # 图形化显示分支合并

# 查看改动
git diff  # 查看工作区的改动
git diff --cached  # 查看暂存区的改动
git diff HEAD  # 查看所有改动

# 添加文件
git add .  # 添加所有文件
git add filename  # 添加指定文件

# 提交
git commit -m "message"
git commit -am "message"  # 添加并提交所有已跟踪的文件

# 推送
git push origin branch-name

# 拉取
git pull origin branch-name
git fetch origin  # 只拉取不合并

# 分支
git branch  # 查看本地分支
git branch -a  # 查看所有分支
git branch new-branch  # 创建分支
git checkout new-branch  # 切换分支
git checkout -b new-branch  # 创建并切换分支
git branch -d branch-name  # 删除分支
git branch -D branch-name  # 强制删除分支

# 合并
git merge branch-name  # 合并分支
git merge --no-ff branch-name  # 不使用快进合并生成合并提交

# 变基
git rebase branch-name  # 变基
git rebase -i HEAD~3  # 交互式变基修改最近3个提交

# 撤销
git checkout -- filename  # 撤销工作区的改动
git reset HEAD filename  # 撤销暂存区的改动
git reset --hard HEAD  # 撤销所有改动回到上一个提交
git reset --hard commit-id  # 回退到指定提交

# 储藏
git stash  # 储藏当前改动
git stash list  # 查看储藏列表
git stash pop  # 恢复最近的储藏
git stash drop  # 删除最近的储藏

# 标签
git tag  # 查看标签
git tag v1.0.0  # 创建标签
git tag -a v1.0.0 -m "version 1.0.0"  # 创建带注释的标签
git push origin v1.0.0  # 推送标签
git push origin --tags  # 推送所有标签

2. 实用技巧

  • git alias： 可以配置Git别名简化命令比如git config --global alias.st status这样git st就等于git status能提高效率。
  • .gitignore： 一定要配置好.gitignore文件把不需要提交的文件比如.envnode_modulesvendor日志文件临时文件等等都忽略掉不要提交到Git里。
  • git blame： 用git blame filename能查看文件的每一行是谁什么时候改的出了问题能快速找到责任人。
  • git bisect： 用git bisect能二分查找哪个提交引入了bug当不知道bug是什么时候引入的时候很有用。
  • git reflog： 用git reflog能查看所有的Git操作记录包括被删除的提交误操作了能用git reflog找回很有用。
  • cherry-pick： 用git cherry-pick commit-id能把某个提交挑出来应用到当前分支当只需要某个分支的某个提交不想合并整个分支的时候很有用。

六、踩坑经验

最后分享一些我用Git踩过的坑和经验：

1. 不要强制推送主干分支

千万不要强制推送主干分支（git push --force origin master）那样会覆盖别人的提交导致代码丢失很危险如果确实需要强推一定要确认没人在这个分支上工作而且要通知大家一般主干分支都是受保护的不允许强推。

2. 不要在公共分支上rebase

不要在公共分支（比如masterdevelop）上做rebase因为rebase会改写提交历史别人拉取的时候会有问题冲突很多公共分支只做merge不要rebaserebase只在自己的feature分支上用。

3. 提交前一定要pull

推送前一定要先pull拉取最新的代码合并解决冲突测试没问题再push不然可能会把别人的代码覆盖或者有冲突推送不上去养成push前先pull的习惯。

4. 不要把敏感信息提交到Git

千万不要把敏感信息比如数据库密码API密钥私钥等等提交到Git里那样很危险一旦提交就会留在历史里即使后来删了也能从历史里找到所以敏感信息要放在.env文件里或者环境变量里.env要加入.gitignore不要提交。

如果不小心把敏感信息提交了要尽快修改密码密钥然后用git filter-branch或者BFG Repo-Cleaner清理历史记录不要只是删了就完事。

5. 定期清理分支

分支合并完了就要及时删除不要留着很多旧分支那样分支会越来越多很乱不知道哪个是有用的定期清理已经合并的分支保持分支列表干净清晰。

6. 写好.gitignore

一开始就要写好.gitignore文件把不需要提交的文件都忽略掉不要等提交了很多没用的文件才想起来加.gitignore那样已经提交的文件还在历史里要清理很麻烦。

七、写在最后

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

Git是每个开发者都必须掌握的工具但是会用Git命令只是基础更重要的是理解Git工作流分支策略代码评审等等这些能让团队协作更高效代码质量更高版本管理更清晰。

当然Git工作流没有最好的只有最合适的团队要根据自己的项目特点团队规模发布周期等等选择合适的工作流并且不断优化改进找到最适合自己的方式。

希望这篇分享能帮大家更好地理解Git工作流更好地使用Git提高团队协作效率和代码质量。

最后用一句话结尾：

"Git不只是一个版本控制工具更是一种团队协作的方式好的Git工作流能让团队事半功倍。"

祝大家都能用好Git协作愉快！