正确做法是先同步远程最新状态：切到develop分支，执行git fetch origin再merge或reset；禁止直接在过时分支上merge；冲突须本地解决并验证；合并后立即删除远程feature分支；严禁对公共分支使用--force推送。
git merge 前必须更新目标分支
直接在过时的 develop 分支上执行 git merge feature/login，大概率会引入隐藏冲突或覆盖他人已合并的代码。这不是“能不能合”的问题，而是“合完是不是真可用”的问题。
正确做法是先同步远程最新状态：
git checkout develop-
git fetch origin（只拉元数据，不改本地） -
git merge origin/develop或git reset --hard origin/develop（后者适合确认无本地提交时）
注意：git pull 看似省事，但它把 fetch + merge 合成一步，容易掩盖中间状态。比如你本地 develop 有未推送的提交，pull 会直接 merge 进去，而你根本没意识到——这会让后续排查“谁改了什么”变得困难。
冲突解决必须在本地完成，不能靠 CI 或同事善后
CI 流水线里报 CONFLICT (content): Merge conflict in src/api/auth.js，说明你跳过了最关键的一步：在发起 PR 前，自己先跑通一次合并。
标准动作链是：
- 切到
develop，确保它是最新版 -
git merge --no-ff feature/login（加--no-ff强制生成合并提交，历史可追溯） - 手动编辑冲突文件，删掉
/ <code>=======/>>>>> feature/login标记，保留逻辑正确的代码 -
git add <file></file>标记已解决，git commit提交合并结果 - 本地验证：能编译、能启动、关键路径走通
很多团队卡在“PR 一直红”，根源就是把冲突解决推给合并按钮——Git 不会猜你要哪段逻辑，它只标记分歧点。
feature 分支合并后必须删除远程分支
不删 origin/feature/login，会导致三个实际问题：
- 下次新建
feature/login时，Git 可能因远程同名分支存在而拒绝创建（取决于配置） - 分支列表越来越长，
git branch -a输出几十页，真正要找的分支被淹没 - 有人误从旧
feature/login继续开发，再提 PR，造成重复功能或逻辑错乱
删除命令很简单：git push origin --delete feature/login。建议在 PR 被合并后立刻执行——别等“回头再删”，回头就忘了。
禁止对公共分支使用 git push --force
git push --force 在 feature 分支上偶尔可用（前提是确认没人基于它开发），但只要涉及 develop、main、release 这类共享分支，就是高危操作。
它真正干的事是：用你的本地提交历史，完全覆盖远程分支当前指向的整个提交链。后果包括：
- 别人刚基于
origin/develop拉出的feature/order，rebase 后可能丢失关键修复 - CI 流水线记录的构建产物与实际代码不一致（因为 commit hash 对不上）
- 线上回滚时找不到对应 commit，因为那个 commit 已被强制移除
如果真需要重写历史（比如误提交密码），正确做法是：联系管理员协调时间窗口，所有人暂停推送，用 git push --force-with-lease 替代 --force，它至少会检查远程是否已被他人更新。
