大多数开发者都会用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：
-
feat：新功能 -
fix：修复bug -
docs：文档更新 -
style：代码格式（不影响功能） -
refactor：重构 -
test：测试相关 -
chore：构建工具、依赖更新
配置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清单
审查者应该关注的要点：
- 正确性：逻辑是否正确，边界情况是否处理
- 可读性：命名是否清晰，代码是否自解释
- 安全性：是否有SQL注入、XSS等安全隐患
- 性能：是否有N+1查询、不必要的循环
- 测试：关键路径是否有测试覆盖
- 一致性：是否符合项目的代码规范
五、实用Git技巧
1. 交互式Rebase整理提交历史
bash
# 整理最近3次提交
git rebase -i HEAD~3
---
*本文首发于[我的技术博客](https://wdsega.github.io)，欢迎访问获取更多技术文章。*
*如果你是内容创作者或自由职业者，推荐看看我整理的[Creator Pro Bundle](https://segauser.gumroad.com/l/rrhmbb)工具包，包含AI提示词系统、内容创作工具、副业指南和自动化脚本，源码全开放。*
Top comments (0)