每日开工执行 git pull --rebase origin/develop 是必须动作，旨在主动暴露并解决潜在冲突，避免延迟爆发导致逻辑混淆、修复困难；需正确处理冲突标记、禁用 --force 推送、清理临时提交以维护历史整洁。
多人共用 develop 分支时，冲突不是“能不能避免”，而是“什么时候暴露、谁来解决”。强行绕开冲突只会让问题延迟爆发，最终更难收场。
为什么 daily git pull --rebase 是必须动作
不是为了“拿到最新代码”，而是主动把潜在冲突提前暴露在自己本地——此时上下文清晰、改动量小、逻辑归属明确。等写完 200 行再拉，冲突混着别人刚合入的业务逻辑，根本分不清哪段该留、哪段是冗余。
- 每天开工第一件事：
git pull --rebase origin/develop - 如果报
no tracking information，先执行：git branch --set-upstream-to=origin/develop develop - 别用
git pull（默认 merge），它会生成无意义的 merge 提交，破坏历史线性，也掩盖真实修改顺序
冲突标记怎么删才不丢逻辑
VSCode 或 IDEA 会高亮，但底层还是靠三段文本锚点识别： 是你本地改的，<code>======= 是分界，>>>>> origin/develop 是别人推上来的。机器只负责标出差异，不理解业务意图。
- 不能只删标记行，必须人工比对两段代码：哪段保留？要不要合并？比如一个改了返回值类型，一个加了参数校验，得都留
- 删完立刻检查语法：
if是否配对、括号是否闭合、分号是否遗漏——IDE 不会帮你校验逻辑正确性 - 别依赖 IDE 的 “Accept Current” 或 “Accept Incoming”，它们只适合互斥改动（比如注释 vs 删除），多数业务逻辑需逐行判断
push 被拒后为什么不能 --force
看到 rejected: non-fast-forward 就该停手。这不是网络或权限问题，是 Git 在保护协作秩序。
-
git push --force可能直接抹掉队友刚推送的提交，尤其当 CI/CD 已触发构建时，会导致测试环境跑错版本、部署失败甚至线上异常 - 正确做法是立即
git pull --rebase origin/develop，重新整理本地提交；如果 rebase 中又冲突，说明别人又推了新东西——这是常态，按前面方法再解一次 - 确认无冲突后，直接
git push即可，不用加分支名或--force（只要 upstream 已设置）
临时提交怎么清理才不影响历史
多人共用分支时，没人自动帮你擦掉调试用的 git commit -m "test" 或 "fix typo"。这些提交一旦 push，就永远留在远程历史里。
- 日常小修建议用
git commit --amend合并到上一个提交，避免碎提交 - 如果已有多次提交，用
git rebase -i HEAD~3交互式整理：合并、重写、删除不需要的提交 - 切忌在 rebase 过程中跳过冲突文件的
git add—— 没git add就git rebase --continue，会反复卡住
真正容易被忽略的，不是怎么解冲突，而是每天开工前那一次 git pull --rebase —— 它不产生代码，却决定了当天是顺畅推进，还是陷入三小时冲突泥潭。
