企业官网建设流程全解析

前阵子做模拟项目X的时候，我们同时开了两个功能分支：我在feature/report这边写导出模块，另一个同事在feature/data那边重构数据接入层。等到功能联调，我必须把他那一整套改动完整地拉到我这边来跑。结果一看远端分支，十来条commit密密麻麻，从“fix typo”到“调整接口字段”都有，要是直接合并回去，主干历史基本就废了。

于是“拉取别的分支代码”和“合并多个commit”这两个操作，就顺理成章地凑到了一起。说实话，这两个操作单独拎出来都不难，但组合在一起用，并且用得干净利落，不丢代码、不乱历史，还是有不少门道的。这篇文章我就结合自己的实操，把原理、命令、参数和常见坑一次讲清楚。刚接触Git的同学可以照着敲，已经用了一段时间但只会固定几个命令的，也建议看看，很多细节值得重新捋一遍。

1. 先搞清楚场景：这两个操作为什么会常常一起出现

1.1 实际工作场景拆解

先说“拉取别的分支代码”。最常见的需求是你做A分支，同事做B分支，现在需要把B分支的功能临时合到你这边一起联调，或者直接把B分支作为基础继续往上叠功能。这时候你就得“碰到”B分支的代码。它跟普通的git pull还不完全一样，因为你当前可能不在B分支上，甚至本地根本没有B分支。

再说“合并多个commit”。假设同事在他那个B分支上提了十几条commit，你拉过来之后要做两件事：第一，代码要正确跑起来；第二，这些commit不能原样堆在你的分支上。尤其以后要发起合并请求、做代码评审，一条干净完整的提交信息，比“fix fix fix”刷屏要专业得多。所以拉完代码之后，紧接着整理提交历史几乎成了标配动作。

这两个需求其实是串在一起的：拉取分支解决的是“代码同步”，合并commit解决的是“历史整洁”。只做前者不管后者，代码能跑，但后续review、回滚、cherry-pick都会很难受。只做后者不拉分支，你手上又没代码。这也是为什么网上讨论这两个问题的时候总是一起出现。

1.2 先理解几个基础概念再动手

动手之前，有几个概念必须想明白，否则很容易操作到一半发现坏了。

第一个是“分支到底是个啥”。你可以把一个分支理解成一个指针，它指向某一条commit链的顶端。之所以叫“拉取别的分支代码”，本质上就是把这个指针指向的那条提交链更新到你本地仓库里，并且让你的工作区切到那条链上。

第二个是“本地分支”和“远端分支”的关系。本地分支你随便建，它能跟踪一个远端分支。比如git checkout -b feature/data origin/feature/data这个命令，做了两件事：在本地创建一个叫feature/data的分支，并且让它跟远端仓库的feature/data建立跟踪关系。有了这层关系，后续git pull、git push都不用再指定远端分支名，很省事。

第三个是“detached HEAD”状态。如果你直接执行git checkout origin/feature/data，不是用-b创建本地分支，而是直接切到一个“远端分支快照”上，Git会提示你进入了一个游离的HEAD状态（detached HEAD）。在这个状态下你改的东西如果不新建分支，很容易丢失，因为没有任何本地分支指向它。新手不推荐这么操作，老手有时候反而可以利用这个状态做临时检查。

第四个是用来理解commit合并的“引用链”。HEAD~3这种写法表示当前HEAD往前数第3个提交，是执行commit压缩操作时最常用的参数。理解了这个，reset和rebase才看得懂。

2. 拉取别的分支代码的完整实操

2.1 最稳妥的三步走：fetch、checkout、pull

我先说我最常用的方式，可以把它当成标准流程。第一步是git fetch origin，第二步根据情况切分支，第三步git pull。

git fetch origin git checkout -b feature/data origin/feature/data git pull

