企业官网建设流程全解析

1. 为什么我们需要rebase？从一次真实的合并“车祸现场”说起

我猜你点开这篇文章，多半是因为被git merge后那错综复杂、像蜘蛛网一样的提交历史给搞烦了。或者，你正准备向一个活跃的开源项目提交PR，维护者礼貌地回复你：“请先rebase到最新的master分支。” 你一头雾水，去搜教程，看到的要么是晦涩的原理图，要么是一堆吓人的命令，感觉一不小心就会把代码库搞炸。

别担心，我刚开始用git rebase的时候，跟你的感受一模一样。它就像Git里的一个“危险”工具，人人都在用，但没人敢轻易碰。直到有一次，我在一个长期开发的功能分支上，眼睁睁看着因为频繁的git merge，提交历史变成了一个理不清的毛线团，我才下定决心要彻底搞懂它。

简单来说，git rebase的核心就一句话：“重新定义基准点”。想象一下，你从主路（比如master分支）的一条岔路口（比如feature分支）开始修一条新路。修路期间，主路本身也在向前延伸。git merge的做法是，在你修的新路和现在的主路尽头之间，直接架一座桥，把两条路连通。这样历史记录里会明确保留“这里曾经有过岔路”的事实。

而git rebase的做法更“激进”：它把你新修的这条路，整个“平移”到当前主路的最新起点上，假装你从一开始就是在最新的主路上开始修的。这样，最终的历史就是一条完美、笔直的直线，看不到任何分叉的痕迹。

那么，到底该用哪个？这取决于你的团队文化和项目状态。如果你在维护一个公共的、历史清晰的开源项目，或者团队强调提交历史的整洁性，那么git rebase是首选。如果你更看重保留完整的协作上下文，或者分支合并非常复杂，那么git merge更安全。今天，我们就来彻底驯服git rebase这头“猛兽”，让它为你所用。

2. 图解rebase：从“架桥”到“移山”的本质转变

要理解rebase，我们必须先把它和merge放在一起对比看。很多教程一上来就讲命令，但如果不理解背后的“时空观”，你永远会感到困惑。

2.1 经典场景：feature分支的开发与合并

假设我们有一个简单的仓库，初始提交是C0。你基于master分支（此时在C0）创建了一个feature分支，准备开发新功能。

C1---C2---C3 (feature) / C0---C4---C5 (master)

你在feature分支上辛勤工作了几天，提交了C1,C2,C3。与此同时，你的同事在master分支上合并了一些其他更新，产生了C4和C5。现在，你的feature分支的“基准”还是古老的C0，而master已经跑到了C5。

此时，如果你执行git merge：你切换到master分支，然后执行git merge feature。Git 会找到一个最佳的“共同祖先”C0，然后创建一个新的“合并提交”C6。这个C6有两个父节点：C5和C3。历史图会变成这样：

C1---C2---C3 / \ C0---C4---C5---C6 (master)

你得到了一条清晰的合并记录，但也引入了一个分叉点。如果这样的分支很多，历史图就会像地铁线路图一样复杂。

此时，如果你执行git rebase：你切换到feature分支，然后执行git rebase master。这时，Git 会进行一系列神奇的操作：

1. 找到分歧点：Git 找到feature分支和master分支的共同祖先C0。
2. 暂存差异：Git 计算出从C0到C3（feature分支的尖端）这一路上所有提交（C1,C2,C3）引入的代码变更，并把它们暂时保存起来。
3. 重置指针：将feature分支的指针“快进”到master分支的最新提交C5上。注意，此时C1,C2,C3在feature分支上暂时“消失”了。
4. 重新应用提交：Git 把刚才暂存的那些变更，以C5为新的基础，一个一个地重新“提交”上去。因为基础变了，这些重新生成的提交会有全新的提交ID（比如C1',C2',C3'），但变更内容和你原来的一模一样。

最终的历史图会变成这样：

C1'---C2'---C3' (feature) / C0---C4---C5 (master)

看，feature分支的起点从C0“平移”到了C5，历史变成了一条直线。现在，你再切回master执行git merge feature，因为feature的所有提交都在master的“前方”，Git 会执行一次“快进合并”（fast-forward），直接把master指针移到C3'，连合并提交都不会产生：

C0---C4---C5---C1'---C2'---C3' (master, feature)

