企业官网建设流程全解析

很多人用Git的第一天就开始执行git pull，但真到要解释清楚“拉取和合并”到底做了什么、为什么有时候会冲突、什么时候该用merge什么时候该用rebase，能讲明白的人其实不多。我见过不少同事，从SVN迁移过来之后，把git pull当成“更新到最新版”的黑盒操作，结果一遇到冲突就懵，一rebase就慌。这篇东西我不打算讲那种“Git从入门到精通”的大而全教程，就聚焦在拉取和合并这两个高频动作上，把原理讲透，把实操步骤写清楚，再把我在真实项目里踩过的坑和排查思路一并整理出来。

无论你是刚接触Git的新手，还是已经被冲突折磨过几轮的中级开发者，这篇内容都应该对你有用。我会尽量用实际工作中会遇到的场景来拆解，而不是堆命令文档。

1. 先搞清楚git pull到底在做什么——fetch与merge的组合拳

1.1 fetch和pull的差别，很多人用了一年都没分清

Git里有几个动作长得特别像：fetch、pull、merge、rebase。新手容易混，老手有时候也会说出“我已经pull了怎么还看不到别人的代码”这种话，其实多半是没理解fetch和pull的本质区别。

简单说，git fetch是“把远程仓库的最新提交下载到本地”，但注意，它只更新本地仓库里记录的远程分支引用（比如origin/main），并不会修改你当前工作目录里的任何文件，也不会改变你当前所在分支的提交历史。换句话说，fetch之后，你的工作区是干干净净的，代码一行没动，只是在本地悄悄把远程的状态同步了过来。

而git pull则是两条命令的合体：先fetch，再merge（或者rebase，取决于你的配置）。也就是说，pull不仅下载远程的提交，还会尝试把远程分支的提交合并到你当前所在的分支上。

我用一个生活化的类比来解释：fetch相当于你从货架上把新品拿下来放到自己手边，但还没拆封；pull则是不但拿下来了，还直接拆开包装、把新品混进你正在用的货品堆里。前者是“我看看有什么新的”，后者是“我要把新的用起来”。

所以在排查问题的时候，只要记住一条判断逻辑：**如果你只是想看远程有没有新提交、别人改了什么，用git fetch加git log就够，千万别用git pull去打扰当前的工作区。**反过来，如果你想把自己的代码更新到和远程一致，再执行git pull。

1.2 git pull的三种合并模式：merge、rebase、ff-only

很多人并不知道git pull背后具体执行的是哪种合并，这直接决定了你拉取之后提交历史长什么样。

默认情况下，git pull等价于git fetch加git merge。这种模式会生成一个“合并提交”（merge commit），用来把两条分叉的历史重新接起来。好处是保留了完整的历史脉络，坏处是历史会变得像毛线团一样，全是分叉和交汇点。

如果你的Git配置里设置了pull.rebase=true，或者你在命令行写了git pull --rebase，那pull就会执行fetch加rebase。这种模式下，你本地未推送的提交会被“临时摘下来”，等远程的新提交落到你当前分支之后，再把你本地的提交重新“放”到最顶端。好处是提交历史是一条直线，非常干净；坏处是如果操作不当，会重写提交时间戳，甚至引发意想不到的冲突。

还有一种模式叫--ff-only，它的意思是：只允许快进合并。什么叫快进？就是远程分支的新提交是在你当前分支的“后面”追加的，没有分叉，那Git直接把分支指针往前移动就行，不产生任何合并提交。但如果远程分支和本地分支已经分叉了，--ff-only会直接拒绝合并，报错提示你“不能快进”。这种模式适合那些要求历史绝对线性的团队，它强制你每次合并前先rebase。

我自己在团队里推荐的做法是：默认使用git pull --rebase，尤其是在自己的功能分支上。理由很简单，线性历史更好看，review代码时更容易追踪。但在master这种大家共享的长期分支上，我反而不太在意用默认的merge，因为那里本来就会有很多合并提交，再增加一两条也无妨。

1.3 用git fetch加git log验证你的理解

我强烈建议你亲手做一次这样的实验，比读任何教程都有用：

# 先看当前状态 git status # 只拉取远程信息，不修改本地代码 git fetch origin # 对比本地分支和远程分支差了几个提交 git log --oneline HEAD..origin/main # 查看远程分支最新提交信息 git log -1 --stat origin/main

