Git是目前最流行的版本控制系统，几乎所有的软件开发团队都在用Git。但很多团队，虽然用了Git，却没有建立规范的工作流——大家直接往master分支提交代码，分支命名混乱，提交信息随意，代码没有审查，发布全靠手动。结果就是：代码冲突频繁、bug满天飞、版本混乱、发布困难，团队协作效率低下。

Git只是一个工具，怎么用Git、怎么建立团队协作的工作流，才是关键。一个好的Git工作流，能让团队协作更高效、代码质量更高、发布更稳定。

我经历过几个不同的团队，用过不同的Git工作流，从最简单的集中式工作流，到Git Flow、GitHub Flow、GitLab Flow，积累了一些经验。今天分享Git工作流的最佳实践，帮你的团队建立高效、规范的Git协作模式。

常见的Git工作流

1. 集中式工作流 最简单的工作流，所有人都在master分支上开发，直接commit和push。适合小团队、个人项目，但不适合多人协作的大项目，容易冲突和混乱。

2. 功能分支工作流（Feature Branch） 所有新功能都在独立的功能分支上开发，开发完成后合并回master。这是最基础的分支工作流，比集中式好很多，但缺少发布和热修复的规范。

3. Git Flow 最经典的Git工作流，由Vincent Driessen提出。包含5种分支：

  • master：生产分支，只存放正式发布的代码
  • develop：开发分支，日常开发的集成分支
  • feature：功能分支，从develop切出，开发新功能，完成后合并回develop
  • release：发布分支，从develop切出，用于发布前的测试和bug修复，发布后合并到master和develop
  • hotfix：热修复分支，从master切出，修复线上紧急bug，修复后合并到master和develop

Git Flow非常规范，适合有明确发布周期的项目（如桌面软件、App）。但流程比较复杂，对于持续发布的Web项目来说可能太重了。

4. GitHub Flow GitHub提出的简化工作流，只有master分支+功能分支：

  • master分支始终是可部署的
  • 新功能从master切出功能分支
  • 功能分支开发完成后，提交Pull Request（PR）
  • 代码审查通过后，合并到master
  • 合并后立即部署

GitHub Flow简单、高效，适合持续发布的Web项目，是目前最流行的工作流之一。

5. GitLab Flow GitLab提出的工作流，在GitHub Flow基础上增加了环境分支（如pre-production、production），适合有多个部署环境的项目。

工作流选择建议：

  • 个人项目/小团队：功能分支工作流或GitHub Flow
  • 有明确发布周期的项目：Git Flow
  • 持续发布的Web项目：GitHub Flow
  • 多环境部署的项目：GitLab Flow

不要盲目追求复杂的工作流，适合自己团队的才是最好的。

分支策略

不管用哪种工作流，分支管理都很重要。

分支命名规范：

  • 功能分支：feature/xxx 或 feat/xxx，如feature/user-login
  • Bug修复分支：bugfix/xxx 或 fix/xxx，如fix/login-error
  • 热修复分支：hotfix/xxx，如hotfix/payment-bug
  • 发布分支：release/xxx，如release/v1.2.0
  • 实验分支：experiment/xxx 或 spike/xxx

分支命名要简洁、清晰，能看出分支的用途。

分支操作规范：

  • 从哪个分支切出，就合并回哪个分支
  • 功能分支只做一件事，不要在一个分支里做多个不相关的功能
  • 分支生命周期要短，开发完成后尽快合并，避免分支过时
  • 合并前先rebase或merge主分支，解决冲突
  • 合并后删除已合并的分支，保持仓库整洁

长期分支 vs 短期分支：

  • 长期分支：master、develop，长期存在，受保护，不直接提交
  • 短期分支：feature、bugfix、hotfix、release，用完即删

提交规范

Git提交信息（commit message）很重要，好的提交信息能让团队成员快速了解每次提交做了什么，也方便生成changelog和回溯历史。

Conventional Commits规范： 目前最流行的提交信息规范是Conventional Commits，格式：

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

<body>

<footer>
  • type：提交类型，常见：

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

  • scope：影响范围（可选），如user、auth、api
  • subject：简短描述，不超过50字符
  • body：详细描述（可选）
  • footer：不兼容变更或关闭issue（可选）

示例：

feat(user): add user login feature

- add login page and form
- add backend API for authentication
- add session management

Closes #123
fix(auth): fix login error when password contains special chars

The password field was not properly escaped, causing login
failures for users with special characters in their password.

Closes #456

提交原则：

  • 原子提交：一次提交只做一件事，不要把多个不相关的改动放在一次提交里
  • 提交前自测：提交前自己测试一下，确保代码能运行、没有明显bug
  • 不要提交半成品：功能没做完不要提交（除非用WIP标记）
  • 不要提交敏感信息：密码、密钥、个人信息不要提交到Git
  • 不要提交构建产物：node_modules、dist、.log等加入.gitignore

代码审查

代码审查（Code Review）是保证代码质量的重要环节，也是团队学习和知识共享的好机会。

代码审查流程：

  1. 功能分支开发完成后，提交Pull Request（PR）或Merge Request（MR）
  2. 填写PR描述：做了什么、为什么这么做、测试情况、截图（如有）
  3. 指定审查人，团队成员审查代码
  4. 审查人提出意见和建议，开发者修改
  5. 审查通过后，合并到主分支

