多人协作禁用直接 push 到 main 分支，必须经 pr/mr 流程确保代码审查、测试验证与冲突预判；推荐语义化分支命名、启用分支保护规则，并规范 rebase 与 merge 使用场景。
多人协作时，为什么不能直接 push 到 main 分支
因为直接 push 会绕过代码审查、测试验证和冲突预判，极易引入未测试逻辑或覆盖他人修改。主流团队都禁用对 main（或 master）的直接写入权限，必须走 Pull Request（PR）或 Merge Request（MR）流程。
实操建议：
- 所有功能开发都在独立分支进行，命名建议带语义，如
feat/user-login、fix/api-timeout - 远程仓库应配置 branch protection rule，禁止直接 push 到
main，并要求至少 1 个 approval + CI 通过才能合并 - 本地误操作 push 到
main后，若尚未被他人 pull，可用git push --force-with-lease origin main安全回退；但切勿用--force
rebase 还是 merge？在协作中怎么选
关键看团队对历史线性的要求：rebase 让提交线性干净，但会改写 commit hash；merge 保留真实协作时间线，但可能产生大量 merge commit。
实操建议：
- 个人开发分支同步
main时，优先用git rebase origin/main—— 避免无意义的“Merge branch 'main'”提交 - PR/MR 合并时，一律用 merge（平台默认行为），不点 squash or rebase，除非团队明确约定 squash 提交
- 切忌在已 push 的公共分支上执行
git rebase，否则其他人git pull会遇到 divergent history，需手动git pull --rebase或重置本地分支
如何避免“我本地没问题，CI 却失败”这类问题
根本原因是本地环境与 CI 环境不一致：Node.js 版本、依赖锁文件、Git hook 是否启用、甚至换行符（core.autocrlf）都可能引发差异。
实操建议：
- 确保
package-lock.json（npm）或yarn.lock（Yarn）已提交，并在 CI 中严格按 lock 文件安装依赖 - 本地开发前运行
git checkout main && git pull && npm ci（或yarn install --frozen-lockfile），模拟 CI 清洁安装流程 - 在
.gitattributes中统一设置* text=auto eol=lf，防止 Windows/Mac/Linux 换行符混用导致测试失败 - 把常用检查脚本（如
npm run lint、npm test）加入 pre-commit hook（推荐用Husky），提前拦截问题
遇到冲突合并不了，该怎么安全处理
冲突不是错误，而是 Git 在说：“这两段修改你得亲自确认哪段该留”。强行跳过或硬删标记行（ / <code>==== / >>>>）常导致逻辑丢失。
实操建议：
- 先用
git status看哪些文件冲突，再用git diff查看当前 vs incoming 变更细节 - 编辑冲突文件时，不要只删冲突标记，而要逐块判断：保留自己改的？采纳对方的？还是合并两者逻辑？
- 解决后用
git add <file></file>标记为已解决，**不能跳过这步直接git commit**，否则 Git 不认为冲突已处理 - 如果卡在中间想放弃，可用
git merge --abort回退到合并前状态（仅限未 commit 前）
实际协作中最容易被忽略的，是每天开始工作前没执行 git pull --rebase origin/main 同步最新主干 —— 这会让后续 PR 越积越多冲突，也会让 CI 测试基于过期基线运行。