先解释git fetch origin。它做的事情是：去远端仓库，把所有分支的新commit都下载到本地仓库，但不动你当前的工作区、当前分支和你本地的任何东西。你可以把fetch理解成“去远端仓库的货架上看了一眼，把商品信息同步到了本地，但还没有把东西搬到你自己的推车上”。这一步是整个流程的安全垫，先同步信息，后面做什么都有底。

第二步git checkout -b feature/data origin/feature/data，这是在本地新建一个与远端保持跟踪关系的分支。如果你是第一次接触这个远端分支，必须用这种方式。如果本地已经有了这个分支，那就直接git checkout feature/data切过去，然后执行git pull。

第三步git pull会把你刚才在fetch阶段看到的远端新提交真正合并到当前分支。因为有了跟踪关系，命令会直接拉取origin/feature/data的更新，不需要写全称。

为什么我不推荐直接一上来就git pull origin feature/data？因为那个命令本质上是fetch和merge的组合，它会在你的当前分支上直接生成一个合并提交，然后把对方分支的代码全部并过来。如果当前分支上还有你自己的未提交改动，容易撞车。先fetch、再切分支、再拉取，每一步都可以停下来检查，出问题也好定位。

2.2 切换分支时的本地状态保护

切分支前一定要先看一眼工作区状态。你本地如果有改到一半的文件没有提交，执行git checkout时Git可能会拒绝切换，或者把改动带到目标分支上，很容易造成代码混入。

我的习惯是：切换分支前，先执行git status看一眼，有改动就二选一。要么先把改动提交到当前分支，要么暂时存起来：

git stash push -m "wip: 导出模块临时保存"

git stash的作用是把当前工作区的改动打包收起，让工作区回到干净状态。等去了别的分支办完事，再切回来执行git stash pop就能恢复。这里有个小坑：stash pop遇到冲突时会留下一部分stash内容，我一般会在pop之前先git status确认当前分支没有其他关键改动。

如果只是临时切过去看代码、不打算改任何东西，那git checkout之前其实可以不stash，但前提是你当前分支的工作区是干净的。这又回到了那个原则：Git操作前的干净状态，是避免一切妖魔鬼怪的前提。

2.3 只需要别人分支里的某些文件怎么办

还有一种高频场景：你不想把整个分支拉过来，只需要对方分支上某个工具类、某个配置文件，或者某几个页面的代码。这时候没必要切分支，直接做文件级别的检出：

git fetch origin git checkout origin/feature/data -- src/lib/http.ts src/api/user.ts

这个命令的意思是把远端feature/data分支上指定的几个文件，直接复制到当前分支的工作区和暂存区。注意，它只覆盖你指定的文件，其他文件一概不动，也不会产生任何分支切换。

这个操作特别适合那种“我只是想借一个工具函数，不想引入对方一整个功能的依赖”的情况。但使用时要小心：拿过来的文件内容来自另一个分支，如果以后那个分支再整体合并进来，很可能会因为这部分文件出现冲突。所以我个人建议，文件级检出尽量用在临时调试或参考场景，如果是正式功能接入，还是走完整的分支合并流程。

2.4 远端分支状态检查：fetch之后别忘看log

每次git fetch之后，我习惯顺手看一眼远端分支和本地分支的差异，确认这次更新到底带来了什么。

git log --oneline --graph HEAD..origin/feature/data

这个命令会列出远端分支上有、但当前分支没有的提交。HEAD..origin/feature/data这种区间写法，意思是看从HEAD到远端分支之间，远端多出来的提交。在正式合并之前，先看一遍这些提交信息，能避免合并后才发现“对方已经改了我刚改过的那块代码”。

如果版本差异很大，我还会额外执行git diff HEAD...origin/feature/data --stat，看一眼文件级别的改动分布。确认没有关键文件被大改之后再合并，这个过程会稳妥很多。

3. 合并多个commit：两种主流方式完整拆解

3.1 为什么要合并commit，不合并会怎样

先聊一个最容易被低估的问题：为什么一定要合并commit？很多人觉得“提交历史多点乱点无所谓，能跑就行”。但如果你经历过一次紧急回滚，就会明白一个干干净净的历史有多重要。

