企业官网建设流程全解析

刚学 Git 的时候，我最怕的就是“拉取”和“合并”。那时候分不清 pull 和 fetch 的区别，也不知道 merge 和 rebase 到底有什么不同，总是一顿操作猛如虎，最后发现本地分支被远程一堆新提交碾过去，自己写的东西夹在冲突标记里不知道怎么办。后来在实际项目里被队友带着排查了几次，才算把这套流程彻底理清楚。这篇就聊聊 git 拉取和合并，讲明白它们到底在干什么、什么时候用哪种姿势、遇到冲突怎么不慌。

“git 拉取和合并”是每个用 Git 的开发者几乎每天都会碰到的操作，它决定了你怎么把别人的代码同步到本地，又怎么把你自己的改动安全地并回分支。这篇文章不是为了背命令，而是从工作原理讲到真实操作，再给出一套可以直接上手的冲突解决思路。不管你是刚接触 Git 的初学者，还是已经用了一段时间但一直没系统梳理过的朋友，这篇应该都能帮上忙。

1. 拉取和合并的底层逻辑：先搞懂 Git 是怎么存分支的

1.1 本地分支与远程跟踪分支的关系

要理解拉取和合并，先得知道 Git 里的分支到底是什么。很多新手以为分支是“分出来的一个文件夹”，其实不对。Git 的分支只是一个指针，指向某一次提交。你每次提交，分支指针就会往前进一位。

当你执行git clone或者第一次git remote add之后，Git 会为远程仓库创建一个对应的“远程跟踪分支”，名字一般是origin/main。这个分支不是给你直接操作用的，它只负责记录“上一次你从远程仓库看到的版本是什么”。你本地main分支该怎么前进，完全是你自己提交决定的事；而origin/main怎么前进，只有在你主动和远程服务器通信时才会更新。

看不看得见本地和远程的差距，直接决定你后面拉取和合并的选择。比如你本地提交了几次，而同事也往远程推了新代码，这时候你的main和origin/main就会分叉。用git log --oneline --graph --all能看到类似这样的结构：

* 6a3b2c7 (HEAD -> main) feat: 完成登录模块 | * 281d9e3 (origin/main) fix: 修复空指针异常 |/ * f12ab30 基础框架搭建

这种情况下，你本地比远程多一个提交，远程比你本地多一个提交，分支变成了一条岔路。接下来的拉取和合并，就是要让这两条路重新接在一起。

1.2 git pull 其实就是 fetch + merge

很多教程会直接告诉你“git pull 是拉取代码”，但这个说法太笼统了。Git 官方文档里说得非常清楚：git pull实际上执行的是两个动作，先git fetch，再git merge。

git fetch负责把远程仓库最新提交下载到本地，更新origin/main这个远程跟踪分支。注意，它不会碰你的工作区，也不会碰你本地分支，所以是绝对安全的操作。git merge则负责把你下载下来的新提交合并到你当前所在的分支上。

所以当你执行一条git pull，Git 内部大概走了这么两步：

git fetch origin git merge origin/main

理解了这一点，你就能明白为什么git pull有时候会直接快进更新本地分支，有时候却弹出一个“Merge branch 'origin/main'”的合并提交。那是因为两边分叉了，git merge自动创建了一个合并提交。很多人看到这种提交一脸懵，其实是正常现象。

先弄懂这条链，是掌握拉取合并最关键的一步。你不需要记住所有命令，只要脑子里知道“拉取”不是一个原子操作，它是“先拿回来”和“再合并”的组合，后面很多疑难杂症都能自己想明白。

1.3 合并、变基与快进：三个概念一次理清

既然拉取的核心是合并，那合并里最基础的概念就绕不开：快进合并、普通合并、变基。

快进合并（fast-forward）：当你在本地没有新提交，只是远程前进了，Git 就能把你本地的分支指针直接往前挪，挪到远程最新提交的位置。因为整条提交历史是一条直线，不需要产生新的提交。