如果你执行完上面这几条命令之后，git status显示工作区干净，本地分支也没变化，那就证明你对fetch的理解到位了。接下来执行git pull，再对比一下git log的变化，你就能直观感受到pull多做了哪一步。

这种“先fetch再决定要不要pull”的习惯，其实就是所有Git高手的日常。别小看这多出来的一步，它能在你毫不知情的情况下，帮你避免好多次“拉到一半发现冲突”的尴尬。

2. git merge的完整实操与冲突解决思路

2.1 从拉取到合并的完整命令流

假设你正在开发一个功能，本地新建了一个分支叫feature/login，这时候同事把你依赖的公共模块改动合并到了develop分支。你需要把develop的新代码合并到自己的分支上。最直接的做法是：

# 切回develop先拉取最新 git checkout develop git pull origin develop # 切回自己的功能分支 git checkout feature/login # 把develop合并进来 git merge develop

注意第4步，git merge develop是把develop分支的提交合并到当前分支（feature/login）上。合并完成后，feature/login会包含一次额外的合并提交。如果你想让历史更线性，可以改用git rebase develop，这个我们后面讲。

那么，什么时候用merge最合适？我自己的经验是：**在需要把长期分支（如develop、master）更新到功能分支时，用merge问题不大，因为它生成的合并提交可以被revert，方便回滚。**而在准备提交PR/MR之前，如果想把主干的最新代码吸收进来，我倾向先用rebase把本地提交挪到最新，再push，这样reviewer看你的PR会轻松很多。

2.2 冲突产生的根源与解决步骤

冲突的本质是：两边的修改在同一个位置“撞车”了。Git不是万能的，它能自动合并大部分不会交叠的改动，但只要两个分支修改了同一个文件的同一个区域，它就不知道到底该听谁的，只能交给你来裁决。

实际操作中，遇到冲突时不要慌，按照这个顺序走：

第一步，查看冲突文件列表：

git status

你会看到类似both modified: src/App.js的状态，其中both modified表示两个分支都修改了这个文件。

第二步，打开冲突文件，搜索冲突标记。Git会在冲突位置插入这样的标记：

<<<<<<< HEAD 这里是当前分支的内容 ======= 这里是合并进来的分支的内容 >>>>>>> develop

你需要手动判断保留哪一部分，或者把两边的内容都做整合。整合完之后，一定要删掉<<<<<<<、=======、>>>>>>>这三行标记。

第三步，标记为已解决并提交：

git add src/App.js git commit -m "Merge branch 'develop' into feature/login"

这里有个经验之谈：在解决冲突时，千万不要只凭直觉“选一边”。很多冲突的根源在于双方改了同一处，但语义上其实是要同时保留两边各自的逻辑。你需要看上下文，理解这两段代码各自在做什么，再决定是拼接还是覆盖。

第四步，合并完成后，强烈建议跑一遍测试：

npm test # 或者 pytest # 或者你们项目自己的构建命令

千万不要合并完就push，这是我在生产事故里学到的血的教训。

2.3 git merge的三种合并提交策略：--ff、--no-ff、--squash

除了最基础的git merge branch，还有几个常用变体，理解它们能让你在不同场景下更灵活。

默认情况下，如果当前分支和要合并的分支没有分叉，Git会执行快进合并（fast-forward），直接把指针往前移，不生成合并提交。如果你希望保留一个明确的“合并节点”，哪怕没有分叉也要记录一次合并，就加--no-ff参数：

git merge --no-ff develop

这在某些团队的发布流程里很常见，因为他们想通过合并提交来标记“这个功能是什么时候进入主干”的。

另一个常用变体是--squash，它的作用是把要合并分支上的所有提交压缩成一个新的提交，再合并进来。这样带来的历史非常干净，但也丢掉了功能分支上每个小步骤的提交细节：

git merge --squash feature/login git commit -m "Add login feature"

注意，--squash只把改动放到暂存区，不自动生成提交，所以后面还跟了一步git commit。这个方式特别适合那种功能分支上有一堆“wip”、“fix typo”之类的临时提交的场景。

3. git rebase：换一种思路整合分支

3.1 rebase的原理与使用场景

rebase这个词直译过来是“变基”，意思是重新设置基础。它的做法是：把你当前分支上的提交“摘下来”，记在一边，然后把目标分支的新提交落到底座上，最后再把摘下来的提交逐个重新放上去。

