git pull 是 git fetch 加一次整合：把远端更新取回来后，默认用 merge 合进当前分支，也可以改成 rebase。日常用得最多，也最容易因为「默认行为没配清楚」而多出一堆合并提交。
本文列出 git pull 的常用参数，并给出团队里较稳的配置建议。
关于本系列
本文是《Git 使用教程》按命令拆分的第 25 / 28 篇，全部收录在 Git 栏目。参数表列的是日常高频项，并非穷举；想看某个命令的完整参数，用
git pull -h 看精简列表、git help pull 看完整手册。示例以 Git 2.56.0 为准。一、命令语法
先看语法骨架，再对照下一节的参数表。<占位> 表示必填值，实际输入时不要带尖括号；[...] 表示可选项，-- 用来分隔选项与路径。
bash语法
git pull [<options>] [<repository> [<refspec>...]]二、参数逐项详解
下表按用途列出 git pull 的常用参数，每项都注明了「它到底改变了什么」。
| 参数 | 作用 |
|---|---|
<remote> [<分支>] | 指定拉哪个远端的哪条分支，不写用当前分支的上游 |
--rebase / --no-rebase | 用变基 / 用合并整合，覆盖 pull.rebase 配置 |
--ff-only | 只在能快进时更新，否则直接报错，不产生合并提交 |
--no-ff / --ff | 强制生成 / 允许快进合并提交 |
--autostash / --no-autostash | 本地有未提交改动时自动 stash，整合完再恢复 |
--all | 拉取所有已配置远端（配合 --rebase 需谨慎） |
--tags / --no-tags | 顺带取 / 不取标签 |
--depth=<n> | 在浅仓库里按指定深度拉取 |
--dry-run | 只演练，不真正整合 |
--squash | 把改动压成工作区改动，不生成合并提交 |
--verify-signatures / --no-verify-signatures | 校验 / 不校验合并端的 GPG 签名 |
-q / -v | 静默 / 详细输出 |
三种默认行为怎么配
| 配置 | 效果 | 适合 |
|---|---|---|
pull.ff only | 只允许快进，分叉就报错 | 发布分支、多人共享主干（最稳） |
pull.rebase true | 本地提交自动变基到远端之上 | 功能分支、想保持线性历史 |
pull.rebase false | 生成合并提交 | 希望保留合并痕迹的团队 |
三、常用示例
最安全的日常拉取
bash最安全的日常拉取
git status -sb # 先确认工作区干净
git pull --ff-only
# 若提示分叉：先 fetch 看差异，再决定 merge 或 rebase本地有改动时
bash本地有改动时
git pull --autostash --rebase
# 等价于：stash → fetch → rebase → stash pop一次性的行为覆盖
bash一次性的行为覆盖
git pull --no-rebase origin main # 本次用 merge
git pull --rebase origin main # 本次用 rebase
git pull --dry-run origin main # 先看会拉什么四、注意事项
pull 之前先看工作区
本地有未提交改动时，
pull 可能产生冲突并留下混合状态。要么先 commit/stash，要么用 --autostash。另外 --rebase 会重写本地尚未 push 的提交哈希，已经公开过的分支不要这么做。推荐给所有人的一行配置：
git config --global pull.ff only。它让「本地与远端分叉」变成一个明确的错误提示，而不是悄悄生成一堆合并提交；真需要整合时再显式执行 merge 或 rebase，意图清楚得多。五、小结
把 pull 拆开理解：fetch + 「怎么整合」。参数里真正需要决策的只有 --rebase / --ff-only 和 --autostash。团队统一配好 pull.ff 或 pull.rebase，能省掉大量莫名其妙的合并提交。
本系列共 28 篇，一个命令一篇，完整目录见 Git 栏目。下一篇：git push 命令参数详解。