大多数开发者都会用Git的基本操作——add、commit、push、pull。但当团队从3个人扩展到15个人，从单仓库到多仓库协作时，简单的git操作就不够用了。分支策略混乱、合并冲突频发、代码回滚困难……这些问题如果不系统性地解决，会严重拖慢团队效率。这篇文章从分支策略、工作流设计、冲突解决到实用技巧，帮你建立完整的Git团队协作体系。

一、选择适合团队的分支策略

1. Git Flow：适合发布周期明确的项目

main ─────────────────────────────────── release ────
  \                    /              /
develop ── feature/A ── feature/B ────
              \          /
hotfix ──────────────────────────────────────────────

适用场景：有明确版本发布计划的项目（如SaaS产品、移动App）

# 创建开发分支
git checkout -b develop main

# 从develop创建功能分支
git checkout -b feature/user-auth develop

# 功能完成后合并回develop
git checkout develop
git merge --no-ff feature/user-auth
git branch -d feature/user-auth

# 发布时从develop创建release分支
git checkout -b release/1.2.0 develop
# 测试修复bug后合并到main和develop
git checkout main
git merge --no-ff release/1.2.0
git tag -a v1.2.0

# 紧急修复从main创建hotfix
git checkout -b hotfix/critical-bug main
git checkout main
git merge --no-ff hotfix/critical-bug
git checkout develop
git merge --no-ff hotfix/critical-bug

2. GitHub Flow：适合持续部署的项目

main ───────────────────────────────────
  \        \          \
feature/A  feature/B  feature/C

适用场景：Web应用、持续部署的项目

# 始终从最新的main创建分支
git checkout main
git pull origin main
git checkout -b feature/new-dashboard

# 开发完成后推送并创建Pull Request
git push origin feature/new-dashboard
# 在GitHub上创建PR，请求code review

# PR通过后合并到main，自动部署
git checkout main
git pull origin main
git branch -d feature/new-dashboard

3. Trunk-Based Development：适合成熟团队

main ─── commit ─── commit ─── commit ─── commit
         \          /
          feature (short-lived)

适用场景：团队成熟度高，有完善的CI/CD和自动化测试

核心思想是：所有人都在main（或trunk）上开发，功能分支存活时间不超过1-2天，通过Feature Flag控制未完成功能的上线。

二、规范化Commit Message

好的commit message能让团队协作效率提升一个量级。推荐使用Conventional Commits规范：

# 格式
<type>(<scope>): <subject>

<body>

<footer>

# 示例
feat(auth): 添加JWT令牌刷新机制

实现access_token过期后自动使用refresh_token获取新令牌的功能。
refresh_token有效期为7天，过期后需要重新登录。

Closes #123

常用type：

配置commit模板：

# ~/.gitmessage
# <type>(<scope>): <subject>
#
# <body>
#
# <footer>
#
# Type:
# feat:     新功能
# fix:      修复bug
# docs:     文档更新
# refactor: 重构
# test:     测试
# chore:    构建/工具

git config --global commit.template ~/.gitmessage

三、合并冲突的预防和解决

预防冲突的最佳实践

# 1. 频繁同步主分支
git fetch origin
git rebase origin/main

# 2. 保持功能分支短小
# 功能分支存活时间不超过3天
# 每个分支只做一件事

# 3. 明确模块边界
# 不同开发者负责不同文件/目录
# 减少对同一文件的修改

# 4. 使用.gitattributes标记冲突策略
# .gitattributes
package-lock.json merge=ours
yarn.lock merge=ours

解决冲突的步骤

# 1. 拉取最新代码
git fetch origin
git rebase origin/main

# 2. 如果出现冲突
# Auto-merging src/auth/login.py
# CONFLICT (content): Merge conflict in src/auth/login.py

# 3. 查看冲突文件
git status
# both modified:   src/auth/login.py

# 4. 打开文件，找到冲突标记
# <<<<<<< HEAD
# 当前分支的代码
# =======
# 被合并分支的代码
# >>>>>>> feature/user-auth

# 5. 手动解决冲突后
git add src/auth/login.py
git rebase --continue