一条无比清晰、线性的历史就此诞生。这就是rebase的魅力，也是它让历史保持整洁的秘密。

2.2 黄金法则：什么时候绝对不能用rebase？

理解了原理，就必须牢记一条git rebase的黄金法则：永远不要对已经推送到远程仓库的提交进行rebase。

为什么？因为rebase的本质是“重写历史”。它创建了新的提交（C1',C2',C3'）来替代旧的提交（C1,C2,C3）。在你的本地仓库，这没问题，旧提交会被垃圾回收。

但是，如果你的旧提交已经推送到了像 GitHub、GitLab 这样的远程仓库，并且可能已经被其他同事拉取（pull）到了他们的本地仓库。这时你再强行推送（push）重写后的历史，就会导致你的本地历史和远程历史对不上。其他同事再拉取时，会陷入一场混乱的合并冲突，或者看到大量“重复”的提交（旧的和新的都在）。要解决这种问题非常麻烦，需要强制推送（git push -f），而这会覆盖别人的工作，是团队协作中的大忌。

所以，请把这句话刻在脑子里：rebase只适用于你本地、尚未推送的提交。对于已经共享的提交，老老实实用merge。

3. 手把手实操：从零开始玩转rebase

光说不练假把式。我们用一个最简单的例子，从头到尾操作一遍，让你亲眼看到每一步发生了什么。请打开你的终端，跟着我一起做。

3.1 准备实验环境

首先，我们创建一个干净的实验目录并初始化Git仓库：

mkdir rebase-demo && cd rebase-demo git init

创建一个初始文件并提交，作为我们的master分支起点：

echo "Initial content" > file.txt git add file.txt git commit -m "C0: Initial commit"

现在，我们模拟在master上有了新的提交（比如同事的更新）：

echo "Update from master branch" >> file.txt git add file.txt git commit -m "C1: Update on master"

此时，我们的master分支有两个提交：C0和C1。历史是线性的。

3.2 创建并开发feature分支

假设现在你要开发一个新功能。基于C0创建并切换到一个新分支feature：

# 我们先回到C0，以此为基础创建feature分支 git checkout -b feature HEAD~1 # HEAD~1 表示当前提交（C1）的上一个提交，即C0

注意：这里我们特意基于C0（HEAD~1）创建分支，而不是基于最新的C1，就是为了模拟真实开发中，你从某个较早的节点开始工作，而主分支已经前进的场景。

在feature分支上，我们做两次提交：

echo "Feature work A" >> file.txt git add file.txt git commit -m "F1: Feature work A" echo "Feature work B" >> file.txt git add file.txt git commit -m "F2: Feature work B"

现在，我们来看一下提交图。使用git log --oneline --graph --all：

* f123456 (HEAD -> feature) F2: Feature work B * abcdef0 F1: Feature work A | * 7890abc (master) C1: Update on master |/ * 3456789 C0: Initial commit

看得很清楚：master在C1，feature分支从C0分叉出去，有了F1和F2两个提交。这就是我们rebase前的状态。

3.3 执行rebase操作

我们的目标是让feature分支基于最新的master（即C1）。切换到feature分支（如果还没在的话），然后执行rebase：

git checkout feature git rebase master

你会看到类似这样的输出：

First, rewinding head to replay your work on top of it... Applying: F1: Feature work A Applying: F2: Feature work B

这个过程就是前面原理部分讲的：Git 先把feature分支的指针暂时回退到和master的共同祖先（C0），然后把F1、F2的变更暂存，再将feature分支快进到master（C1），最后把暂存的变更依次应用上去，生成新的提交F1'和F2'。

现在再看提交图：

* a1b2c3d (HEAD -> feature) F2: Feature work B * d4e5f6a F1: Feature work A * 7890abc (master) C1: Update on master * 3456789 C0: Initial commit

太棒了！历史变成了一条完美的直线。feature分支的起点现在紧挨着master的最新提交C1。注意，提交ID（a1b2c3d,d4e5f6a）已经和之前的（f123456,abcdef0）完全不同了，它们是全新的提交。

3.4 完成合并：快进（Fast-Forward）

现在，feature分支的代码已经包含了master的最新内容，并且我们的工作是基于最新代码进行的。我们可以将feature分支合并回master。

切换到master分支，然后合并：

git checkout master git merge feature

