多人协作是 Git 的核心使用场景，我按**「标准协作全流程 + 核心规范 + 常见工作流 + 避坑指南」**完整讲解，覆盖99%的团队开发场景：

📌 一、多人协作完整标准流程（按执行顺序）

🔹 第一步：初始准备（只做一次）

  1. 克隆远程仓库到本地
1
2
3
4
5
# 把团队的远程仓库克隆到本地
git clone 远程仓库地址（比如git@github.com:xxx/xxx.git）

# 进入项目目录
cd 项目名
  1. 配置个人信息（全局配置一次即可）
1
2
git config --global user.name "你的名字"
git config --global user.email "你的团队邮箱"

🔹 第二步：日常开发标准流程（每次开发都要走！）

1. 永远先拉取远程最新代码

开发前必须先同步主分支的最新代码，避免后续冲突：

1
2
3
4
5
# 切换到主分支（main/master，看团队命名）
git switch main

# 拉取远程最新代码
git pull origin main

2. 创建自己的功能分支（绝对不要直接在main分支开发！）

1
2
# 基于最新的main分支，创建自己的功能分支，命名按团队规范
git switch -c feature/用户登录功能

✅ 分支命名规范（团队通用）：

  • 功能开发：feature/xxx功能
  • 修复线上bug：hotfix/xxx问题修复
  • 修复普通bug：bugfix/xxx问题

3. 开发+本地提交

1
2
3
# 开发过程中，频繁小步提交（不要攒一大堆再提交）
git add .
git commit -m "feat: 完成登录页面UI开发"

✅ 提交信息规范（团队通用，Angular规范最常用）：

  • feat: xxx 新功能
  • fix: xxx 修复bug
  • docs: xxx 文档修改
  • style: xxx 代码格式调整（不影响逻辑）
  • refactor: xxx 代码重构

4. 开发完成，同步主分支最新代码（解决冲突）

你的分支开发期间，主分支可能已经有别人提交的代码，必须先同步再推送：

1
2
3
4
5
6
7
8
9
10
11
# 1. 先切回主分支，拉取最新代码
git switch main
git pull origin main

# 2. 切回自己的功能分支，把主分支的最新代码合并进来
git switch feature/用户登录功能
git merge main

# 3. 如果有冲突，手动解决冲突后，完成合并
git add 冲突文件
git commit -m "merge: 合并main分支最新代码，解决冲突"

5. 推送自己的分支到远程仓库

1
2
# 第一次推送需要加 -u，后续直接git push即可
git push -u origin feature/用户登录功能

6. 提交合并请求（PR/MR，团队协作核心）

  1. 打开远程仓库页面（GitHub/GitLab/Gitee）
  2. 找到你推送的分支，点击「New Pull Request」（PR）/「Merge Request」（MR）
  3. 填写标题、修改说明，指定评审人，提交PR
  4. 等待同事代码评审，根据评审意见修改代码（修改后直接push到自己的分支，PR会自动更新）
  5. 评审通过后，由负责人合并到主分支

7. 合并完成，清理分支

1
2
3
4
5
6
7
8
9
# 1. 切回主分支，拉取合并后的最新代码
git switch main
git pull origin main

# 2. 删除本地已经合并的功能分支
git branch -d feature/用户登录功能

# 3. （可选）删除远程的功能分支（仓库页面也可以删）
git push origin --delete feature/用户登录功能

📋 二、多人协作核心规范（必须遵守！）

  1. 绝对禁止直接push到main/master主分支，所有修改必须走PR/MR评审
  2. 禁止在公共分支使用rebase/reset --hard，会破坏所有人的提交历史
  3. 小步提交，不要攒大提交：每完成一个小功能就提交，方便回滚和排查问题
  4. 提交前必须本地测试通过，不要把不能运行的代码推到远程
  5. 每天至少拉取一次主分支代码，尽早解决冲突，避免最后攒大冲突
  6. 不要提交敏感信息、大文件、node_modules等依赖包，用.gitignore过滤

🔄 三、团队最常用的2种协作工作流

1. GitHub Flow（最通用，90%中小团队用这个）

✅ 特点：简单、灵活，适合持续交付的团队

  • 只有一个长期主分支 main
  • 所有功能都从main拉feature分支
  • 开发完提PR，评审通过合并到main，立刻部署
  • 线上bug从main拉hotfix分支，修复完合并回main

2. Git Flow（适合大项目、版本发布严格的团队）

✅ 特点：规范严谨，适合有明确版本周期的项目

  • 长期分支：main（线上稳定版）、develop（开发主分支）
  • 临时分支：feature/xxx（从develop拉，开发完合并回develop）、release/x.x.x（版本发布分支）、hotfix/xxx（从main拉，修复线上bug）

⚠️ 四、多人协作常见坑&避坑方案

  1. 冲突太多解决不了？

    • 每天拉取主分支代码，不要等开发完再同步
    • 按功能拆分分支，不要一个分支写太多功能
    • 冲突时先和修改同文件的同事沟通，不要私自覆盖别人的代码

  2. 不小心把错误代码推到远程了？

    • 自己的私有分支：可以用 git reset --hard 然后 git push -f 强制推送
    • 公共分支：绝对不能强制推！用 git revert 生成新提交撤销错误代码

  3. 别人的PR想本地测试？

1
2
3
# 拉取别人的PR到本地测试（PR编号看远程页面）
git fetch origin pull/123/head:test-pr-123
git switch test-pr-123
  1. 多人修改同一份文件，怎么减少冲突？
    • 提前和同事沟通开发范围，尽量避免多人同时改同一个核心文件
    • 按模块拆分文件，降低单文件复杂度