必须先拉最新主干再merge最后push：因本地main落后远程，Git拒绝non-fast-forward推送以防覆盖他人提交；漏掉git pull origin main是生产环境合并失败最常见原因。
必须先拉最新主干，再 merge，最后 push —— 三步缺一不可，漏掉 git pull origin main 是生产环境合并失败最常见原因。
为什么 git merge 后 push 失败报 “non-fast-forward”
这不是权限问题，而是你本地 main 分支落后于远程。Git 拒绝覆盖别人已推送的提交。现象是：git status 显示 “Your branch is ahead of 'origin/main' by 1 commit”，但 git push origin main 直接失败。
- 根本原因：合并前没执行
git pull origin main，导致你的本地main还停留在旧提交上 - 验证方式：运行
git log --oneline -n 3 origin/main和git log --oneline -n 3 main，对比 HEAD 是否一致 - 修复动作：先
git pull origin main，再git merge feature/login（可能触发新冲突） - 别用
git push --force强推 —— 会丢弃他人提交，生产环境严禁
git merge feature/x 与 git merge --squash feature/x 的实际区别
不是“要不要压缩提交”的风格问题，而是影响后续协作的关键设计选择。
Cnb Cool Git
下载
CNB 云原生构建平台的 Git 操作技能，支持代码克隆、提交、推送、分支管理、Merge Request 管理、流水线触发与结果读取。初次使用需收集用户的 Git 用户名和邮箱。
-
git merge feature/x：保留整个分支所有提交历史，生成一个 merge commit。适合长期迭代的功能分支，方便回溯每轮修改 -
git merge --squash feature/x：把feature/x所有改动暂存为一次变更，不自动提交；必须手动git commit -m "feat: xxx"。适合一次性修复或小功能，主线历史干净 - 注意：--squash 后
git branch -d feature/x会报 “branch not fully merged”，这是正常行为，不是错误 - 如果
feature/x后续还要继续开发，千万别用 --squash，否则再次 merge 会重复应用已 squash 过的改动
合并冲突时，编辑文件的底线规则
冲突标记（<<<<< HEAD、=======、>>>>> feature/x）不是注释，是 Git 的解析锚点 —— 删一半留一半会导致后续操作失败。
- 必须整块删除，包括所有三行标记，只保留你最终决定保留的代码
- 改完后必须
git add <file>，否则git commit会拒绝（Git 仍认为该文件处于冲突状态） - 不要用 IDE 的“accept theirs / accept ours”一键解决后就直接 commit —— 先
git status确认所有冲突文件都已added，再 commit - 冲突解决后建议快速验证：跑一遍关键单元测试，或至少
git diff --cached看下暂存区内容是否符合预期
真正容易被忽略的点是：git pull origin main 不只是“同步代码”，它决定了 merge 的基线版本。生产环境里，哪怕只差一个提交，也可能让本该自动 fast-forward 的合并变成带冲突的三方合并 —— 这个细节，比选 merge 还是 rebase 更影响交付稳定性。
