git pull底层原理与安全实践：fetch+merge/rebase深度解析

1. 为什么“git pull”不是魔法，而是一把双刃剑——一个老手的十年血泪总结

刚入行那会儿，我带的第一个实习生，每天早上雷打不动执行三件事：喝咖啡、看邮件、敲git pull。他觉得这行命令就像给手机充电一样自然，插上就完事。直到某天下午三点，他一脸惨白地冲进我办公室，说“本地代码全乱了，merge冲突里有27个文件，全是红色的<<<<<<<”，而他刚改完的登录页样式，被自动合并成了一团无法识别的HTML碎片。那天我们花了四小时回溯、比对、重写，最后发现罪魁祸首就是他习惯性在没git status的情况下，对着一个刚改了三天、还没提交的分支狂按git pull。

这就是git pull最真实的日常——它既是你协作效率的加速器，也是你工作流里最隐蔽的定时炸弹。它不声不响，却能瞬间把你精心维护的本地状态撕成两半；它看似简单，背后却串联着 Git 最核心的三大机制：对象模型、引用管理、三方合并算法。我见过太多人把它当“同步按钮”用，结果在 CI 流水线上栽跟头，在 Code Review 时被质疑“为什么这个 commit 里混进了别人昨天的修复”，甚至在上线前最后一刻发现主干分支被错误地 rebased 导致历史不可逆。这不是操作失误，而是对底层逻辑的误判。

这篇文章，不是教你怎么查手册，而是把我踩过的坑、调过的源码、翻过的 Git 内部文档，全部摊开讲透。我会告诉你：为什么git pull origin main和git pull在绝大多数情况下效果不同；为什么--rebase不是“更高级”，而是在特定协作契约下才成立的约定；为什么git pull --no-commit看似多此一举，实则是大型项目里规避“静默破坏”的关键保险栓。如果你正在带团队、写 CI 脚本、或者只是不想再为 merge 提交日志里那个刺眼的 “Merge branch 'origin/main' into main” 感到羞愧——这篇就是为你写的。它不讲概念，只讲现场；不列选项，只说场景；不画流程图，只还原真实终端里的每一行输出和每一个心理活动。

2. 核心设计与思路拆解：git pull为何必须是 fetch + merge/rebase 的组合拳？

2.1 它根本不是一个原子命令，而是一个“策略封装”

这是理解git pull的第一道门槛。很多人以为git pull是 Git 的一个基础原语，就像git commit或git checkout那样直接操作对象数据库。错。它压根不是 Git 核心命令（plumbing command），而是一个典型的“高层命令”（porcelain command），其本质就是一个 shell 脚本级别的封装。你可以用git pull --verbose看到它内部执行的完整步骤，但更直接的方式是查看 Git 源码中的builtin/pull.c—— 它的核心逻辑就是先调用fetch函数，再根据参数决定调用merge还是rebase函数。

提示：git pull的设计哲学，源于 Git 创始人 Linus Torvalds 对“默认安全”的坚持。他拒绝让一个命令同时完成“下载”和“修改工作区”两件事，除非用户明确授权。所以git pull的存在，不是为了简化，而是为了在“安全”和“便捷”之间划出一条可配置的分界线。它默认选择 merge，是因为 merge 是可逆的、非破坏性的；而 rebase 虽然线性，但会改写历史，一旦推送到共享分支，后果自负。

2.2 为什么不能只用git fetch？—— 引用（ref）与工作区（working tree）的分离真相

git fetch看似安全，但它只做一件事：把远程仓库的最新 commit 对象、tree 对象、blob 对象，原封不动地下载到你的.git/objects/目录里，并更新你本地的“远程跟踪分支”（remote-tracking branch），比如origin/main。注意，它完全不碰你的当前分支指针（HEAD），也绝不修改你磁盘上的任何文件。

举个具体例子。假设你本地main分支停在 commit A，远程origin/main已经推进到 commit C（A→B→C）。你执行git fetch origin后：

