<span style="font-family:inherit;font-size:16px;font-weight:400;">以下为国内互联网团队通用的标准协作流程，覆盖95%以上的团队开发场景，所有流程均遵循「主干干净、历史可追溯、低冲突」的协作原则。</span>

一、GitHub Flow 标准协作流（最主流·轻量PR模式）

适用场景：中小团队、持续交付模式、敏捷迭代，是目前企业最常用的协作工作流
核心规则：

main/master 为受保护的生产主干，禁止直接推送代码
所有功能/修复均在独立 feature 分支开发
必须通过 Pull Request(PR)/Merge Request(MR) 代码评审后，才能合并入主干

完整执行步骤

# 1. 切换到主干，拉取最新代码（保证分支基于最新版本）
git checkout main
git pull origin main

# 2. 创建功能分支，团队统一命名规范：feature/需求ID-功能描述
git checkout -b feature/20240710-user-center

# 3. 本地开发，小步高频提交
git add .
git commit -m "feat: 完成用户中心个人信息接口"
# 可多次提交，遵循团队统一的提交规范

# 4. 提交PR前，同步主干最新代码（核心步骤，大幅减少线上冲突）
git stash                # 暂存未提交的半成品代码（如果有）
git fetch origin main    # 拉取远程主干最新状态
git rebase origin/main   # 用变基方式同步，保持提交历史线性整洁
# 若出现冲突，按后文「冲突解决模板」处理后再继续
git stash pop            # 恢复暂存的代码

# 5. 推送分支到远程仓库
git push origin feature/20240710-user-center

# 6. 在代码平台（GitHub/GitLab/Gitee）发起 PR，指定合并目标为 main
# → 等待团队成员代码评审、CI 自动化检查通过
# → 评审通过后，在平台上点击合并（推荐 Squash Merge 或 Rebase Merge）

# 7. 合并完成后，本地收尾清理
git checkout main
git pull origin main          # 拉取合并后的最新主干
git branch -d feature/20240710-user-center  # 删除本地功能分支
git fetch -p                  # 清理远程已删除的分支引用

二、每日开工：分支同步主干模板（团队必做）

适用场景：每天上班开发前、提交 PR 前执行，是降低团队冲突概率最有效的手段
推荐方式：使用 rebase 同步，保证分支提交历史线性，无多余合并节点

标准同步流程（有未提交代码也能执行）

# 1. 暂存当前工作区未提交的代码
git stash save "临时暂存-未完成开发"

# 2. 拉取远程主干最新代码
git fetch origin main

# 3. 将当前功能分支变基到最新主干上
git rebase origin/main

# 👉 若执行后出现冲突，按后文冲突模板解决，执行 git rebase --continue 完成

# 4. 恢复之前暂存的工作代码
git stash pop

简易同步流程（代码已全部提交，无半成品）

git pull --rebase origin main

三、团队协作冲突标准化解决模板

冲突是团队协作的常态，核心原则：先本地解决冲突，再提交PR，不要把冲突留到线上处理

场景1：Rebase 同步主干时的冲突（最常见）

# 1. 变基中断后，查看冲突文件
git status
# 标记为 both modified 的文件即为冲突文件

# 2. 逐个打开冲突文件，手动编辑保留正确代码，删除所有冲突标记
# 冲突标记说明：
# <<<<<<< HEAD  → 当前分支你的代码
# =======      → 分隔线
# >>>>>>> xxx  → 主干/目标分支的代码

# 3. 全部修改完成后，标记文件为已解决
git add <冲突文件路径>

# 4. 继续执行变基（后续可能还有多轮冲突，重复上述步骤）
git rebase --continue

# 👉 应急回退：不想解决了，完全取消本次变基
git rebase --abort

场景2：Merge 合并时的冲突

# 1. 查看所有冲突文件
git status

# 2. 手动修改冲突文件，保留正确代码

# 3. 标记冲突已解决
git add <冲突文件>

# 4. 完成合并
git merge --continue

# 👉 应急回退
git merge --abort

四、线上 Hotfix 紧急修复团队流

适用场景：生产环境突发bug，需要全团队同步执行的标准修复流程
核心规则：从主干拉分支，修复后合并主干并打标签，同步到所有开发分支

# 1. 从生产主干拉取热修复分支
git checkout main
git pull origin main
git checkout -b hotfix/支付回调异常修复

# 2. 修复问题，提交代码
git add .
git commit -m "fix: 修复支付回调签名校验失败问题"

# 3. 推送远程，发起 Hotfix PR，评审测试通过后合并入主干
git push origin hotfix/支付回调异常修复

# 4. 合并到主干后，打版本补丁标签
git checkout main
git pull origin main
git tag -a v1.2.1 -m "热修复：修复支付回调异常"
git push origin v1.2.1

# 5. 关键：同步修复内容到开发分支（避免后续版本把bug带回来）
git checkout develop
git pull origin develop
git cherry-pick <修复提交的commit哈希>
# 或直接合并：git merge hotfix/支付回调异常修复

# 6. 清理分支
git branch -d hotfix/支付回调异常修复

五、团队协作高频运维指令

1. 查看团队提交进度

# 查看所有人最近一周的提交记录
git log --since="1 week ago" --oneline

# 按作者统计提交次数
git shortlog -sn

2. 批量清理本地已合并分支

# 先同步远程分支状态
git fetch -p

# 查看所有已合并到main的本地分支
git branch --merged main

# 批量删除（排除main分支），手动执行删除更安全
git branch -d <分支1> <分支2>

3. 安全强制推送（团队协作禁止直接用 --force）

# 仅当自己的feature分支需要覆盖远程时使用，不会覆盖别人的提交
git push --force-with-lease origin <你的分支名>

团队协作核心规范提醒

禁止直接向 main/master 推送代码，所有改动必须走 PR/MR 评审
功能分支周期不超过3天，长周期分支必须每天同步主干
仅在自己的私有功能分支上执行 rebase/强制推送，绝对不要在公共主干执行
提交信息遵循团队统一规范，方便问题追溯与版本管理

团队合作最常用的Git 工作流指令模板