假设你接到一个故障，需要回滚到两天前某个稳定版本。如果这中间混入了几十条“fix typo”“update code”这种毫无信息量的提交，你根本不知道该回到哪一个节点。更常见的是代码评审，别人看你提交记录，看到的全是“temp”“test”“again”，第一印象就是这个人思路混乱。把语义相关的提交压缩成一条，读了message就知道这段代码要干什么、为什么这么改，这才是提交记录应该有的样子。

所以我在自己的项目里有一个习惯：本地开发阶段怎么commit都无所谓，但在合并到公共分支之前，一定把一段功能的提交压缩成一到两条。这就是“合并多个commit”的核心场景。

3.2 方式一：git reset --soft 软重置合并法

先介绍第一种方式，也是我个人最爱用的：git reset --soft。

它的原理特别容易理解。Git的每个分支本质上就是一个指针，reset就是把这个指针往前或往后移动。--soft表示：只移动HEAD指针，保留所有文件改动，并且把这些改动全部放到暂存区。

比如当前分支的最近4条提交是这样的：

$ git log --oneline -4 d4f2e31 feat: 完善导出逻辑 a1b2c3d fix: 修改字段映射 9f8e7d6 feat: 接入数据接口 c5b4a3e feat: 初始化导出模块

现在想把后面三条提交合并到第一条里，一个命令就能做到：

git reset --soft HEAD~3 git commit -m "feat: 完整导出模块"

执行完reset --soft HEAD~3之后，HEAD指针退到了c5b4a3e这个提交，被退掉的三个提交里所有的文件改动都留在暂存区，一步到位。然后直接执行一次git commit，填一个全新的提交信息，一条压缩后的提交就出来了。

这里要注意reset --soft与另外两个参数的区别，我用一张表直接对比：

一句话总结：--soft是最安全的合并方式，它不碰你工作区的任何一个文件，只是把“已经提交的状态”退回到“待提交的状态”。

3.3 方式二：git rebase -i 交互式变基法

第二种方式功能更细：git rebase -i。它是通过编辑器让你逐条选择如何处理历史提交，适合那种想精细控制每一条commit去向的场景。

用法是这样：

git rebase -i HEAD~4

输入命令后，会弹出编辑器，里面是最近4条提交，每一条前面有关键词。默认都是pick，含义是“保留这条提交”。要把多条合成一条，把后面的几条pick改成squash或fixup即可。

pick c5b4a3e feat: 初始化导出模块 squash 9f8e7d6 feat: 接入数据接口 squash a1b2c3d fix: 修改字段映射 squash d4f2e31 feat: 完善导出逻辑

保存退出之后，Git会接着弹出第二个编辑器，让你填写合并后的最终提交信息。如果你希望合并完只留下最早那条提交的message，别的都不要，可以把后面的关键词改成fixup，那样就不会再弹message编辑窗口。

这个命令我第一次用的时候也容易慌，因为编辑器里看到的都是历史提交，稍不留神就改了不该改的。但熟悉了之后你会喜欢上它的精细度：你可以在合并之前，再检查一遍每条提交的message和大致内容，确认哪些该留、哪些该并。

3.4 squash和fixup到底有什么区别

选squash还是fixup，是很多人纠结的地方。其实区别就一条：

• squash会把被合并提交的message也带进最终的提交信息编辑器里，相当于把所有message汇总一遍让你重新组织，适合几条提交各有价值、想拼成一段完整说明的场景。
• fixup直接丢弃被合并提交的message，只保留第一条的message，适合“这几条提交只是零碎修正，不该留下任何痕迹”的场景。

我一般写功能时，第一个提交带着完整功能说明，后面如果只是调个缩进、改个别名，全部用fixup。如果每一段提交都有自己的语义（比如“接入接口”“修复字段映射”“补充导出逻辑”），我会用squash，在编辑器里把它们整合成一条完整的功能说明。