• .git/refs/remotes/origin/main文件内容变成了 C 的 SHA-1 值；
• 你的工作目录里，所有文件还是 A 版本的样子；
• 你的main分支指针（.git/refs/heads/main）依然指向 A；
• 但你现在拥有了 B 和 C 的完整对象数据，随时可以检出。

这就引出了关键问题：git fetch后，你看到的git log main..origin/main显示有 2 个新提交，但你的代码根本没变。你得手动执行git merge origin/main或git rebase origin/main才能把这些变化真正应用到你的main分支上。git pull就是把这两步自动化了。但自动化带来的代价，是失去了对“何时应用”、“如何应用”的精确控制权。

2.3--rebase不是“更好”，而是“契约驱动”——团队协作的隐性协议

很多教程把git pull --rebase描绘成“更优雅的选择”。这种说法极具误导性。Rebase 的本质，是将你本地的提交“重放”（replay）到远程分支的最新提交之上。它会生成全新的 commit 对象（SHA-1 全变），并丢弃旧的 commit。这在单人开发或功能分支上毫无问题，但在多人协作的长期存活分支（如main、develop）上，它是一颗地雷。

想象一下：你和同事都在main上工作。你上午git pull --rebase，把你的两个提交 D、E 重放到远程最新的 C 之后，变成 C→D'→E'。你git push上去。但同事的本地main还停留在旧的 C，他下午也git pull --rebase，他的提交 F、G 就会被重放到你推送的 E' 之后，变成 E'→F'→G'。问题来了：他本地的 D'、E' 是你生成的，但他没有这些对象！Git 会尝试从远程拉取，但如果网络中断或权限不足，他的 rebase 就会卡死，报错 “Cannot find commit D'”。

实操心得：git pull --rebase只应在两种场景下使用：（1）你正在一个私有功能分支（feature branch）上开发，且该分支从未被其他人基于它创建过新分支；（2）你的团队有明确的“上游分支只接受 rebase 合并”的书面规范，并配备了强制的 CI 检查（例如，禁止推送包含 merge commit 的 PR）。否则，git pull默认的 merge 策略，才是保护所有人工作流的“最低公分母”。

3. 核心细节解析与实操要点：参数、陷阱与那些手册里不会写的真相

3.1git pull后面不加参数，到底在拉谁？—— upstream 分支的隐式绑定机制

这是新人最容易栽跟头的地方。当你在main分支上只敲git pull，Git 并不是傻乎乎地去origin/main拉。它首先会检查你的main分支是否设置了“上游”（upstream）。这个 upstream 是一个配置项，存储在.git/config文件里，形如：

[branch "main"] remote = origin merge = refs/heads/main

只有当这个配置存在时，git pull才知道该从origin的main分支拉。如果这个配置缺失，git pull会直接报错：“There is no tracking information for the current branch.”。而这个 upstream 配置，通常是在你第一次执行git push -u origin main时由-u（即--set-upstream）参数自动创建的。

注意：git branch -vv命令显示的[origin/main]就是这个 upstream 的简写。但要注意，-vv显示的是“当前已知的远程分支状态”，而不是“当前配置的 upstream”。真正的 upstream 必须通过git config --get branch.main.merge来验证。我曾遇到一个诡异案例：git branch -vv显示[origin/main]，但git pull死活报错，最后发现是.git/config里branch.main.remote被手动删掉了，只剩merge，导致 Git 无法确定从哪个 remote 拉。

3.2git pull origin feature/login的深层含义：它不只是“拉分支”，而是在做 refspec 映射

当你执行git pull origin feature/login，你可能以为只是把远程的feature/login分支拉下来。其实，Git 在后台做了一次完整的 refspec 解析。refspec 是一个形如+<src>:<dst>的字符串，定义了“把远程的哪个引用，更新到本地的哪个引用”。

