必须先合hotfix再合feature最后同步develop，否则引发幽灵错误；hotfix优先级最高，需保留独立提交历史；feature须等hotfix推送后再合并；develop必须用merge而非rebase同步；每次merge后需人工核对diff确认修复生效。
必须先合 hotfix，再合 feature，最后同步回 develop —— 顺序错了，冲突会变“幽灵错误”，本地验证通过但线上出问题。
hotfix 必须最先合并到 main
hotfix 分支修复的是线上紧急问题，它的变更优先级最高。如果先合并了 feature 分支，再合 hotfix，Git 可能自动选择 feature 的版本覆盖 hotfix 的修复（尤其当两分支修改同一文件但无直接共同祖先时）。
- 执行前确保
main是干净且最新的：git checkout main && git pull origin main - 用
git merge hotfix/timeout合并，不要加--no-ff或--squash—— 需要保留 hotfix 的独立提交历史，方便回滚 - 合并后立刻跑冒烟测试，确认修复生效；再
git push origin main
feature 分支要等 hotfix 推送后再合
feature 分支开发时基于的 main 很可能不含 hotfix 提交。如果在 hotfix 推送前就合并 feature，相当于把“没包含 hotfix 修复”的代码直接上线，风险极高。
batch-git-url-replace
下载
批量替换指定目录下所有 Git 仓库的远程地址（remote URL）。 当用户需要将 Git 仓库从一个服务器迁移到另一个服务器时使用。 触发词：git remote 替换、git url 批量修改、git 仓库迁移、更换 git 地址、批量修改 remote url。
- 切回
main后先git pull origin main—— 这一步不能省，否则你 merge 的是旧版 main - 再
git merge feature/payment，此时 Git 能正确识别 hotfix 已存在，冲突提示更准确 - 若多个 feature 并行，按依赖关系排序：比如
feature/order依赖feature/user，就得先合 user 再合 order
develop 分支必须最后同步，且要用 merge 而非 rebase
很多人图省事对 develop 执行 git rebase main，结果导致团队其他人的本地分支失效、提交哈希全变、协作中断。
- 正确做法是切到
develop，git pull origin develop，然后git merge main - 这样会在
develop上生成一个 merge commit，历史可追溯，且不破坏他人本地分支 - 如果
develop和main之间有大量无关提交（比如未合入的 feature），Git 会提示“Already up to date”——这是正常现象，别强行 rebase
最容易被忽略的点：每次 git merge 后，别只看命令行没报错就认为完事。打开 IDE 查看实际改动，确认 hotfix 的关键行确实出现在最终 diff 里 —— 有些冲突 Git 自动解决得“太聪明”，反而删掉了你真正要保留的修复逻辑。
