同一分支多人交替推送必然引发冲突，因git的push是快进式追加而非覆盖上传：a推送后远程指针前移，b本地仍基于旧指针，push时被拒绝以保护历史；正确做法是每次推送前执行git pull --rebase，先fetch再将本地提交重放到远程最新提交之后，避免merge commit并保持历史线性。
为什么同一分支多人交替推送必然引发冲突？
因为 Git 的 push 不是“覆盖式上传”，而是“快进式提交追加”。当 A 推送后，远程分支指针前移；B 本地仍基于旧指针开发，push 时 Git 发现远程已变更，就会拒绝——这不是错误，是保护机制。常见报错：Updates were rejected because the remote contains work that you do not have locally。
每次推送前必须执行 git pull --rebase
直接 git pull 会触发 merge，生成无意义的 Merge branch 'main' into main 提交，污染主线历史。而 git pull --rebase 是安全同步的唯一合理做法：
- 先
fetch远程最新提交（不碰本地工作区） - 再把你的本地未推送提交，“重放”到远程最新提交之后
- 避免 merge commit，保持历史线性
- 若重放过程遇到冲突，会在对应文件中标记
和 <code>=======，此时必须手动解决并git add && git rebase --continue
禁止在 main/dev 分支直接修改和提交
这是所有冲突混乱的源头。真实协作中应严格遵循：
Git Hub Projects V2
下载
使用 gh project CLI 管理 GitHub Projects v2。在代理需要列出待办事项、设置项目字段（如状态、迭代、优先级等）时使用此技能。
- 本地永远不在
main或dev分支写代码 - 所有功能改动必须在独立分支完成：
git checkout -b feature/login-ui - 推送前先切回主线：
git checkout main→git pull --rebase→git checkout feature/login-ui→git rebase main（把功能分支变基到最新主线） - 再
git push origin feature/login-ui，走 PR/MR 流程合并
本地有未提交修改时怎么安全同步？
如果你正在改代码、还没 commit，又急需拉取远程更新（比如别人刚合入关键修复），不能硬 pull —— 会失败或破坏现场。正确顺序是：
-
git stash：把当前工作区和暂存区全部压栈，恢复干净状态 -
git pull --rebase：同步主线 -
git stash pop：把刚才的修改弹出来，Git 会自动尝试应用到新基础上 - 如果弹出后提示冲突，说明你的修改与远程新内容有重叠，需手动编辑冲突文件再
git add→git stash drop
注意：git stash 只保存工作区+暂存区，不包括 untracked 文件（如新写的配置文件），这类文件需提前 git add 或手动备份。