还有一个很实用的小功能：当你在命令行敲git commit --fixup=某个commit时，Git会自动生成一条以fixup!开头的提交，之后执行git rebase -i --autosquash，Git会帮你自动把这些修正类提交放到对应提交旁边并标记成fixup，省去手动排序的麻烦。日常开发里我经常这么干，只是这一步偏进阶，新手可以先记住结论：提交历史是可以事后整理的，也可以在一开始就为整理做准备。

3.5 只想修改最近一条commit：git commit --amend

如果只是想改最近一条提交，根本不用走上面的流程。git commit --amend --no-edit就能把当前暂存区里的改动并入最近一条提交，同时不修改提交信息。如果不加--no-edit，它会先打开编辑器让你改message再提交。

这个命令大多数人会用来改提交信息，但其实它也是“合并两个commit”的最简形态：你刚提交了一个commit，紧接着发现有个文件忘了加，改完git add之后执行git commit --amend --no-edit，就把修正塞进了前一个提交。这样不会在历史里凭空多出两条“fix”记录。

4. 一个真实联调场景的完整命令流与参数选择

4.1 从拉取到整合：完整操作示例

把前面的内容串起来，我模拟一下当时做模拟项目X的真实操作流程，顺便把参数选择和思路都标出来。

当时的情况是：我本地的feature/report分支上有两个自己的提交，远端feature/data是同事做好的数据接入层，有六条提交。我要做的是：把feature/data的代码拉到本地跑通，然后整合成一条新提交放到feature/report上，保证合并后主干历史干净。

我的操作顺序是这样的：

# 1. 先同步远端信息，保持工作区干净 git status git stash push -m "save local changes" # 2. 拉取远端分支并创建本地跟踪分支 git fetch origin git checkout -b feature/data origin/feature/data # 3. 在feature/data上把六条提交压缩成一条 git log --oneline -6 git reset --soft HEAD~6 git commit -m "feat: 接入数据层重构" # 4. 切回自己原来的分支，合并整理好的分支 git checkout feature/report git merge feature/data --no-ff -m "merge: 集成数据层功能" # 5. 恢复之前暂存的本地改动 git stash pop

这一段流程的关键在于：我在feature/data这个临时分支上执行了reset --soft，压缩的是同事那六条提交，完全没有影响到我自己的feature/report分支。等压缩完成再合并回来，主分支历史里就只会看到一条干净的新提交，而不是那堆零碎的提交记录。

如果反过来，直接在自己当前的feature/report分支上执行reset --soft HEAD~8，那会把同事的六条和我的两条一起全压成一条，我的两条提交也被埋进去了。这样不是不行，但后续如果同事自己也拉了这个分支，会造成很大的历史冲突。所以原则是：先到数据所在的分支上整理，再合并到自己的分支。

4.2 合并后推送远端：force push该怎么做

做完commit合并之后，如果这个分支已经推到了远端，本地历史和远端不一致，直接git push会被拒绝，Git会提示non-fast-forward。

此时需要强推，但强推不一定非要用大家常说的git push --force，我更推荐下面这个命令：

git push --force-with-lease origin feature/data

--force-with-lease比--force多了一层检查：它会确认远端分支在你上次fetch之后没有被别人更新过。如果远端已经被别人推了新提交，它会拒绝执行，防止你覆盖同事的提交。而裸--force不管远端状态，直接硬覆盖，风险大得多。

需要特别声明一点：改写公共分支的历史是需要谨慎的，如果那条分支上已经有很多人基于它开发，强行压缩并强推会让所有人的本地历史跟远端对不上。所以我自己有一个约定：已经推送到公共分支的提交，原则上不再压缩；要压缩就在推送之前完成。这算是我踩过几次坑之后总结出的规矩。

4.3 冲突处理：拉取并合并时撞车了怎么办

合并时最常见的麻烦是冲突。所谓冲突，就是同一条文件、同一块区域，两边都有修改，Git不知道怎么取舍。

