git merge必须在目标分支上执行：先checkout目标分支（如main），再merge源分支（如feature/login）；误操作需用revert而非reset；冲突解决后须git add标记，合并后及时推送并清理分支。
远程分支合并不是“把代码推过去”，而是先拉取远端最新状态，再在本地完成 merge，最后推回远程——顺序错一步，历史就乱了。
git merge 必须在目标分支上执行
Git 不关心你想“合到哪”，只认当前 HEAD 所在分支。比如要把 feature/login 合入 main，必须：
- 先
git checkout main（确认git status显示 “On branch main”） - 再
git merge feature/login - 如果误在
feature/login分支上执行git merge main，结果是把main合进了功能分支，逻辑反了 - 已 push 远程的错误合并不能用
git reset --hard，得用git revert -m 1 <merge-commit-hash></merge-commit-hash>反转合并提交
git pull --ff-only 是最安全的同步方式
日常同步远程更新时，git pull 默认行为可能悄悄创建合并提交，污染线性历史。用 --ff-only 能强制失败而非妥协：
Cnb Cool Git
下载
CNB 云原生构建平台的 Git 操作技能，支持代码克隆、提交、推送、分支管理、Merge Request 管理、流水线触发与结果读取。初次使用需收集用户的 Git 用户名和邮箱。
-
git pull --ff-only origin main：只允许快进，若本地main已分叉则报错，逼你先处理分歧 - 配合
git fetch origin && git log --oneline main..origin/main可预览差多少提交 - 团队若统一设
git config --global pull.ff only，能从源头减少意外 merge commit - 注意：如果本地
main有未推送的提交，--ff-only一定失败——这不是 bug，是提醒你该变基或沟通了
冲突文件必须用 git add 显式标记解决
编辑器里删掉 、<code>=======、>>>>>> feature/login 三行只是第一步，Git 不会自动识别“你修好了”：
-
git status会明确列出 “Unmerged paths”，这是唯一可信依据 - 改完一个冲突文件后，必须
git add <file></file>，否则git commit会拒绝并提示 “fix conflicts and run git commit” -
git merge --abort会丢弃所有已add的解决状态，重来一遍；真要放弃前，先记下哪些文件已add - 不要依赖 IDE 的“一键解决”，尤其涉及逻辑合并（比如两边都加了同一函数但参数不同），手动核对才是底线
合并后必须清理本地和远程分支
本地 git merge 成功只是第一步，不推、不删，协作链就断在你这里：
-
git push origin main推送合并结果（假设目标是main） -
git branch -d feature/login安全删除本地分支（-d检查是否已完全合并，未合并会拒绝） -
git push origin --delete feature/login手动删远程分支——Git 从不自动同步这个动作 - 如果远程分支被其他人还在用，删之前务必确认（比如看 CI 状态、问 Slack 频道），否则可能打断别人构建
最容易被忽略的是：远程分支的引用信息不会自动刷新。哪怕你刚 git push --delete 了 feature/login，下次 git branch -a 还会显示 remotes/origin/feature/login，得靠 git fetch --prune 或 git remote prune origin 清理本地缓存的远程指针。