普通合并（merge）：当本地和远程都各自有了新提交，Git 会找到两个分支的共同祖先，然后把两边的改动都整合成一个新的“合并提交”。这个提交有两条父提交，用来记录合并来自哪两个分支。

变基（rebase）：它不是直接合并，而是把你本地的提交先“摘下来”，然后以远程分支最新的提交为基础，再把你的提交一个个重新提交上去。最终的效果是你的提交看起来像是排在远程提交后面的一条直线，但提交本身的 hash 会改变。

用生活里的场景类比：两拨人各自改同一份文档。快进就是只有一拨人改了，另一拨人直接拿最新版；普通合并是两拨人都改了，需要一个助手把两边改动汇总到一份文档里；变基则是你把你改的段落复制出来，粘贴到对方最新版本后面，最后整个文档的修订记录看起来只有一条时间线。

这三者的区别很关键，用一张表可以看得更清楚：

2. 拉取代码的几种姿势：pull、fetch 和 pull --rebase 怎么选

2.1 git pull：最直接的同步操作，但它有自己的脾气

git pull是大多数人最常用的命令，操作上确实方便。什么都不加，在本地主干分支上直接就能把远程代码拉下来：

git pull origin main

如果当前分支和远程分支没有分叉，上面这条命令会快进到远程最新版本，你本地工作区立刻变成远程的样子。如果两边有分叉，Git 就会自动进行合并，并生成一个合并提交。

但是这里有几个容易踩坑的点。

第一，如果远程有新提交，而本地也有未提交的改动，且两者恰好改了同一个文件的同一行，git pull会直接报错，告诉你本地修改会被覆盖。这时候你仓库里的文件并不会丢，但合并操作会被中止，你需要先把本地改动处理掉。

第二，git pull默认行为是不带任何防护的，分叉时它可能直接生成一个你没有预期的合并提交。很多人不想要这种“自动合并提交”，于是更愿意用下面的方式。

如果你想让git pull更安全一点，可以加上--ff-only参数：

git pull --ff-only origin main

它的意思是：只有能快进时才拉取，如果本地和远程分叉了，就报错退出，不自动合并。这样就把决策权交还给你，而不是让 Git 稀里糊涂地给你合并。

2.2 git fetch：只下载不合并，适合做精细操作

git fetch是最“老实”的拉取方式。它会把远程的新提交下载到本地，更新origin/main，但你的工作区、本地分支、暂存区统统都不动。

很多人不习惯先 fetch，觉得多一步操作很麻烦。但这其实是官方推荐的做法。你完全可以先把远程的提交拉下来看一圈，再决定怎么处理：

git fetch origin

然后你可以对比本地和远程的差距：

git log --oneline origin/main..main # 查看本地有而远程没有的提交 git log --oneline main..origin/main # 查看远程有而本地没有的提交 git diff main origin/main # 查看两边的内容差异

看完之后，再决定是git merge origin/main、git rebase origin/main，还是干脆按兵不动。这个习惯非常好，尤其适合团队合作中需要谨慎合并的场景。你不想在不明所以的情况下，一股脑把远程代码合进来把本地工作区搞坏。

坦白说，我现在已经很少直接用裸git pull了，基本都会先 fetch，然后心里有数之后再做合并或变基。虽然命令多敲了一条，但安全感提升非常多。

2.3 git pull --rebase：让提交历史保持线性

当你本地分支有一些提交，同时远程也前进了一些提交，这时候git pull默认会帮你 merge，产生一个合并提交。如果你不想让本地分支出现太多“分叉再合并”的历史，可以用 rebase 方式拉取：

git pull --rebase origin main

这条命令会把你本地还没有推送到远程的提交先放到一边，然后把远程最新的提交拉到本地，最后再把你的提交逐个重新提交上去。执行完之后，你的提交历史是一条直线，看起来特别清爽，没有多余的合并提交。

