git多人协作的工作流程【汇总】

多人协作禁用直接 push 到 main 分支，必须经 PR/MR 流程确保代码审查、测试验证与冲突预判；推荐语义化分支命名、启用分支保护规则，并规范 rebase 与 merge 使用场景。

多人协作时，为什么不能直接 push 到 main 分支

直接往主分支推送代码，听起来很高效，实则隐患重重。这相当于绕过了所有质量关卡——代码审查、自动化测试、潜在的合并冲突预判，全都没了。结果呢？未经充分验证的逻辑、甚至可能直接覆盖队友刚提交的修改，就这么悄无声息地混了进去。正因如此，如今但凡规范一点的团队，都会锁定 main（或 master）分支的写入权限，强制要求所有变更都必须通过 Pull Request（PR）或 Merge Request（MR）流程来合并。

具体怎么做？记住这几个要点：

• 分支策略是基础：所有新功能或修复，都必须在独立分支上进行。分支名最好自带语义，比如 feat/user-login、fix/api-timeout，一目了然。
• 锁死主分支：在远程仓库（如 GitHub、GitLab）配置分支保护规则（branch protection rule），禁止直接 push 到 main，并设置合并条件，比如至少需要一个审核人批准，且所有 CI 检查必须通过。
• 误操作了怎么办？：如果不小心本地 push 到了 main，且还没被其他人拉取，可以用 git push --force-with-lease origin main 安全地回退。但切记，绝对不要轻易使用粗暴的 --force 选项。

rebase 还是 merge？在协作中怎么选

这是个经典的选择题。选哪个，核心取决于团队对提交历史“整洁度”的追求。Rebase 能重整提交时间线，让历史记录变成一条清晰的直线，但代价是它会改写提交的哈希值（hash）。Merge 则保留了真实的协作脉络，每次合并都会生成一个合并提交（merge commit），历史更完整，但也可能显得有些“枝繁叶茂”。

那么实践中如何取舍？可以遵循一个简单的原则：

• 同步更新时，用 rebase：当你正在自己的特性分支上开发，需要同步主干的最新改动时，优先使用 git rebase origin/main。这样能避免在历史里留下一大堆“Merge branch 'main'”这类无实际内容的提交。
• 合并入主干时，用 merge：在 PR/MR 界面点击合并时，默认使用 merge 方式（即平台的标准行为）。除非团队有明确约定，否则不要轻易选择 squash（压缩提交）或 rebase 合并，以免带来意外。
• 一条红线：绝对不要在已经推送到远程的公共分支上执行 git rebase。否则，你的队友执行 git pull 时会遇到令人头疼的分支偏离（divergent history）问题，不得不手动处理。

如何避免“我本地没问题，CI 却失败”这类问题

这个问题太常见了，根源几乎总是“环境不一致”。你以为万事俱备，但 CI 环境里的 Node.js 版本、依赖包、甚至文件换行符，都可能和你的本地机器有微妙差别。

想从根本上减少这类“灵异事件”？试试下面这几招：

• 锁死依赖：务必把 package-lock.json（npm）或 yarn.lock（Yarn）提交到仓库。并且确保 CI 流水线是严格根据这份锁文件来安装依赖的，而不是每次都重新解析。
• 模拟 CI 环境：开始一天的工作前，不妨先执行一套标准动作：git checkout main && git pull && npm ci（或 yarn install --frozen-lockfile）。这能最大程度地让你本地的依赖状态与 CI 保持一致。
• 统一文本格式：在项目根目录的 .gitattributes 文件中设置 * text=auto eol=lf，可以强制统一换行符，避免因 Windows、Mac、Linux 系统差异导致脚本或测试失败。
• 前置检查：把代码规范检查（lint）和单元测试（test）等脚本，通过工具（如 Husky）加入到 pre-commit 钩子中。让问题在本地提交前就被拦截，别等到 CI 才报错。

遇到冲突合并不了，该怎么安全处理

首先得摆正心态：遇到合并冲突，不是 Git 在给你找麻烦，而是它在提醒你：“这两处修改有重叠，需要你亲自裁决一下。” 如果为了图省事，直接删除那些冲突标记（<<<< / ==== / >>>>），很可能会丢失重要的代码逻辑。

安全处理的流程应该是这样的：

• 看清战场：先用 git status 看看哪些文件陷入了冲突，再用 git diff 仔细对比冲突区块的细节，搞清楚“当前分支的修改”和“要合并进来的修改”分别是什么。
• 手动仲裁：打开冲突文件，逐块审视。是保留自己的改动？采纳对方的版本？还是需要将两者的逻辑巧妙地融合起来？手动编辑，做出决定。
• 标记解决：每个冲突文件处理完后，必须执行 git add 来告诉 Git 这个文件的冲突已经解决。千万别跳过这步直接去 git commit。
• 留有退路：如果解决到一半发现情况复杂，想从头再来，只要还没完成提交，都可以用 git merge --abort 命令安全地撤销合并，回到操作前的状态。

话说回来，协作中最容易踩的坑，往往是最简单的步骤被忽略了：比如每天开工前，没有习惯性地执行 git pull --rebase origin/main 来同步最新主干。这个小小的疏忽，会让你的分支基于陈旧的代码基线，导致后续的 PR 积累大量冲突，CI 测试的结果也失去了参考意义。养成好习惯，事半功倍。