我经常用搭积木来比喻：merge就像是两堆积木各自搭好之后，中间用一根横梁连起来，变成一个整体；rebase则像是把你这边搭歪的部分拆掉，重新放到对方已经搭好的顶部，整体看起来就是一条笔直向上的结构。

具体命令：

git checkout feature/login git rebase develop

执行过程中，如果遇到冲突，解决方式跟merge差不多，但有一点关键区别：**rebase时你不是用一次新的提交来完成整合，而是要逐个处理被“重新放置”的提交。**每解决一个冲突，要继续执行：

git add 冲突文件 git rebase --continue

如果你想放弃这次rebase，回到执行前的状态：

git rebase --abort

3.2 已经push过的分支能不能rebase？怎么安全操作

这个问题的标准答案是：**不要rebase你已经推送到远程共享分支上的提交。**因为rebase会重写提交的哈希值，而远程分支上的其他人可能已经基于这些提交做了进一步的开发。你一旦强制推送重写后的历史，别人的本地仓库就会“分裂”，他们pull时会收到一堆莫名其妙的冲突。

但也有例外情况：如果你推送的是一个自己独享的分支（比如feature/login），并且明确知道没有其他人在用，那你可以在rebase后强制推送：

git push --force-with-lease

这里我用的是--force-with-lease而不是--force。--force-with-lease会在推送前检查远程分支有没有被其他人更新过，如果有，就拒绝推送。这个参数比裸的--force安全得多，强烈建议你统一用它。

我自己踩过一个大坑：有一次在功能分支上rebase了master，然后直接git push --force，结果同事已经在同一分支上推了一个提交，我的强制推送把他的提交整个覆盖掉了。虽然最后通过reflog找回来了，但那个下午的沟通成本极高。从那以后，我在团队里只允许--force-with-lease。

3.3 日常开发中最推荐的工作流：git pull --rebase

既然说了merge和rebase，那日常应该怎么组合？我自己的标准流水线是这样的：

# 在功能分支上开始一天的工作前 git checkout feature/login # 拉取最新develop（这里用rebase而不是merge） git pull --rebase origin develop # 开始写代码、本地提交 git add . git commit -m "feat: implement login form" # 多提交几次之后，整理提交 git rebase -i HEAD~3 # 推送之前再拉一次最新develop git pull --rebase origin develop # 推送到远程 git push

这个方法的核心思路就是：**尽量用rebase来保持历史线性，用交互式rebase来整理本地提交，push之前再同步一次。**长期坚持下来，你的PR会非常干净，reviewer看得也舒服。

4. 拉取合并中的常见问题排查实录

4.1 本地有未提交修改时pull失败怎么办

这是新手最常见的报错场景。你正在改代码，突然想起来要拉一下远程更新，于是执行git pull，结果Git报错：

error: Your local changes to the following files would be overwritten by merge: src/App.js Please commit your changes or stash them before you merge.

这段话的核心意思是：拉取下来的远程改动会覆盖你本地未提交的修改，Git出于安全考虑拒绝执行。

这时候你有两个选择：要么先把本地修改提交了再pull，要么先把修改存起来。临时修改还没写完、不想提交，最常用的方案是git stash：

git stash git pull git stash pop

git stash会把你的未提交修改临时保存到一个栈里，等你pull完成后再用git stash pop恢复。注意，pop有可能因为冲突而失败，如果恢复时出现冲突，解决方式和merge一样。

还有个更隐蔽的场景：你本地有未提交的新增文件，而这些文件在远程分支里恰好也存在。Git会报“untracked working tree files would be overwritten”之类的错误。这时候需要先确认这个文件是不是真的要被远程版本覆盖，如果是，可以把本地文件移走或删除，再pull。

4.2 拉取后代码“丢失”了？先别慌，reflog能救你

有些人在执行git pull --rebase时遇到冲突，心一慌直接执行了git rebase --abort，然后又发现develop分支上的某个提交不见了，顿时冷汗直冒。其实这种情况下，Git并没有真正删除任何东西，它只是把引用移动了。

任何时候你觉得自己的提交“丢了”，第一反应应该是查reflog。reflog记录了HEAD指针的每一次移动，包括reset、rebase、merge等操作：

git reflog

输出会显示一排历史操作记录，每一行都有一个哈希值。找到你要恢复的那个提交，执行：

git reset --hard <commit-hash>

就可以让当前分支回到那个时间点的状态。我曾经有一次rebase到一半觉得历史太乱想回退，结果因为操作失误导致分支指针乱了，最终就是靠reflog一步步找回的。