代码审查要点：

  • 功能是否正确实现
  • 代码是否清晰、易读、易维护
  • 是否有重复代码、可以优化的地方
  • 是否有安全隐患（SQL注入、XSS、密码明文等）
  • 是否有性能问题
  • 命名是否规范、注释是否充分
  • 测试是否充分
  • 是否符合团队编码规范

代码审查原则：

  • 对事不对人：审查的是代码，不是人，用建设性的语言
  • 小步审查：PR不要太大，最好控制在400行以内，大的PR拆成小的
  • 及时审查：PR提交后尽快审查，不要让开发者等太久
  • 学习机会：代码审查不只是挑错，也是学习和知识共享的机会
  • 自动化辅助：用CI自动运行测试、代码检查（lint）、安全扫描，减少人工审查的负担

发布流程

规范的发布流程，能保证线上稳定，减少发布事故。

发布流程（以GitHub Flow为例）：

  1. 功能分支合并到master后，触发CI自动测试和构建
  2. CI通过后，自动部署到测试环境（staging）
  3. 测试环境验证通过后，手动或自动部署到生产环境
  4. 发布后监控线上状态（错误率、性能、日志）
  5. 打tag标记版本，如v1.2.0
  6. 生成changelog（基于commit message）

热修复流程：

  1. 线上出现紧急bug，从master切出hotfix分支
  2. 在hotfix分支修复bug
  3. 提交PR，紧急审查
  4. 合并到master，紧急发布
  5. 打tag，如v1.2.1
  6. 事后复盘，分析bug原因，避免再次发生

发布原则：

  • 小版本频繁发布：不要攒一大堆功能一起发布，小版本频繁发布风险更小
  • 灰度发布：新功能先给部分用户使用，观察没问题再全量
  • 回滚预案：发布前准备好回滚方案，出问题能快速回滚
  • 发布后监控：发布后密切监控线上状态，及时发现问题
  • 不在周五发布：避免周末出问题没人处理（除非有值班）

常用Git命令

基础命令：

git init                    # 初始化仓库
git clone <url>             # 克隆仓库
git status                  # 查看状态
git add <file>              # 添加文件到暂存区
git add .                   # 添加所有文件
git commit -m "message"     # 提交
git push                    # 推送到远程
git pull                    # 拉取远程更新
git fetch                   # 拉取远程更新但不合并

分支命令：

git branch                  # 查看本地分支
git branch -a               # 查看所有分支（包括远程）
git checkout <branch>       # 切换分支
git checkout -b <branch>    # 创建并切换分支
git merge <branch>          # 合并分支
git rebase <branch>         # rebase分支
git branch -d <branch>      # 删除分支
git push origin --delete <branch>  # 删除远程分支

撤销和回退：

git checkout -- <file>      # 撤销工作区修改
git reset HEAD <file>       # 撤销暂存
git reset --soft HEAD~1     # 回退一次提交，保留修改在暂存区
git reset --mixed HEAD~1    # 回退一次提交，保留修改在工作区（默认）
git reset --hard HEAD~1     # 回退一次提交，丢弃修改（危险！）
git revert <commit>         # 新建一个提交，撤销指定提交
git stash                   # 暂存当前修改
git stash pop               # 恢复暂存的修改

查看历史：

git log                     # 查看提交历史
git log --oneline           # 简洁的提交历史
git log --graph             # 图形化分支历史
git log --author="name"     # 查看某人的提交
git diff                    # 查看工作区修改
git diff --staged           # 查看暂存区修改
git diff <branch1> <branch2>  # 比较两个分支
git show <commit>           # 查看某次提交的详情
git blame <file>            # 查看文件每行的最后修改者

标签：

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      # 推送所有标签

其他最佳实践

1. .gitignore 项目根目录一定要有.gitignore，忽略不需要提交的文件：

  • 依赖目录：node_modules、vendor
  • 构建产物：dist、build、*.log
  • 环境配置：.env、config.local.php
  • 系统文件：.DS_Store、Thumbs.db
  • IDE配置：.idea、.vscode（可选，看团队习惯）

2. README 项目根目录要有README.md，说明项目是什么、怎么安装、怎么运行、怎么贡献。

3. 保护主分支 在GitHub/GitLab上设置master/develop分支为受保护分支，不允许直接push，必须通过PR合并，且需要审查通过和CI通过才能合并。

4. 持续集成（CI） 接入CI（如GitHub Actions、GitLab CI、Jenkins），每次提交自动运行测试、代码检查、构建，保证代码质量。

5. 定期清理 定期删除已合并的分支、清理旧的远程分支，保持仓库整洁。

总结

Git工作流是团队协作的基础，一个好的工作流能让团队协作更高效、代码质量更高、发布更稳定。

重点：

  1. 选择适合团队的工作流（GitHub Flow、Git Flow等）
  2. 规范分支命名和操作
  3. 规范提交信息（Conventional Commits）
  4. 坚持代码审查
  5. 规范发布流程
  6. 用好Git命令和工具
  7. 接入CI自动化

不要盲目追求复杂的工作流，从简单开始，根据团队需要逐步完善。关键是团队达成共识，所有人都遵守规范。

希望这篇文章能帮你的团队建立高效、规范的Git协作模式。