因为feature的所有提交都在master的“前面”，Git 会执行一次快进合并，输出Fast-forward。master分支的指针直接移动到了feature分支所在的位置。

最终的历史图（使用git log --oneline --graph）：

* a1b2c3d (HEAD -> master, feature) F2: Feature work B * d4e5f6a F1: Feature work A * 7890abc C1: Update on master * 3456789 C0: Initial commit

一条清晰、线性、易于阅读的历史记录诞生了。这就是一次完整的、标准的rebase工作流。

4. 进阶技巧与实战避坑指南

掌握了基础操作，我们来看看rebase更强大的用法，以及那些教程里不会告诉你的“坑”。

4.1 交互式rebase：整理你的提交记录

git rebase -i（交互式rebase）是代码整理的瑞士军刀。它可以让你在“重新应用提交”的过程中，对提交进行排序、合并、拆分、修改提交信息等操作。这在准备一个干净的PR时尤其有用。

假设我们在feature分支上有三个提交：

1. F1: Add user login function
2. F2: Fix typo in login page
3. F3: Add user logout function

其中F2只是修复了F1里的一个拼写错误，完全没必要作为一个独立提交。我们可以用交互式rebase将它们合并。

# 假设当前在feature分支，我们要整理最新的3个提交 git rebase -i HEAD~3

这会打开一个编辑器（如Vim或VSCode），显示如下内容：

pick a1b2c3d F1: Add user login function pick d4e5f6a F2: Fix typo in login page pick e7f8g9h F3: Add user logout function

每一行代表一个提交，前面的pick表示“应用这个提交”。我们可以修改这些命令：

• 将第二行的pick改为squash（或简写s），表示将这个提交合并到前一个提交中。
• 也可以改为fixup（或f），效果类似squash，但会直接丢弃这个提交的日志信息。

修改后：

pick a1b2c3d F1: Add user login function squash d4e5f6a F2: Fix typo in login page pick e7f8g9h F3: Add user logout function

保存并退出编辑器。Git 会应用这些更改，并可能再次打开编辑器让你为合并后的新提交编辑提交信息。完成后，原来的三个提交就变成了两个：一个包含了登录功能和拼写修复的提交，和一个独立的登出功能提交。历史瞬间变得干净利落。

实操心得：交互式rebase是本地提交的“后悔药”。在推送到远程之前，大胆地用它对提交历史进行美容。常用的命令还有reword（修改提交信息）、edit（暂停rebase，允许你修改提交内容）、drop（删除提交）。多练习几次，你就会爱上这种掌控历史的感觉。

4.2 处理rebase过程中的冲突

rebase并不是魔法。当你的修改和新的基础（master）上的修改发生在同一文件的同一区域时，冲突就会发生。这与merge时遇到冲突本质相同，但处理方式略有区别。

假设在执行git rebase master时，在应用某个提交（比如Applying: F1: Feature work A）时发生了冲突，Git会停下来，并告诉你：

Auto-merging file.txt CONFLICT (content): Merge conflict in file.txt error: could not apply abcdef0... F1: Feature work A Resolve all conflicts manually, mark them as resolved with "git add/rm <conflicted_files>", then run "git rebase --continue". You can instead skip this patch with "git rebase --skip". To abort and go back to the original state, run "git rebase --abort".

处理流程如下：

1. 不要慌。Git已经暂停了rebase过程，等待你解决冲突。
2. 解决冲突：打开冲突文件（这里是file.txt），你会看到标准的冲突标记（<<<<<<<,=======,>>>>>>>）。根据需求手动编辑文件，保留你想要的代码，删除冲突标记。
3. 标记冲突已解决：解决完所有冲突文件后，用git add <file>将文件标记为已解决。或者用git add .添加所有更改。
4. 继续rebase：运行git rebase --continue。Git 会创建这个冲突提交的新版本（基于你解决后的内容），然后继续应用后面的提交。
5. （可选）跳过或中止：
   • 如果这个冲突的提交你完全不想要了，可以用git rebase --skip跳过这个补丁。
   • 如果冲突太多，想放弃整个rebase操作，回到最初的状态，用git rebase --abort。这是你的安全绳。

避坑指南：与merge一次性解决所有冲突不同，rebase是逐个提交应用变更。这意味着你可能会在多个提交上遇到冲突，需要重复“解决->add->continue”的过程。虽然繁琐，但这也有个好处：你可以确保每一个提交在应用到新基础后都是独立且正确的，保持了每个提交的原子性。解决冲突时，务必仔细阅读冲突内容，判断是保留你的更改、采用他人的更改，还是进行融合。