4.3 怎么拉取修改之前的代码：checkout指定提交或文件

热搜词里有“git怎么拉取修改之前的代码”，这个需求特别常见。你想回到项目历史中某个特定提交的状态，但不影响当前进度，有几种做法。

如果只是临时看某个历史版本的代码，可以：

git checkout <commit-hash>

这会让工作区处于“detached HEAD”状态，即你不再处于任何一个分支上，代码会变成那个提交时刻的状态。看完之后想回到分支：

git checkout feature/login

如果想直接拿到历史上某个文件在特定提交时的内容，可以：

git checkout <commit-hash> -- src/App.js

这个命令会把那个提交里的src/App.js覆盖到当前工作区，适合“我想找回被误删的某段逻辑”这种情况。

如果你想重建一个分支来基于历史版本继续开发：

git checkout -b hotfix-old-version <commit-hash>

4.4 拉取合并常见问题速查表

4.5 关于工具链的补充：IDE里的“Update Project”和命令行git怎么对应

很多人习惯用IDE里的图形界面来操作拉取合并，比如IDEA里的“Update Project”按钮。这里提醒一点：IDE默认的更新行为可能是merge，也可能是rebase，取决于你的VCS设置。

以IDEA为例，在Settings → Version Control → Git里，有一个“Update method”选项，默认是merge。如果你的IDE在拉取代码时总是弹出“Rebasing”提示（热搜词里就有一条“idea拉取git分支提示rebasing”），那很可能是因为项目里配置了pull.rebase=true，或者IDE设置为rebase模式。

这本身不是错误，但如果你不理解它在干嘛，遇到冲突时会很懵。我的建议是：如果是新手时期，先把IDE的更新方式改成merge；等你熟悉了rebase的逻辑，再切换成rebase。工具只是辅助，核心还得明白底层命令在做什么。

5. 团队协作中拉取合并的几个安全习惯

说了这么多原理和命令，最后我想聊几个真正影响团队协作质量的习惯。

第一个习惯是：**push之前一定先git pull --rebase一次。**这样能确保你的提交永远是在远程最新代码的“顶端”，而不是基于一个旧的基线。reviewer看你的PR时，diff会干净很多。如果你不rebase就直接push，而远程恰好有新提交，那么你的PR里会出现合并冲突，需要额外沟通解决。

第二个习惯是：**尽量小步提交，但提交信息要规范。**在功能分支上，我们可以频繁提交小改动，方便自己回退和整理。但在准备PR之前，用git rebase -i把这些小提交整理成几个有意义的提交，是个非常值得养成的习惯。整理提交不只是为了好看，它能让reviewer高效理解你的实现思路。

第三个习惯是：**不要把合并和拉取当作“跟远程同步”这个动作的一部分而不假思索地操作。**每次pull之前，先思考一个问题：“我当前的工作区干净吗？这些改动我想保留吗？”如果答案是否定的，先stash或commit，再pull。很多人把Git冲突归结为运气不好，其实大部分冲突是可以通过良好的操作习惯避免的。

第四个习惯是：**定期用git fetch检查远程的长期分支状态。**把“干活前先看远程状态”变成肌肉记忆，而不是一上来就pull。多花十秒钟看git log --oneline HEAD..origin/main能帮你搞清楚远程比自己快了多少，以及这些提交会不会跟你的工作产生交叠。

拉取合并应该是“主动操作”而非“被动同步”

回头再看拉取和合并这两个动作，你会发现它们其实承载了Git最核心的协作思想：既要让多个人并行开发互不干扰，又要能把大家的成果安全地汇聚到一起。理解了fetch和pull的区别、merge和rebase的适用场景，再配合reflog这种安全网，绝大多数日常问题都能自己解决。

我个人在实际项目里最深的体会是：Git命令本身不难背，难的是每次操作前都想清楚“这一步会怎样改变我的提交历史”。只要你养成了动手前先看状态、动手后检查结果的习惯，拉取合并就再也不是什么让人头疼的事。最后再分享一个小技巧：在终端里给git pull设置一个别名git up，并在全局配置里默认启用rebase，你会很快感受到这套工作流的顺畅感：

git config --global pull.rebase true git config --global alias.up "pull --rebase"

这样每次敲git up，它都在做两件事：拉取远程更新，然后把本地的提交重新放到最干净的位置上。试试看，你会喜欢的。