git pull有时不创建合并提交，是因为其底层执行git fetch+git merge，而merge在满足快进条件（本地无新提交、远程有更新、历史线性）时仅移动分支指针，不生成新提交。

git pull 默认会把远程分支的最新提交合并进当前分支，但这个“合并”行为不是固定不变的——它取决于本地分支是否已有新提交、远程是否有新提交，以及你是否显式指定了策略。

为什么 git pull 有时不创建合并提交？

因为 git pull 底层是 git fetch + git merge，而 git merge 在满足快进（fast-forward）条件时，只会移动当前分支指针，不产生新提交。

触发快进合并的典型场景：

• 你本地没做任何 git commit，但远程有新提交（git status 显示 behind 'origin/main' by N commits）
• 远程分支历史是当前分支的直接延伸，没有分叉
• 没设置 merge.ff = false 这类全局配置

这时执行 git pull origin main，日志里看不到合并提交，git log --oneline 看起来就像“直接更新了”。这不是 bug，是 Git 的默认优化。

git pull --no-ff 强制保留合并节点的适用场景

当你要明确标记“此处集成了远程变更”，比如在长期维护的 main 或 release/* 分支上，避免历史被线性重写，就该加 --no-ff。

注意两点：

• 它只对非快进情况生效；如果本地干净、远程有更新，加了也还是快进，不会强制建提交
• 它不会改变 fetch 行为，只是让后续 merge 拒绝快进，强制生成一个合并提交
• 团队若统一启用 merge.ff = false，那所有 git merge（包括 git pull 调用的）都会默认走 --no-ff

想同步远程提交但不触发自动合并？用 git fetch + 手动 git merge 或 git rebase

这是最可控的方式，尤其当你需要预判影响或处理潜在冲突时。

Cnb Cool Git

CNB 云原生构建平台的 Git 操作技能，支持代码克隆、提交、推送、分支管理、Merge Request 管理、流水线触发与结果读取。初次使用需收集用户的 Git 用户名和邮箱。

下载

标准操作链：

• git fetch origin main：只下载对象，不动工作区和当前分支
• git log HEAD..origin/main --oneline：看远程比你多哪些提交
• git merge origin/main：按默认策略合并（可能快进）
• 或 git rebase origin/main：把本地提交“挪到”远程最新提交之后，获得线性历史（注意：会改写本地提交 hash）

关键区别在于：git pull 是“拿来就合”，而 fetch + merge/rebase 是“先看再定”。后者能避开很多因误判远程状态导致的混乱合并。

容易被忽略的陷阱：当前分支没设 upstream 时 git pull 可能拉错分支

如果你在 feature/login 分支上，但没运行过 git branch --set-upstream-to=origin/login feature/login，那么直接敲 git pull 可能失败，或默认去拉 origin/main（取决于 config 中 branch.autoSetupMerge 设置）。

验证方式：

• git branch -vv：看当前分支后面是否显示 [origin/xxx]
• git config --get branch.feature/login.merge：应返回 refs/heads/login
• git config --get branch.feature/login.remote：应返回 origin

没配好就别依赖 git pull 的简写形式，老实用 git pull origin login 显式指定更安全。