# 6. 如果解决不了，可以放弃
git rebase --abort

使用merge tool提高效率

# 配置VS Code作为merge tool
git config --global merge.tool vscode
git config --global mergetool.vscode.cmd \
  'code --wait $MERGED'

# 使用merge tool
git mergetool

四、代码审查工作流

Pull Request模板

在仓库根目录创建.github/pull_request_template.md：

## 变更说明
<!-- 描述这个PR做了什么 -->

## 变更类型
- [ ] 新功能 (feat)
- [ ] Bug修复 (fix)
- [ ] 重构 (refactor)
- [ ] 文档 (docs)

## 测试
- [ ] 已添加单元测试
- [ ] 已通过所有CI检查
- [ ] 已手动测试

## 关联Issue
<!-- 关联相关的Issue，如 Closes #123 -->

## 截图（如有UI变更）
<!-- 添加截图 -->

Code Review清单

审查者应该关注的要点：

  1. 正确性：逻辑是否正确，边界情况是否处理
  2. 可读性：命名是否清晰，代码是否自解释
  3. 安全性：是否有SQL注入、XSS等安全隐患
  4. 性能：是否有N+1查询、不必要的循环
  5. 测试：关键路径是否有测试覆盖
  6. 一致性：是否符合项目的代码规范

五、实用Git技巧

1. 交互式Rebase整理提交历史

# 整理最近3次提交
git rebase -i HEAD~3

# 在编辑器中：
# pick abc1234 第一个功能
# squash def5678 第二个功能（合并到上一个）
# reword ghi9012 第三个功能（修改提交信息）

2. Cherry-pick精确提取提交

# 从其他分支提取特定提交
git cherry-pick abc1234

# 提取多个提交
git cherry-pick abc1234 def5678

# 如果有冲突，解决后继续
git cherry-pick --continue

3. Stash暂存工作区

# 暂存当前修改
git stash save "正在开发用户认证功能"

# 查看暂存列表
git stash list

# 恢复最近的暂存
git stash pop

# 恢复特定暂存
git stash pop stash@{2}

# 创建分支并应用暂存
git stash branch feature/auth stash@{0}

4. Bisect二分查找引入bug的提交

# 开始二分查找
git bisect start
git bisect bad          # 当前版本有bug
git bisect good abc1234 # 这个版本没有bug

# Git会自动checkout中间的提交，你测试后标记
git bisect good  # 这个版本没问题
git bisect bad   # 这个版本有问题
# 重复直到找到引入bug的提交

# 结束查找
git bisect reset

5. 优雅地回滚

# 撤销工作区的修改（未add）
git checkout -- file.py

# 撤销暂存区的修改（已add未commit）
git reset HEAD file.py

# 撤销最近的提交（保留修改）
git reset --soft HEAD~1

# 撤销最近的提交（丢弃修改）
git reset --hard HEAD~1

# 安全地撤销已push的提交（创建新的提交来撤销）
git revert abc1234

# 撤销多个提交
git revert abc1234 def5678

六、团队Git规范建议

  1. 保护main分支：设置分支保护规则，禁止直接push，必须通过PR合并
  2. 要求CI通过：PR必须通过所有自动化检查才能合并
  3. 限制合并权限：至少需要1-2个reviewer批准
  4. 定期清理分支：已合并的分支及时删除，保持仓库整洁
  5. 使用.gitignore：避免提交不必要的文件（IDE配置、临时文件等）
# 设置分支保护（通过GitHub CLI）
gh api repos/{owner}/{repo}/branches/main/protection \
  -X PUT \
  -f required_pull_request_reviews='{"dismiss_stale_reviews":true,"required_approving_review_count":2}' \
  -f required_status_checks='{"strict":true,"contexts":["ci/test","ci/lint"]}' \
  -f enforce_admins=true

总结

Git工作流没有”唯一正确”的答案，关键是选择适合团队规模的策略：

无论选择哪种策略，核心原则不变：频繁提交、小步前进、清晰沟通、规范操作。 Git是工具，真正决定协作效率的是团队对规范的执行力度。