git pull --rebase更适合跨时区团队，因其避免无意义合并提交、保持线性历史，但仅适用于未推送的本地提交；需全局配置pull.rebase true，并用三点式diff和git blame精准定位冲突根源。
为什么git pull --rebase比git pull更适合跨时区团队
因为默认git pull会触发merge提交，而跨地域协作中，不同成员在相近时间提交到同一分支（如main），极易产生无意义的“合并提交”——既污染历史，又让git blame和git bisect失效。
用git pull --rebase能将本地未推送的提交“重放”到最新远程基准上，保持线性历史。但要注意：它只适用于尚未push的本地提交；若已push并被他人基于该提交工作，强制rebase会破坏协作基础。
- 团队应约定：所有人在
push前先执行git pull --rebase - CI/CD流水线需配置
git config --global pull.rebase true，避免新人误用默认merge - 遇到
error: cannot rebase: You have unstaged changes，先git stash再pull --rebase，完成后git stash pop
冲突发生在rebase中途，怎么安全中断并回退
rebase过程中出现冲突时，Git会暂停并提示当前停在哪一个提交（如Stopped at 3a7f1b2... fix login timeout）。此时不能直接git commit或git push，否则会把冲突状态提交上去。
正确做法是先确认是否真要继续——如果发现冲突复杂、时间不够，或想换策略处理，就立刻中止：
- 用
git rebase --abort回到rebase前状态，所有修改保留在工作区 - 若已部分解决冲突并
git add，但还没git rebase --continue，仍可用--abort - 切忌用
git reset --hard强行清理，可能丢失未暂存的编辑
git diff HEAD...origin/main比git diff origin/main更能暴露真实差异
跨地域团队常有人误以为git diff origin/main就能看到自己“将要提交的内容”，其实它只对比工作区与远程分支最新提交的快照，忽略本地已commit但未push的变更。
真正反映“待推送差异”的是三点式diff：git diff HEAD...origin/main。它以HEAD和origin/main的最近共同祖先为基准，展示从那个分叉点起，两边各自独有的变更——这才是你push后别人将看到的实质改动。
- CI脚本里建议用
git diff --quiet HEAD...origin/main判断是否有实质性变更 - 若输出为空，说明本地分支已完全同步，无需
push - 注意：三点式diff不适用于刚
clone或从未fetch过的仓库，需先git fetch
多人同时修改同一文件时，如何快速定位冲突根源而非逐行肉眼比对
当git status显示both modified: src/api/client.ts，别急着打开编辑器硬啃。先用Git自带工具缩小范围：
-
git log -p --merges --oneline origin/main..HEAD查出自己本地有哪些合并提交（如有），确认是否引入了上游改动 -
git show :1:src/api/client.ts查看冲突基础版本（即共同祖先）内容，对比:2:（本地）和:3:（远程）可精准定位谁改了哪块逻辑 - 用
git blame -L 45,+10 origin/main -- src/api/client.ts看关键行在远程分支上是谁、何时、为何修改的——比猜“他是不是改错了”高效得多
真正麻烦的不是冲突本身，而是缺乏上下文判断权责。跨地域团队必须养成在PR描述里注明“此修改是为了支持新加坡时区的定时任务调度”，否则光靠代码diff根本无法评估取舍。