不过这里有一个非常重要的红线：不要对已经推到共享分支上的提交做 rebase。因为 rebase 会改变提交的 hash，如果你的提交已经被别人拉走了，你再 rebase 一次，别人合并时就会出现完全分叉的历史。所以git pull --rebase更适合你本地有私有提交的场景，比如你在功能分支上写了半天还没推上去，想同步一下主分支的新代码，用它是很合适的。

2.4 拉取行为的默认配置建议

针对git pull到底用 merge 还是 rebase，Git 提供了全局配置：

git config --global pull.rebase false # 默认 merge git config --global pull.rebase true # 默认 rebase git config --global pull.rebase merges # 只对新提交变基，保留合并提交

我个人的建议是：日常开发中，如果只是同步远程主干代码，把pull.rebase设置为true会更省心，能避免大量无意义的合并提交。但如果你是在做分支合并管理的负责人，希望忠实保留每次合并的时间点，那还是用merge更符合需求。

另外配合上pull.ff配置也可以提高安全性。例如：

git config --global pull.ff only

这样默认情况下，只要不能快进，git pull就不会自动合并，而是提示你手动决定。对于想减少“意外合并提交”的新手，这个配置很值得试。

3. 合并分支的完整实操：从准备到冲突解决

3.1 合并前的检查清单

真正手动执行git merge的时候，不要上来就敲命令。先看一下自己的仓库状态，养成核对的习惯会少踩很多坑。

第一步，确认工作区干净。执行：

git status

如果显示有未提交的改动，建议先git stash暂存起来，或者干脆提交掉。因为合并时 Git 会尝试把另一个分支的改动应用到当前工作区，如果本地有未提交且与合并改动冲突，会让合并变得非常复杂。

第二步，更新远程跟踪分支。在合并之前，先git fetch origin，确保你要合并进来的远程代码是最新的。如果你直接git merge一个好几天前的origin/main，那合并进来之后可能还会面临一大堆新冲突。

第三步，看历史，判断分叉情况。执行：

git log --oneline --graph --all -10

这一步能让你直观看到本地和远程各自领先多少个提交。如果两边没有分叉，后面就是纯快进；如果分叉了，你就知道冲突大概率会发生。

第四步，可以顺手确认一下你即将合并进来的内容到底改了什么：

git diff --stat HEAD origin/main

这一步很管用，尤其是当你怀疑目标分支上有不成熟代码时。提前看一眼改动范围，心里有底再合并，能避免给别人做“免费测试”。

3.2 执行合并：快进合并和普通合并的区别

做完检查之后，就可以正式合并了。假设你在main分支上，已经 fetch 过远程，接下来执行：

git merge origin/main

如果本地没有新的提交，origin/main的提交就排在本地提交的下游，Git 会显示类似Fast-forward的提示，并直接移动指针，这时候不会有额外提交。

如果本地有自己的提交，而远程也有新提交，Git 就会进入普通合并模式。它会在你本地生成一个合并提交，并可能需要你填写提交信息。不想进入编辑器的话，可以加上--no-edit：

git merge origin/main --no-edit

很多团队在把功能分支合并回主干时，会特意使用--no-ff参数：

git merge feature/xxx --no-ff

--no-ff的意思是“禁止快进合并”，哪怕能快进也强制生成一个合并提交。这样做的目的是在主干分支上保留一个明确的“功能合并节点”，方便将来回溯历史、做回滚。这是团队协作中非常常见的技巧。

3.3 冲突的本质与解决流程（含详细示例）

冲突是合并操作里最让新手头大的事情。但冲突的本质没那么神秘：两个分支在同一个文件的同一块区域都做了不同的修改，Git 不知道到底该听谁的，于是把它标记出来让你做决定。

一个典型的冲突标记长这样：

<<<<<<< HEAD 这里是你当前分支的代码 ======= 这里是远程分支的代码 >>>>>>> origin/main

<<<<<<< HEAD到=======之间是你本地分支的内容，=======到>>>>>>> origin/main是要合并进来的分支内容。你需要做的是打开文件，读一遍两边代码，手动保留正确的内容，然后把冲突标记全部删除。

