如何为中型团队设计Git分支策略并解决代码冲突？

题目

如何为中型团队设计Git分支策略并解决代码冲突？

信息

• 类型：问答
• 难度：⭐⭐

考点

Git工作流设计,分支管理策略,冲突解决,团队协作规范

快速回答

建议采用改进的Gitflow工作流：

• 主分支：main（生产环境），develop（集成环境）
• 支持分支：feature/*（新功能），release/*（预发布），hotfix/*（紧急修复）
• 协作规范：
  1. 功能分支从develop创建，合并前需Rebase
  2. 发布分支用PR合并到main和develop
  3. 使用git merge --no-ff保留合并记录
• 冲突解决：
  1. 本地解决后提交
  2. 使用git mergetool可视化工具

一、核心分支策略设计

推荐工作流：改进版Gitflow（适合5-20人团队）

main        - 生产环境代码（受保护，仅允许PR合并）
├── develop - 集成测试环境（所有功能合并点）
├── release/* - 预发布分支（版本测试）
├── feature/* - 功能分支（从develop切出）
└── hotfix/*  - 热修复分支（从main切出）

二、关键操作流程

1. 功能开发流程

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

# 定期同步develop变更（避免大冲突）
git rebase develop

# 完成开发后合并
git checkout develop
git merge --no-ff feature/user-auth  # 保留分支历史

2. 冲突解决最佳实践

场景：多人修改同一文件时发生冲突

# 拉取最新代码时检测冲突
git pull origin develop

# 冲突文件会显示标记
<<<<<<< HEAD
本地代码
=======
远程代码
>>>>>>> commit-id

# 手动解决后标记已解决
git add resolved-file.js
git rebase --continue

# 或使用可视化工具
git mergetool  # 配置为VS Code或BeyondCompare

三、团队协作规范

• 分支命名：feature/功能名，hotfix/问题ID
• 合并要求：
  • 功能分支必须通过CI测试
  • PR需至少1人Code Review
  • 合并前Rebase而非Merge Commit
• 保护规则：
  • main/develop分支禁止直接push
  • 强制PR审查机制

四、常见错误与规避

五、扩展知识

• 替代方案：
  • GitHub Flow：适合持续部署团队
  • Trunk-Based Development：适合成熟CI/CD体系
• 工具集成：
  • 使用.gitattributes定义合并策略
  • 配置CI自动检查冲突（如GitLab Merge Train）
• 高级技巧：
  • git rerere自动记录冲突解决方案
  • 交互式Rebase整理提交历史