4.3 使用--onto进行更灵活的重基

这是rebase的一个高级但极其有用的功能。假设你的分支结构更复杂：

A---B---C (topic) / D---E---F---G (master) \ H---I (next)

你基于next分支创建了topic分支（A基于E）。但现在你想让topic分支基于master分支，而不是next。直接git rebase master会把E、F、G的变更也包含进来，这不是你想要的。

这时就需要--onto：

git rebase --onto master next topic

这个命令的意思是：“把topic分支上，但不在next分支上的提交（即A, B, C），重新应用到master分支上。” 结果会变成：

A'---B'---C' (topic) / D---E---F---G (master) \ H---I (next)

topic分支干净地“移植”到了master上。这个命令在需要调整分支基准，或者从一个旧的长周期特性分支中“拯救”出部分提交时非常有用。

5. Rebase vs Merge：如何根据场景做出正确选择？

到了这里，你已经是一个rebase高手了。但高手不仅要会用它，还要知道什么时候不用它。我们来做一个最终的对比和总结。

选择git merge当：

• 你需要保留完整的历史上下文：特别是当分支的生命周期很长，或者多人协作非常频繁时，那个合并提交本身就是一个重要的历史标记，记录了“何时、为何进行了这次集成”。
• 分支合并非常复杂：如果两个分支的修改已经严重分叉，进行rebase可能需要解决大量冲突，且可能破坏原有提交的原子性。一次合并提交更能清晰地记录这次复杂的集成。
• 你对历史线性化没有强迫症：有些团队或项目并不介意历史图看起来像一棵树，他们更看重记录的完整性。

选择git rebase当：

• 你在准备提交PR/MR之前：这是rebase最经典的场景。在将本地特性分支推送到远程并创建拉取请求前，先rebase到主分支的最新状态。这能确保你的变更是在最新代码基础上测试的，也让维护者更容易评审和合并（因为历史是线性的）。
• 你追求清晰、线性的项目历史：像Linux内核这样的项目，就要求提交历史必须是一条直线。这便于使用git bisect等工具进行问题定位。
• 你在整理本地提交：使用交互式rebase来合并琐碎的提交、修改错误的提交信息，让每一个提交都是一个独立、完整、有意义的变更集。

我个人的工作流习惯：对于我个人的项目或我主导的团队，我倾向于采用一种混合策略，可以称之为“rebase-merge”工作流：

1. 本地开发：在本地特性分支上，自由地进行小步、频繁的提交，甚至有些“WIP”（工作进行中）的提交也没关系。
2. 本地整理：在功能完成、准备推送前，使用git rebase -i对本地提交进行整理、压缩，形成几个逻辑清晰的提交。
3. 更新基准：执行git rebase master（或main,develop），将我的分支变基到主分支的最新状态，并在本地解决可能出现的冲突。
4. 测试：在变基后的分支上运行测试，确保一切正常。
5. 推送与合并：将整理好的、基于最新代码的分支推送到远程，创建Pull Request。在PR被审核通过后，在GitHub/GitLab界面上选择“Squash and merge”或“Create a merge commit”。
   • 如果我的分支提交历史已经非常整洁，我会让维护者使用“Rebase and merge”（如果平台支持），这样主分支历史依然是线性的。
   • 如果我的分支提交较多，或者想强调这是一个完整的功能单元，我会选择“Create a merge commit”，生成一个合并提交。虽然这会产生一个分叉点，但这个合并提交的信息（如PR编号、简述）本身也很有价值。

这个工作流的核心思想是：在本地和个人的分支上，使用rebase来保持历史的整洁和可控；在集成到共享的主干时，根据情况灵活选择合并策略，兼顾清晰度和上下文记录。它既享受了rebase带来的清晰，又通过最终的合并提交（可选）为重要的集成点留下了标记。

最后记住，无论选择哪种方式，团队内部达成一致最重要。和你的队友定好规矩，然后一起遵守，这比单纯追求某种“最佳实践”更重要。工具是为人服务的，而不是反过来。希望这篇超详细的图解和实战指南，能让你彻底告别对git rebase的恐惧，自信地用它来打造更优雅的代码历史。