完整的操作流程如下：

1. 首先执行git status，查看哪些文件冲突了，Git 会列出both modified的文件。
2. 打开冲突文件，逐个处理，把标记和不要的代码删掉。
3. 处理完所有冲突后，执行git add <file>把文件标记为“已解决”。
4. 全部解决后，执行git commit完成这次合并。

举个例子，假设你在登录模块里加了几个参数，远程的同事也在同一个函数里改了逻辑，冲突后是这样的：

<<<<<<< HEAD public User login(String username, String password, String deviceId) { return authService.login(username, password, deviceId); } ======= public User login(String username, String password) { return authService.legacyLogin(username, password); } >>>>>>> origin/main

如果你确认设备标识deviceId是需要的，同时又不希望丢掉远程同事的legacyLogin改动，最终正确的代码可能是结合两者：

public User login(String username, String password, String deviceId) { return authService.login(username, password, deviceId); }

然后把所有<<<<<<<、=======、>>>>>>>标记删除。处理完之后git add，最后git commit。

如果纠结到一半发现实在处理不了，想回到合并前状态，可以用：

git merge --abort

这条命令会立刻停止合并，把工作区恢复到合并之前的状态，非常实用。

3.4 合并后的验证与回滚预案

合并提交生成之后，并不是万事大吉。至少要做两件事。

第一件，看合并提交的形态。执行：

git log --oneline --graph -5

确认合并的结构是否符合预期。如果你用的是普通合并，会看到一个有两个父提交的合并节点；如果是快进合并，历史就是一条直线。

第二件，跑编译、跑测试。合并之后代码能通过语法检查，不代表逻辑上没问题。冲突解决时你手动修改过代码，很容易引入潜在错误。不验证就推代码，是对团队的不负责。

如果合并后你发现结果完全不对，想撤销这次合并，有两个方向：

• 合并还没有生成提交时，直接用git merge --abort。
• 合并已经提交，但还没有推送到远程，可以用git reset --hard HEAD@{1}回到合并前位置，或者去 reflog 里找一个更早的 hash。
• 合并已经推送到远程，那就不能随便改了，这时候更适合用git revert -m 1 <merge-commit>，生成一个反向提交来抵消这次合并的效果。

记住区分“未推送”和“已推送”，这是选择回滚方式的关键。

4. 常见问题与排查技巧实录

4.1 误合并之后如何安全撤销

误合并是每个开发者都会遇到的情况。比如你本来想合并一个分支，结果手滑合错了，或者合并完之后发现代码彻底跑不起来。这时候“撤销”分几种场景。

如果你还没有退出合并过程，直接：

git merge --abort

如果已经生成了合并提交，但没推送，最方便的是git reflog配合git reset。执行：

git reflog

你会看到本地分支的所有历史动作，包括每一条命令执行后的 commit hash。找到合并前那一条记录，比如HEAD@{1}，然后强制切回去：

git reset --hard HEAD@{1}

这里强烈建议先确认reflog里选的位置是对的，因为reset --hard会把当前工作区改成目标提交的状态，任何没有提交的改动都会被丢弃。

如果合并提交已经推送到了公共分支，那么不要用reset，因为那样会改写远程历史，坑到别人。正确做法是反向提交：

git revert -m 1 <merge-commit-hash>

-m 1表示保留合并提交的第一条父提交线，即保留主干上的内容，取消合并进来的分支改动。这个过程会生成一个新的提交，整个过程对团队其他人是安全的。

4.2 如何快速定位所有冲突文件

冲突文件一多，一个个翻会非常低效。有几个命令可以帮你快速定位。

最简单的：

git status --short

冲突文件会显示成UU开头，表示两处修改都未合并。

想只输出冲突文件，可以用：

git diff --name-only --diff-filter=U

这条命令会把所有处于“未合并”状态的文件名列出来，干净利落。拿到列表后，你可以按文件逐个打开处理。