默认的 refspec 是+refs/heads/*:refs/remotes/origin/*，意思是“把远程所有 heads 下的分支，都映射到本地remotes/origin/下的同名分支”。但当你指定git pull origin feature/login时，Git 会临时构造一个 refspec：+refs/heads/feature/login:refs/remotes/origin/feature/login。它先执行git fetch，把远程feature/login的最新 commit 下载，并更新origin/feature/login这个远程跟踪分支；然后执行git merge origin/feature/login，把origin/feature/login合并到你的当前分支。

这里的关键点在于：git pull origin feature/login并不会改变你本地的feature/login分支指针。它只是把远程的feature/login拉下来，然后合并到你当前所在的分支（比如你正在main上，它就合并到main）。如果你想把远程的feature/login更新到你本地的feature/login分支，你应该先git checkout feature/login，再git pull，或者直接git fetch origin feature/login && git checkout -B feature/login origin/feature/login。

3.3--no-commit：不是“不提交”，而是“延迟提交决策”——一次真实的 CI 故障复盘

去年我们一个支付模块上线前夜，CI 流水线突然在npm test阶段失败。日志显示，一个本该返回200的 API 接口，现在返回了500。排查了半小时，发现是前端一个新提交里，把后端 API 的路径硬编码错了。但奇怪的是，这个错误在开发者的本地环境里完全正常。最后定位到：开发者在合并 PR 前，执行了git pull --no-commit，然后手动git add了所有文件，git commit -m "fix api path"，但忘了git add一个关键的配置文件config.js。结果git status显示“all clean”，git diff也看不出问题，因为那个配置文件的修改被--no-commit的“暂存区”状态掩盖了。直到 CI 环境里执行git checkout，才暴露出这个未暂存的修改。

--no-commit的真实价值，就在这里：它把“合并”和“提交”这两个动作彻底解耦。git pull --no-commit会执行完整的 fetch 和 merge 逻辑，生成合并后的文件状态，但不自动生成 merge commit。此时，你的工作目录是合并后的结果，你的暂存区（index）是空的（除非你手动git add）。你必须手动git add你想提交的文件，再git commit。这给了你最后一次肉眼审查的机会——打开 IDE，对比合并后的文件，确认没有意外的覆盖、没有遗漏的配置、没有冲突标记残留。

实操心得：在以下场景，--no-commit是必选项：（1）你正在main或develop这类高风险分支上工作；（2）你刚刚git stash pop回来，不确定本地修改和远程变更是否有潜在冲突；（3）你的项目有严格的 Code Review 流程，要求每次 merge 都必须有明确的、可追溯的 commit message。记住，--no-commit不是让你偷懒，而是让你在键盘敲下Enter前，多一次深呼吸。

3.4--verbose输出的每一行，都是 Git 在向你“汇报工作”

git pull --verbose的输出，远不止是“给你看进度”。它是 Git 内部状态机的一份实时快照。我们来逐行解读一次典型的输出：

$ git pull --verbose origin main From https://github.com/user/repo * branch main -> FETCH_HEAD = [up to date] main -> origin/main Updating a1b2c3d..f4e5d6c Fast-forward src/api/auth.js | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

• From https://github.com/user/repo：Git 正在连接的远程 URL。如果你看到这里是个内网地址或 IP，说明你的origin配置可能被篡改。
• * branch main -> FETCH_HEAD：FETCH_HEAD是一个特殊的引用，它记录了本次fetch操作中，Git 认为“最相关”的那个远程 commit。对于git pull origin main，它就是origin/main的 HEAD。这个信息至关重要，因为后续的merge或rebase，都是以FETCH_HEAD为基准。
• = [up to date] main -> origin/main：这个等号=表示origin/main这个远程跟踪分支，和它所代表的远程main分支，是完全同步的。如果这里显示+，表示origin/main被更新了（有新提交）；如果显示-，表示origin/main被删除了（远程分支被删）。
• Updating a1b2c3d..f4e5d6c：这是 Git 在告诉你，你的当前分支（main）的 HEAD 正在从a1b2c3d移动到f4e5d6c。中间的..表示“从旧到新”的范围。
• Fast-forward：这是最关键的信号！它表示 Git 判断本次合并是一个“快进”（fast-forward）操作。也就是说，你的本地main分支是远程main分支的一个直接祖先，没有分叉。Git 只需简单地把main的指针向前移动，不需要创建任何 merge commit。这意味着本次pull是绝对安全的，零冲突风险。反之，如果这里显示Auto-merging src/api/auth.js，那就意味着要走三方合并流程，冲突风险立即上升。

4. 实操过程与核心环节实现：从一次失败的pull到一次完美的同步

4.1 场景还原：当git pull报错 “Your local changes to the following files would be overwritten by merge”

这是最经典的“未提交修改”冲突。但它的底层原因，比表面看起来要深刻。Git 的合并算法，依赖于一个干净的“工作树”（working tree）和“暂存区”（index）。当你有未提交的修改时，Git 无法确定：这些修改是“你正在做的新工作”，还是“你已经完成、只是忘了提交的旧工作”？为了安全，它选择放弃。

但直接git stash并不是万能解药。我见过太多人git stash后git pull成功，git stash pop却又报冲突，因为git pull合并进来的新代码，和你stash里的修改，在同一行产生了逻辑冲突。正确的处理流程，应该是一个“三明治”结构：

1. 第一步：git status全局扫描

   git status --short # 输出类似： # M src/components/Button.jsx # ?? src/utils/newHelper.js # A package-lock.json

   这里M是已跟踪的修改，??是未跟踪的新文件，A是已暂存的文件。你需要对这三类文件分别制定策略。

2. 第二步：分类决策

   • 对于??（未跟踪文件）：它们不受git pull影响，可以不管，或者git clean -n预览后清理。
   • 对于A（已暂存文件）：它们已经是暂存区的一部分，git pull会尝试合并它们。如果它们和远程变更无冲突，一切顺利；如果有冲突，Git 会像对待M一样报错。所以，A文件需要和M一起处理。
   • 对于M（已跟踪但未暂存）：这是风险最高的一类。git stash会把它们打包保存，但git stash pop时，Git 会尝试将它们“应用”到新的工作树上，这本身就是一个合并操作。

3. 第三步：执行与验证

   # 1. 先 stash 所有未暂存的修改（M 类） git stash push -m "WIP: before pull" # 2. 确保工作区干净，再 pull git pull origin main # 3. 关键一步：不要直接 pop！先 diff git stash show -p stash@{0} # 仔细看这个 patch，确认它和你刚 pull 下来的代码没有逻辑重叠 # 4. 如果确认安全，再 pop git stash pop # 5. 如果 pop 后有冲突，立刻用 git status 查看，手动解决 # 解决后，git add 冲突文件，git commit（如果需要）

实操心得：永远不要在git stash pop后直接git push。pop后的第一件事，必须是git diff HEAD，确保你恢复的修改，和当前HEAD的差异，完全符合你的预期。我有个脚本，叫git-safe-pop，它会自动执行diff并高亮显示所有修改行，这个习惯救了我至少五次。

4.2 场景还原：git pull --rebase失败后，如何优雅地“回滚”到 rebase 前的状态？

git rebase是一个“破坏性”操作，因为它会改写 commit 历史。一旦git pull --rebase在中途失败（比如某个 commit 应用时产生冲突），Git 会进入一个“rebase 中断”状态。此时，你的分支指针（HEAD）被移动到了 rebase 的起始点，而你的工作目录里，是第一个冲突 commit 的状态。

很多人慌乱中git rebase --abort，以为这样就回到了原点。但--abort只是取消 rebase，它不会恢复你 rebase 前的工作目录状态。如果你在 rebase 前有未提交的修改，这些修改在--abort后可能丢失。

正确的“回滚”流程，是 Git 内置的ORIG_HEAD机制：

# 1. 当 rebase 失败时，Git 会自动将 rebase 开始前的 HEAD 保存到 ORIG_HEAD # 你可以用这个命令查看它指向哪里 git show ORIG_HEAD # 2. 如果你想完全回到 rebase 前的“干净”状态（包括工作目录和暂存区） git reset --hard ORIG_HEAD # 3. 如果你只想重置分支指针，但保留工作目录的修改（比如你还有未提交的代码） git reset --soft ORIG_HEAD # 4. 如果你连 ORIG_HEAD 都不确定了，Git 还有一个更底层的 reflog git reflog show main # 你会看到类似： # a1b2c3d (HEAD -> main) HEAD@{0}: rebase finished: returning to refs/heads/main # f4e5d6c HEAD@{1}: pull --rebase: checkout f4e5d6c # d7c8b9a HEAD@{2}: commit: my last good commit # 找到你想要的 commit，比如 d7c8b9a，然后 git reset --hard d7c8b9a

ORIG_HEAD是 Git 最可靠的“后悔药”。它不像reflog那样有时间限制（默认 90 天），也不像git stash那样需要你主动创建。只要git pull --rebase开始执行，ORIG_HEAD就被设定了。养成git show ORIG_HEAD的习惯，比背一百条命令都管用。

4.3 场景还原：如何用git pull安全地同步一个“只读”的文档仓库？

我们有一个内部知识库，用 Git 管理，所有工程师都可以git clone，但只有少数管理员有 push 权限。大家的需求是：每天早上一键同步最新文档，但绝不能因为一次pull意外修改了本地文件，导致下次git status一堆modified。

标准的git pull在这种场景下是危险的，因为如果本地有未提交的修改（比如你手贱改了一个 README），pull就会失败。而git pull --force又太暴力，会直接丢弃你的修改。

最优解，是利用 Git 的“分离头指针”（detached HEAD）模式，配合--depth 1浅克隆：

# 1. 首次克隆时，就用浅克隆，只拉最新 commit git clone --depth 1 https://git.internal/docs.git # 2. 后续更新，不用 pull，用 fetch + reset cd docs git fetch origin main git reset --hard origin/main

git reset --hard origin/main的威力在于：它会强制将你的当前 HEAD、暂存区、工作目录，全部重置为origin/main的状态。任何本地的修改，都会被无情覆盖。但这正是“只读”场景需要的——你不需要保留任何本地修改，你只需要“最新”。

注意：--depth 1浅克隆，会让.git目录小 90%，同步速度提升 5 倍以上。但它也有代价：你无法git log看历史，无法git blame查作者。所以，它只适用于“内容消费型”仓库，不适用于“代码开发型”仓库。我在公司推广这个方案后，文档同步的平均耗时从 12 秒降到了 1.8 秒，工程师的抱怨少了 70%。

5. 常见问题与排查技巧实录：来自生产环境的 7 个真实故障

5.1 问题：git pull后，git log显示的 commit 时间是未来时间？

现象：git pull完，git log --oneline -5，发现最新的几个 commit 的时间戳，比你电脑系统时间还晚 2 小时。

根因：Git commit 的时间戳，记录的是作者（author）时间和提交者（committer）时间，这两个时间都来自生成该 commit 的机器的系统时钟。如果远程仓库的某台 CI 服务器，其系统时间比你的本地机器快 2 小时，那么它生成的所有 commit，时间戳都会“超前”。

排查：

# 查看一个 commit 的详细时间信息 git show -s --format="%an %ae %ad %cn %ce %cd" HEAD # 输出：John Doe john@example.com Thu Apr 18 15:30:22 2024 +0800 John Doe john@example.com Thu Apr 18 15:30:22 2024 +0800 # 这里 %ad 和 %cd 都是 +0800，说明作者和提交者都在东八区

解决方案：这不是 Git 的 bug，而是时区同步问题。你应该校准你的 CI 服务器的 NTP 时间服务。作为临时 workaround，你可以用git log --date=local让 Git 用你本地时区显示时间，但这只是显示问题，不解决根源。

5.2 问题：git pull origin main成功，但git status仍显示 “Your branch is behind 'origin/main' by X commits”

现象：明明git pull origin main输出了Updating ... Fast-forward，但git status还是提示落后。

根因：git pull origin main只更新了你的当前分支（比如main），但它不会自动更新你的远程跟踪分支origin/main。git status的判断依据，是git rev-list HEAD...origin/main的结果。如果origin/main还停留在旧的 commit，git status就会认为你落后。

排查：

# 检查你的当前分支 HEAD git rev-parse HEAD # 检查你的 origin/main 指向 git rev-parse origin/main # 如果两者不一致，问题就在这里

解决方案：git pull origin main本身就会触发git fetch，理论上origin/main应该被更新。如果没更新，说明fetch阶段失败了，但pull的 merge 阶段成功了（比如你本地main和远程main是 fast-forward 关系，merge 不需要 fetch 的新对象）。此时，手动git fetch origin main即可。

5.3 问题：git pull --rebase后，git push报错 “Updates were rejected because the tip of your current branch is behind its remote counterpart”

现象：git pull --rebase成功，但git push失败，提示需要git pull。

根因：你在git pull --rebase后，没有git push，而是又做了新的本地提交。此时，你的本地main分支，已经包含了 rebase 后的提交，以及你新做的提交。而远程main分支，只包含了 rebase 后的提交（因为你还没 push）。所以你的本地分支，相对于远程，是“ ahead and behind ”——既超前（你的新提交），又落后（远程可能有别人的新提交）。

排查：

# 查看本地和远程的分叉情况 git log --oneline --graph --all # 你会看到类似： # * e5f6g7h (HEAD -> main) My new commit # * a1b2c3d (origin/main) Rebased commit D' # * f4e5d6c Rebased commit C' # * d7c8b9a (origin/main^) Original commit C

解决方案：这不是pull的问题，而是push前的检查疏忽。在git pull --rebase后，git status显示 “Your branch is up to date with 'origin/main'”，这才是git push的安全信号。如果git status显示 “Your branch is ahead of 'origin/main' by 1 commit”，说明你有新提交，可以git push；如果显示 “Your branch is behind”，说明你漏了pull。

5.4 问题：git pull时，终端卡住，光标一直闪烁，没有任何输出

现象：git pull执行后，终端无响应，Ctrl+C 无效，ps aux | grep git显示进程还在。

根因：最常见的原因是 SSH 连接超时，或者 Git 服务器（如 GitHub、GitLab）的响应延迟。Git 在fetch阶段，会尝试建立 SSH 连接（如果 remote URL 是git@github.com:user/repo.git），如果 SSH agent 没有正确加载密钥，或者网络防火墙拦截了 SSH 端口（22），Git 就会无限等待。

排查：

# 测试 SSH 连接 ssh -T git@github.com # 如果卡住，说明 SSH 有问题 # 临时切换到 HTTPS URL，绕过 SSH git remote set-url origin https://github.com/user/repo.git git pull

解决方案：配置 SSH agent 自动启动，并确保~/.ssh/config正确：

Host github.com User git IdentityFile ~/.ssh/id_rsa_github IdentitiesOnly yes

然后eval "$(ssh-agent -s)" && ssh-add ~/.ssh/id_rsa_github。这是每个 Git 用户的必备基础配置。

5.5 问题：git pull --no-commit后，git status显示大量文件为 “deleted by us”，但这些文件在远程是存在的

现象：git pull --no-commit后，git status显示几十个文件是deleted by us，但你确定这些文件在远程仓库里是完好无损的。

根因：你的本地工作目录里，这些文件被物理删除了（比如你手动rm了，或者某个构建脚本清空了dist/目录），但 Git 还不知道。git pull --no-commit的 merge 阶段，会检测到“远程有这些文件，本地没有”，于是标记为deleted by us，意思是“在我们的工作目录里，这些文件被删了”。

排查：

# 查看哪些文件被物理删除了 git status --ignored # 如果有大量 `deleted by us`，但没有 `ignored`，说明是物理删除 # 恢复一个文件试试 git checkout -- src/index.html # 如果成功，说明是物理删除；如果报错，说明是其他问题

解决方案：git checkout -- <file>可以从暂存区恢复单个文件；git checkout -- .可以恢复整个工作目录。但更推荐的做法是：在执行任何pull前，先git status，确保没有deleted by us或modified的意外状态。把git status当作git pull的前置守门员。

5.6 问题：git pull后，package-lock.json文件被自动修改，但git diff显示全是新增行

现象：git pull后，package-lock.json变了，git diff显示它被完全重写了，但你并没有运行npm install。

根因：package-lock.json的格式，会随着npm版本升级而变化。如果你和同事用的npm版本不同（比如你是 v8，同事是 v9），npm install生成的package-lock.json结构就不同。git pull合并时，Git 会把两个不同结构的 JSON 文件进行文本合并，结果就是整个文件被重写。

排查：

# 查看 npm 版本 npm --version # 查看 package-lock.json 的顶层字段 head -n 10 package-lock.json # 如果一个是 "lockfileVersion": "2"，另一个是 "lockfileVersion": "3"，版本不一致

解决方案：团队必须统一npm版本。在项目根目录添加.nvmrc文件，指定 Node.js 和 npm 版本。CI 流水线必须用nvm use加载指定版本。这是前端工程化中最容易被忽视的“一致性”陷阱。

5.7 问题：git pull时，出现 “error: Your local changes to the following files would be overwritten by merge” 错误，但git status显示 “nothing to commit, working tree clean”

现象：git status干净，但git pull报错说有未提交修改。

根因：git status的“干净”，是指工作目录和暂存区一致。但git pull的冲突检查，还会考虑文件权限（mode）的变化。Linux/macOS 下，git会跟踪文件的可执行位（x权限）。如果你用chmod +x script.sh改了权限，git status默认不显示（除非你git status --ignored），但git pull会检测到这个变化，并阻止合并，因为远程的script.sh可能没有x权限。

排查：

# 显示所有被 Git 跟踪的文件的权限 git ls-files -s | grep script.sh # 输出：100755 abcdef... 0 script.sh # 如果远程是 100644，而本地是 100755，权限不一致 # 查看权限差异 git diff --summary # 会显示： mode change 100644 => 100755 script.sh

解决方案：git config core.filemode false，告诉 Git 忽略文件权限变化。这是跨平台（Windows/Linux/macOS）协作的标配配置。执行一次后，所有后续的git pull都不会再被权限问题困扰。

6. 终极实践：构建一个属于你自己的git-safe-pull别名

经过上面所有的分析，你会发现，一个“安全”的git pull，其实是一系列条件判断和防御性操作的组合。我们可以把它固化成一个 Git 别名，让它成为你每天工作的第一道防线。

在你的~/.gitconfig文件中，添加：

[alias] safe-pull = "!f() { \ echo \"=== Starting safe-pull ===\"; \ git status --porcelain | grep -q '.' && { \ echo \"❌ ERROR: Working directory is not clean!\"; \ echo \" Run 'git status' to see changes.\"; \ return 1; \ }; \ git fetch --prune; \ if git merge-base --is-ancestor HEAD origin/main; then \ echo \"✅ Fast-forward possible. Pulling...\"; \ git pull --ff-only origin/main; \ else \ echo \"⚠️ Not fast-forward. Using rebase for linear history.\"; \ git pull --rebase origin/main; \ fi; \ echo \"=== safe-pull completed ===\";