遇到冲突先别慌，步骤非常固定：

# 1. 查看冲突文件 git status # 2. 逐个打开冲突文件，搜索 <<<<<<< ======= >>>>>>> # 手工选择保留哪边，或两边都改 # 3. 标记已解决 git add <文件名> # 4. 完成合并 git commit

这里分享一个实战经验：很多人一看到冲突就想用git checkout --ours或git checkout --theirs直接站队，因为快。但如果不是紧急事故，我不推荐盲目站队。很多冲突需要你理解两边改动的意图，手工合并可能更合理。比如对方重命名了一个函数，你新增的代码里调用了旧函数名，就算是“站队到对方”也会因为函数名不对而编译失败。

所以我的顺序是：先git status看冲突范围，如果是小范围的配置冲突，直接打开文件手工改；如果是大范围的重构冲突，先看对方commit的信息和diff，再决定怎么合并。

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

5.1 常见问题速查表

把平时踩过、以及身边同事问得最多的问题整理成一个速查表，建议直接收藏：

5.2 几个实操心得，省得你重复踩坑

第一个心得是：无论多简单的Git操作，动手前先看一眼git status。很多事故都是因为工作区混入了临时改动，然后切换分支、reset、merge连环操作后，代码就变得一团糟。一个干净的工作区是安全操作的基本前提。

第二个心得是：git reflog是救命稻草，一定要会用。有一次我在整理提交的时候本来想用--soft，结果手滑写成了--hard，工作区文件瞬间回到了旧版本。当时心都凉了，后来想起来Git有reflog，执行git reflog看到之前的HEAD记录，再用git reset --hard 那个HEAD恢复，改动一分没丢。从那以后，我再也没有怕过reset --hard，但用的时候还是会格外小心。

第三个心得是：拉别人分支的代码之前，先看一下它的提交历史，判断它和当前分支的提交大概相差多远。如果对方分支已经在你当前分支的基础上改了很多，合并基本不会有太大问题；如果两边是平行开发了很久的分支，冲突几乎是必然的，这时候要提前安排好处理冲突的时间和节奏。

第四个心得是：不要把太多功能塞进一个commit。合并commit的根本目的是让历史更有逻辑，但不代表“越少越好”。我自己比较理想的状态是一个commit对应一个完整的逻辑改动，比如“重构数据接入层”是一条，“导出模块联调”是另一条，两条各自独立、可以单独回滚，这比把所有改动压成一条更利于维护。

5.3 一个容易被忽略的细节：合并commit的边界

最后补充一个很多人没注意到的细节：合并commit的边界，到底按什么划分。

如果你只是单纯想把最近几条提交合并，reset --soft HEAD~n就是最简单粗暴的方式。但如果你想把“某几条中间提交”合并，而不是从头开始数n条，就要用rebase -i手动标记。还有更极端的场景：你想把另一个分支上的某几条提交挑过来并且合并成一条，那就需要先git cherry-pick那几个commit，再对这批commit执行squash。

我遇到过最头疼的一种情况是：功能分支上混入了某个紧急修复的提交，这次合并功能的时候想把这个修复提交一起带过去，但又不想改它的历史。遇到这种情况，直接git cherry-pick 那个提交ID把修复带到目标分支，而不是把这个功能分支整体reset合并掉，这样既带走了修复，又不影响原来的提交历史。

最后再说一下我个人平时最顺手的组合方案：需要拉别的分支代码时，一定先fetch，再checkout到目标分支，想清楚这次操作会不会影响本地分支的提交历史。需要合并多个commit时，优先在来源分支上把提交整理干净，然后再合回自己的工作分支，这样既不打乱自己的本地提交，也不会把一堆零碎记录带进公共历史。

这套组合流程我实测下来是效率和安全性最平衡的，尤其适合多分支并行开发、频繁联调的节奏。如果你也经常在几个feature分支之间来回切，不妨把这篇文章里的命令存下来，下次直接用，能省掉不少来回折腾的时间。