如果你用的是现代 IDE，编辑器里也会直接列出冲突文件，并高亮冲突段落。但我还是建议在命令行先把列表跑出来，因为你可能在终端里才能看到最完整的消息。

处理完一个文件后，记得立刻git add这个文件，Git 就会认为它已经解决了。最后再git status确认没有剩余冲突。

4.3 本地有未提交修改时拉取会不会丢代码

这个问题我在团队里被问过很多次：我本地还没提交，直接git pull会不会把代码冲掉？

答案是不会，但前提是远程的改动和你的本地改动没有重叠。Git 在处理时如果发现要拉下来的内容会覆盖你未提交的同文件修改，它会中止操作，报错提示你“本地修改会被覆盖”。这种情况下你的代码还在，只是拉取失败了。

正确的应急流程是：

git stash git pull git stash pop

git stash会把本地未提交的改动暂时存到一个独立的工作区里，然后清空当前改动。拉取完成后，git stash pop再把改动恢复出来。如果这时候你的改动和刚拉下来的代码冲突了，pop会像 merge 一样产生冲突标记，你手动解决后，还需要手动执行git stash drop把暂存的记录清理掉。

如果你想放弃本地未提交的改动，彻底同步成远程版本，可以直接：

git reset --hard origin/main

但这条命令会把你所有未提交的修改直接丢掉，执行之前一定要想清楚。

4.4 远程分支被清理后本地还残留怎么办

有时候远程分支已经删除了，但本地用git fetch之后仍然能看到那个分支的踪影。这是因为默认情况下git fetch不会自动清理本地对应的远程跟踪分支引用。时间一长，你的本地仓库里会堆满一堆“幽灵分支”。

解决办法是用--prune参数：

git fetch --prune

或者：

git remote prune origin

它会检查远程仓库里已经不存在了的分支，并把本地对应的引用清理掉。如果你用的是 IDE 里的 Git 工具，大部分也都支持“Prune Remote Branches”选项。

养成定期执行git fetch --prune的习惯，能让你本地仓库长期保持干净，也避免你盯着一个已经不存在的远程分支发呆。

4.5 团队合作里拉取合并的统一约定

拉取合并不只是个人习惯的问题，还直接影响团队协作效率。我参与过的几个项目里，拉取合并做得好的团队，都有一个共同点：约定清晰，且每个人都遵守。

我们团队的约定大致是这样的：

• 主干分支保持线性：开发者在本地功能分支上开发，需要同步主干最新代码时，统一用git fetch origin加git rebase origin/main，避免在本地产生合并提交。
• 功能分支合并回主干时用 --no-ff：这样主干上能清晰看到每个功能分支的合并节点，方便回溯和回滚。
• 提交粒度要小：每次提交尽量只做一件事，不要在一个提交里混入格式化、重构、功能代码。粒度越小，冲突越少，回滚越精准。
• 推送前一定要先拉取并验证：先git fetch，确认远程没有新提交，再推送。如果远程有新提交，先 rebase 或 merge 后再推。
• 禁止在共享分支上 reset --hard：已经推送的提交，一律用git revert回滚，不要改写历史。

这些约定看起来简单，但真正做到位，能避免绝大多数拉取合并相关的灾难。

我个人在实际操作中的体会是，拉取和合并从来不是“敲一条命令”那么简单，它考验的是你对 Git 分支模型的理解程度。刚入行时我害怕冲突，总希望有工具能自动帮我解决一切；踩了几次坑之后才发现，冲突反而是理解代码脉络的最好机会。每次处理完冲突，我都会顺手看看对方改了什么、为什么改，这种习惯让我少写了无数 Bug。

最后再分享一个小技巧：如果你不想再被git pull的默认行为坑到，可以把pull.ff设置成only，这样一旦遇到分叉，Git 会强迫你停下来思考，而不是自作主张帮你生成一个合并提交。拉和合，说到底都应该由你自己掌控。