多人同时改同一分支会导致push失败并报non-fast-forward错误，因远程有本地缺失提交；应避免直接在main/develop写代码，每日开工前先pull以暴露冲突，遇错误优先rebase而非force push。
多人同时改一个分支会出什么问题
直接后果是 git push 失败，报错 rejected: non-fast-forward —— 说明远程分支有你本地没有的提交。这不是 Git 在刁难你，而是它在拦住“覆盖别人工作”的操作。
常见错误现象：有人 git push 成功了，另一个人接着 git push 就被拒；或者强行 git push --force，结果把队友刚合进去的代码冲掉了。
- 别在
main或develop上直接写代码，那是集成出口，不是编辑区 - 每天开工前先
git pull origin main（或对应主干分支），不是为了“同步”，是为了提前暴露冲突 - 如果已经遇到
non-fast-forward，别硬推，先git pull --rebase整理本地提交，再重试
feature 分支命名和生命周期怎么管才不乱
名字不是随便起的，它要能一眼看出“谁、什么时候、干了啥”。比如 alice/login-form-validation 比 fix123 或 new-feature 强太多——前者能定位人、场景、范围，后者等于没写。
使用场景很明确：每个独立需求、修复、实验，都开一个新分支，从 main 或 develop 拉，完成后合并回去，然后立刻删掉本地和远程的该分支。
- 分支名避免用下划线
_，部分 CI 工具（如 GitHub Actions）对_有解析异常，统一用短横线- - 别长期保留 feature 分支，超过 3 天没合入，大概率已偏离主干，冲突成本指数上升
- 删远程分支用
git push origin --delete alice/login-form-validation，别只删本地
PR/MR 合并前必须检查的三件事
合并不是点一下“Merge”就完事。Git 不校验逻辑，只拼提交历史；人不看，bug 就进主干。
真实协作中，90% 的回归问题来自“看起来没问题”的合并：比如改了公共工具函数但没测调用方，或者删了被其他分支临时引用的调试代码。
- 确认 CI 流水线全绿，尤其
test和lint阶段，不是只看“build passed” - 自己切到
main，git merge --no-ff本地试合一次，跑一遍关键路径测试（哪怕只是手动点两下） - 检查变更范围：GitHub/GitLab 的 PR 页面里点 “Files changed”，重点看有没有意外改动（比如 config 文件、.gitignore、无关模块）
rebase 还是 merge？什么时候该选哪个
答案取决于分支性质：feature 分支推荐 git rebase，main 或 release 分支必须用 git merge。
原因很简单：rebase 把你的提交“挪”到主干最新位置，历史线性干净，适合还没公开的本地分支；但一旦分支被他人基于它开发，rebase 就等于重写历史，别人再 pull 就会多出重复提交。
- 在自己的
feature/xxx上做git rebase origin/main是安全的，前提是没推送到远程或已通知队友暂停基于它开发 -
main分支上的每次集成，必须用git merge --no-ff，保留合并点，这是追溯发布边界的关键依据 - 如果用了 rebase 后又推过远程，之后再想 merge，很可能触发大量“虚假冲突”，因为 Git 认为那是全新提交
真正容易被忽略的是：团队得对“分支是否公开”有共识。没人告诉你那个 dev-john 分支是不是已被别人 git clone 并基于开发——所以最省心的做法是：所有远程分支，一律 merge；所有本地未推送分支，按需 rebase。
