git merge 比 git rebase 更安全，因为 merge 不改已有提交，只新增合并提交以完整保留原始历史；而 rebase 会重写提交历史、生成新 hash，强制推送易破坏他人本地历史，导致协作混乱和 CI/CD 构建失败。
git merge 是分支间同步代码最安全快捷的方式，前提是目标分支已提交干净、无未暂存修改，且你明确接受合并提交带来的历史分叉。
为什么 git merge 比 git rebase 更安全？
因为 rebase 会重写提交历史：它把源分支的提交逐个“搬”到目标分支最新提交之后，并生成全新 commit hash。一旦推送过原分支，再 rebase 后强制推送（git push --force）会破坏他人本地历史，协作中极易引发混乱。
merge 不改任何已有提交，只新增一个合并提交，所有原始记录完整保留，冲突解决过程也清晰可追溯。
- 团队共用分支（如
main、develop）必须用merge - 你不确定对方是否已基于你的提交继续开发 → 别用
rebase - CI/CD 流水线依赖固定 commit ID →
rebase会导致构建失败
git merge 前必须检查的三件事
跳过任一检查，都可能触发意外交互或覆盖他人工作。
Cnb Cool Git
下载
CNB 云原生构建平台的 Git 操作技能，支持代码克隆、提交、推送、分支管理、Merge Request 管理、流水线触发与结果读取。初次使用需收集用户的 Git 用户名和邮箱。
- 确认当前在目标分支：
git branch看星号（*）所在分支，不是靠 IDE 右下角状态栏——它有时缓存不准 - 确保目标分支已提交所有修改：
git status输出应为 “nothing to commit, working tree clean”；若有未提交变更，先git add+git commit，或用git stash临时保存 - 拉取远程最新状态（尤其多人维护分支）：
git fetch origin后执行git log ..origin/main（把main换成实际分支名），确认本地没落后于远程
遇到冲突时，别直接 git add . && git commit
冲突文件里会留下 <<<<< / ====== / >>>>> 标记，这是 Git 的冲突提示符，不是合法代码。直接提交会导致编译失败或运行时异常。
- 先用
git status查看哪些文件冲突（标为 “both modified”） - 手动编辑每个冲突文件，删掉标记行，只保留最终要保留的逻辑
- 编辑完后，对每个文件执行
git add <file>—— 这步是关键，表示“我已解决这个文件的冲突” - 最后统一
git commit，不要加-m参数，让 Git 自动带入默认合并提交信息
推送到远程前，务必确认上游设置
git push 看似成功但实际没推送出去，是最隐蔽的失误之一。根本原因是本地分支没关联远程追踪分支。
执行 git branch -vv，观察输出中当前分支是否显示类似 [origin/main] 的括号内容。没有就说明没设上游。
- 首次推送必须带
-u：git push -u origin feature/login - 如果远程分支名和本地不一致（比如本地叫
dev，远程要叫staging），必须显式写 refspec：git push origin dev:staging - IDE 的“Push”按钮可能静默失败，建议终端里跑一次
git push并观察输出
merge 行为偏离预期。 
