企业官网建设流程全解析

前阵子带实习生集训，有个新同学在小组仓库里干了一件让我印象深刻的事：他把自己分支上的一堆提交整理得漂漂亮亮，准备合并时发现和主干差了整整一个迭代，于是他——把主干指针往回拨，想让“两边重新对齐”。复盘时我发现，他不是不懂 git，他每条命令都背得出来，但他完全不知道这些命令在真实协作里会如何连锁反应。那天之后，我下决心把 git 培训彻底改成“闯关”模式。

所谓闯关，不是让大家做两节课后练习题就盖章通过，而是把真实协作里最高频、最容易出事故的场景，压缩成一条条可复现的关卡。一个人迟早要栽的跟头，最好让他带着训练护具在训练场上栽完。这篇文章就当一次完整复盘，把我在几次专业实习 git 闯关里沉淀下来的关卡设计、常翻车的操作路径，以及一条从入门到熟练的学习路线全部摆出来。准备带新同学、给团队做工具训练，或者单纯想把自己 git 基础打扎实的人，都可以直接拿走这套方案试试。

1. 为什么我坚持把 git 培训做成闯关，而不是讲完课发一份速查表

传统培训我试过两种，效果都不理想。

第一种是会议室上课模式：投影仪上放分支模型，红色蓝色线条在图上交叉，底下坐着的新同学前二十分钟还在记笔记，到了四十分钟开始有人悄悄刷手机。考试的时候都能答对，一进真实仓库就露馅。第二种是“给你们一个仓库，随便练”模式：自由度过高，反而让人不知道从哪下手，有人绕着git status转圈，有人把.git目录都翻了一遍，一周下来除了 clone 和 commit，什么协作场景都没碰过。

问题不在学习态度，而在学习设计。git 不是一门靠背诵就能掌握的知识，它是一套操作直觉。所谓“会用 git”，本质上是面对“当前处于什么状态、下一步该做什么、做错了怎么回来”这三个问题时，能形成快速判断。闯关模式正好能把这种判断训练拆成可重复的练习。

1.1 闯关能把“模糊的恐惧”变成“具体的错误”

新人怕 git，主要是怕未知。他们不知道一个命令敲下去会发生什么，更不知道还有没有后悔药。讲课时你告诉他们“rebase 很危险”，他们记住了“危险”这个词，但并不知道危险长什么样。闯关刚好相反，每个关卡都制造一个具体事故，让新同学亲手触发一次，再亲手收拾干净。

比如我在关卡里故意安排两个分支同时修改同一个文件，逼他们正面遭遇冲突标记。第一次遇到冲突的人，手是抖的，满屏的<<<<<<<和=======看上去像代码坏了。但当他在关卡里自己解决完三次冲突之后，再看到这些符号，第一反应不再是“完了”，而是“哦，这里有两份意图需要我协调”。这种心理转变，靠讲课给不出来。

1.2 闯关自带反馈闭环，错误当场就能被看见

真实项目里，新人改了分支、推了代码，往往要等 Code Review 时才发现问题，周期长、反馈弱。闯关训练里我设计了一个硬性要求：每个关卡都必须跑完一条完整的“操作链”，最后拿结果说话。

举个最简单的例子：关卡要求从主干拉一条分支，完成一个模拟功能，合并回主干。如果有人直接在主干上提交，合并时会发现分支图异常；如果有人 push 时用-f强行覆盖远端，小组其他人的练习仓库会立刻出现拉取冲突。当场就能看到连锁后果，不需要等导师点评。这种即时反馈比任何评分表都有效。

1.3 闯关允许“安全地犯错”，这是实习期最宝贵的特权

工作中没人希望新人把共享分支搞乱，但训练场可以。我在设计关卡时反复强调一个原则：错误必须被允许，甚至要被鼓励。训练仓库本来就是用来破坏的，越乱越有价值。有人在练 reset 时把整个分支历史推翻重来，有人在 rebase 中段迷失方向，这些事故发生在训练期，损失几乎为零，但教训会被记很久。

我带过几轮之后的体会是：一个实习生如果在训练关卡里把“丢失提交又找回来”的流程完整走过一遍，他在真项目里基本不会再犯同类错误。因为身体记住了那种失而复得的紧张感，这种记忆比任何 PPT 都深刻。

2. 三个必练的核心关卡：从建分支到救回丢失的一小时

关卡设计我不会贪多，与其把 git 所有功能都塞进去，不如对准真实工作流里最高频、最容易出事故的三个场景来设计。它们分别是：常规协作循环、冲突解决、以及提交找回与安全回滚。这三个关卡的顺序不能乱，前一个是后一个的基础。

2.1 关卡一：独立分支循环与一次干净的合流

这个关卡模拟的是实习期最日常的节奏：每天开工先同步主干，拉一条自己的分支，做完提交，合回去，推远端。

我在训练仓库里通常安排三个角色：主干、个人分支、远端模拟仓库。要求每位同学完成十次以上“同步练习”。注意，不是跑十遍相同的命令，而是每次面对不同的远端变化。有时主干多了提交，有时自己的分支落后，有时推送时发现远端已经前进了。每一种情况都要用不同的策略处理。

这个关卡里最重要的一句话是：拉取之前先看差异，推送之前再看一眼状态。很多新同学的习惯是git pull一把梭，合出个乱七八糟的 merge commit 才意识到问题。我在关卡里强制他们先运行git fetch，再用git log origin/xxx..HEAD之类的方式看清两边到底差了什么，最后才决定用 merge 还是 rebase 来对齐。

# 推荐的新一天开工顺序 git fetch origin git status git log --oneline --graph --all -10 git checkout -b feature/xxx origin/master # 做完改动之后 git add . git commit -m "完成模拟功能" git fetch origin git log --oneline pending_commit..origin/master # 看远端新增了什么 git pull --rebase origin master # 本地提交整齐地排到远端之后 git push --set-upstream origin feature/xxx

这关常见的翻车点有两个。第一，有人会在git pull时生成大量 merge commit，把分支历史弄成毛线团；第二，有人会把主干直接并进自己的功能分支，然后带着一堆无关改动去开评审。我一般会加一条关卡附加题：要求最终合流时保持一条尽量平直的提交线，逼他们学会--rebase的用法。

2.2 关卡二：被故意制造出来的冲突

冲突是绕不过去的，与其怕它，不如主动让它在训练里高频出现。我在关卡里会制造两次冲突，一次是“两人改同一文件的不同位置”，一次是“两人改同一文件的同一行”。前者告诉你冲突不一定是你死我活，后者告诉你冲突真正考验的是沟通。

第一次冲突通常是很容易解决的：两边改的地方离得远，git 甚至能自动合并。但关卡要求所有人必须手动检查一遍合并结果，不能直接信任自动合并。这一步主要是培养习惯：冲突标记消失不等于合并正确，功能是否完整要靠编译和测试来验证。

第二次冲突是重头戏。两个小组故意被分配到同一个配置文件的同一行，比如都去修改缓存大小参数。合流时冲突出现了，我会要求他们按下面的顺序处理：

• 先读完整冲突区，理解两个人各自想表达什么；
• 不要立刻删掉别人的代码，先确认需求是否冲突；
• 双方口头商量出一个最终写法，再动手修改冲突标记；
• 解决后必须运行一次构建命令或者测试用例；
• 最后再git add并提交。

我在关卡里发现一个很有意思的现象：大多数新人第一反应是问“谁的版本是对的”，很少有人会问“这两个人的需求分别是什么”。实际上冲突往往不是代码层面的问题，而是信息不对称的问题。所以这关我还会布置一个软任务：解决完冲突之后，两个人互相给对方讲一遍自己原来的改动意图。听完之后，大部分冲突都能找到一个比两边原方案都好的解法。

# 冲突现场的标准动作 git status # 找到冲突文件 vim src/config.py # 手工解决冲突标记 # 解决后逐步验证 python -m pytest # 或任何项目构建命令 git add src/config.py git commit -m "合并：统一缓存参数配置"

2.3 关卡三：丢失提交的考古与安全回滚

这一关是训练里最刺激的部分，我会提前在训练仓库里制造一个“事故现场”：某个分支的最新提交被整体回退，看起来像是代码人间蒸发了。关卡要求每个人靠git reflog把丢失的提交找回来，再通过安全方式让它重新进入主流程。

为什么这个关卡必须练？因为实习期最容易犯的灾难级错误是git reset --hard用错了地方。有人为了“清理分支”在共享分支上执行硬回退，还有人为了让远端“和新代码对齐”直接 push 覆盖。这些操作本身没有错，错在场合：reset 改写的是本地历史，push -f 改写的是远端历史，后者对团队的影响是连锁性的。

正确的找回操作并不难，但需要形成条件反射：

# 找回被 reset --hard 丢掉的一小时 git reflog # 输出里找到你想要的 commit，比如 7c9d3a2 git checkout -b recovery/7c9d3a2 7c9d3a2 # 确认文件内容正确后，正常发起合并 git checkout master git merge recovery/7c9d3a2

在闯关里，我会继续追加一个变种：那个“丢失的提交”其实不是被 reset 丢的，而是被git revert反向撤销了。两种状态下reflog的表现不同，处理策略也不同。reset是移动指针，revert是新增一个反向提交，所以 revert 更适合用在已经推送的共享分支上——它不会改写别人的历史，只会追加一个新提交来表达“我要撤销”。

这个关卡练完，新人会真正理解一个道理：git 里绝大多数“删掉的东西”其实都还在本地对象库里，reflog就是那扇逃生门。知道有这扇门，操作时就有底气，不会慌。

3. 实习期最容易翻车的三个场景，以及我的完整排查链路

前面三个关卡解决的是基本功，这一节我想换个角度，聊聊真实项目里新同学最容易翻车的三个具体场景。每个场景我都会按“现象 — 错误直觉 — 正确链路”的顺序拆开，把当时排查和解决的完整路径写出来。

3.1 场景一：改了一下午代码，push 却被远端拒绝

现象非常经典：本地分支落后于远端主干，执行git push时报错“更新被拒绝，因为远程版本包含您本地没有的提交”。这时候大部分新同学的第一反应是——难道我要先把别人的提交删了？

我见过最危险的操作就是在这个节骨眼上出现：直接git push -f，把自己的版本覆盖上去。这相当于把团队其他人刚推上去的成果一把抹掉。如果真发生在共享分支上，整个小组的下一次 pull 都会陷入混乱，严重的要靠 reflog 才能找回。

正确的排查链路应该是：

1. 先git fetch，让本地知道远端到底多了什么，这一步不会产生任何副作用；
2. git log --oneline HEAD..origin/master，看清远端比自己多了几个提交；
3. git status确认自己的工作区是否干净，是否有未提交的本地改动；
4. 根据距离远近选择 merge 或 rebase 进行整合；
5. 如果合并或变基时出现冲突，按第二章节讲的方式处理；
6. 重新构建验证后，再一次git push。

这个链路本身不复杂，难的是克服第一反应。我会在训练里反复灌输一个观念：远端报错时，git 是来帮忙的，不是来找茬的。它拒绝推送，是在保护你，提醒你信息不同步。看懂报错，顺着它走，很少会有真正无法收拾的局面。

# 被拒绝后的完整自救 git fetch origin git log --oneline HEAD..origin/master git status # 选择方式一：保留合流记录 git merge origin/master # 选择方式二：让本地提交排列到远端之后 git pull --rebase origin master # 重新构建并验证 git push

3.2 场景二：rebase 到一半骑虎难下

rebase 进行到一半，冲突特别多，提示符变成了(master|REBASE 3/7)，此时新同学的心理状态是崩溃的：退出怕丢代码，继续怕弄糟，网上搜到的攻略又都是旧时代的说法，更慌。

很多人在这个状态下会想尽办法“逃离现场”，有人去别的目录重新 clone 一份仓库，有人干脆删掉本地分支重新拉，结果做了半天的本地提交全留在孤儿对象里。这里要记住一个最关键的底牌：rebase在冲突时并不会立刻销毁任何东西，你随时可以安全退出。

三种退出命令要分清楚：

• git rebase --abort：直接返回到变基开始前的状态，你原来的提交和分支结构全部保留，最适合“不 rebase 了”的决定；
• git rebase --quit：停止 rebase，但保留已经解决过的文件和当前状态，适用于你已经不打算继续、又想留下现场查看的情况；
• git merge --abort：只对 merge 过程中有效，如果当前是 rebase 状态，这条命令不会找回你想要的原始状态。

我的建议是：只要在 rebase 冲突里没有提交半成品，就直接--abort退回来，换个思路再看。很多新人不敢 abort，是怕之前 rebase 的动机白费了。但实际上，先退回来，把冲突拆小，一次处理一个提交，再用git rebase --continue推进，成功率会高很多。硬着头皮一道命令想处理七个冲突，基本必炸。

# 顶不住的时候先撤，再换小步子推进 git rebase --abort # 拆成更小的单元 git rebase -i HEAD~5 # 每次解决一部分后 git add . git rebase --continue

3.3 场景三：共享分支上的一次手滑 reset --hard

这个场景我遇到过一次，印象极深。某实习生在共享分支上写了几个提交，觉得提交历史太乱，想回退重来，直接在本地执行了git reset --hard <旧版本>，接着git push -f。他发现远端确实变成他想要的样子，但小组其他成员拉取时全部报错，好几个人的本地提交陷入悬空状态。

事后复盘，他最大的错误不是使用reset，而是在共享分支上使用reset --hard并强推。共享分支的历史是整个团队的共同地基，地基一旦被抽走，所有基于它搭建的本地分支都会错乱。

如果情况已经发生，完整恢复链路如下：

1. 先让受影响的所有人停止操作，不要往同一个远端继续推送；
2. 找到那个被覆盖的提交的哈希值，可以从执行操作的人自己的reflog里查，也可以从其他成员本地仓库的reflog里查；
3. 在任意一个包含该提交的本地仓库里，用git checkout -b recovery <hash>把提交捞到一条新分支；
4. 把恢复分支推送到远端，让团队确认这个版本才是正确的目标版本；
5. 用正常的 merge 或 revert 流程，把远端头指针拉回正确位置，而不是再次强推。

这个链路最核心的步骤是“找哈希”。如果你在事故发生当天试过git reflog，那种一眼找到目标提交的爽快感，会牢牢刻在记忆力。我在关卡三里安排这个练习，目的就是让这个场景在训练期里先发生一次。

另一个安全习惯是：push 到共享远端前，先检查分支是否有其他人正在协作。如果是自己的功能分支，那是你的私人空间，可以随意改写历史；如果是多人共用的主干或者 release 分支，那就敬畏一点，只用新增提交来推进，不改写已有历史。

4. 一条能直接照抄的闯关路线：从可视化到仓库卫生

前面聊的是关卡设计和翻车场景，这一节我给出一条经过几轮迭代后相对成熟的完整学习路线。它不追求一次学完全部 git 功能，而是把命令拆成五个阶段，每个阶段都对应一组实战目标。

4.1 第一二阶段：先让眼睛看见，再让手形成习惯

很多新手学 git 最大的障碍是“看不见”。他们敲了命令，但不知道这些命令各自动了什么。所以我强烈建议第一阶段直接上一个带图的可视化工具，看git log --graph的彩色分支线，看分支切换时工作区文件的变化。眼睛先建立起直觉，命令行才会变得有意义。

第二阶段的训练重点只有一个：把分支协作变成日常习惯。有人可能觉得“我就一个人开发，干嘛还得分支”。我的回答是，分支习惯和驾驶习惯一样，等上高速再练就晚了。哪怕只是自己写一个模拟项目，也严格走“主干稳定保护、分支开发功能、合并留痕”的流程。我带的实习小组里，凡是坚持两周这种玩法的，后面进真实项目基本零磨合期。

4.2 把最容易混淆的三组概念一次讲清楚

闯关练完之后，大家普遍还有三个顽固疑问，我干脆在路线第五阶段开一堂课专门讲透。

第一组概念：git fetch和git pull有什么区别。一句话版本：fetch只负责把远端信息下载到本地索引，不动你的工作区；pull等于fetch加自动合并。推荐习惯是每天开工先fetch几次，确认差异后再决定是否 pull 或 rebase，而不是一上来就pull一把梭。这样能极大减少意外产生的 merge commit。

第二组概念：merge 和 rebase 到底选谁。我的选择标准很简单：如果这个分支是你个人临时用的、还没推到共享端，用 rebase 整理历史；如果分支要给别人看、要经过 Code Review，用 merge 保留清晰的分叉与合流节点。还有很多团队规定功能分支统一用 rebase 对齐远端、合流时用 merge 保留一条主线的 merge commit，这也是很成熟的做法。关键是团队要有统一约定，而不是每个人按自己的喜好混着来。

第三组概念：git reset三个参数到底删了什么。--soft只移动分支指针，改动全部留在暂存区；--mixed移动指针且清空暂存区，改动回到工作区；--hard移动指针且直接丢弃工作区改动。很多新手以为--hard是“更彻底的回退”，所以平时也爱用，问题就出在这里。日常工作里，回退提交大多数场景用--soft或者--mixed就够了，--hard只留给明确的“我确定这些改动不要了”的场景。

4.3 如何自己在本地搭一套“闯关仓库”

没有导师安排也没关系，这套闯关完全可以自己搭，而且搭一次能反复用。方法其实很简单：本地建一个仓库，用脚本模拟两个协作者，分别产生各自的提交，再故意制造冲突场景来练习。

比如我先正常提交三个版本，然后切出一条分支，在分支上改某个文件；再切回主干，在同一个文件上做出不同的修改。两个分支一合并，冲突自然就出现了。再比如，我在分支上提交之后执行git reset --hard丢掉它，再用git reflog找回来——每次练习都在加深对“仓库安全性”的理解。

我会建议把练习脚本和闯关关卡文档沉淀下来，放在团队内部知识库。下一批新同学来了，让他们照着文档自己搭一遍，比任何入职培训都有说服力。没人愿意听你说“正确做法是这样”，但当他自己亲手把出事的分支一点点救回来，他会一辈子记住那条命令。

5. 几轮带教下来，我自己也被“闯关”反哺了不少

这套玩法最开始是为了带实习生，结果几轮跑下来，先受益的反而是我自己。

为了把“事故现场”制造得足够真实，我每次都得预先往训练仓库里制造各种混乱的提交历史，时间一长，我把reflog的各种边界行为、rebase 中断状态下的文件流、reset 在不同参数下的实际差异摸了个透。以前我只是会用，现在能讲清楚底层对象模型，这水平完全是闯关的关卡设计逼出来的。

还有一次，实习小组里有人提了个特别好的问题：为什么 rebase 之后，提交的哈希值全变了？我带着他们做了一个小实验，人为改变提交信息中的某一处空白字符，观察哈希值变化，再解释提交内容、树对象和父提交如何共同决定哈希。那次讨论比我自己当年看的任何教程都透彻。

后来我们干脆把闯关题库做成开放式的，让上一届的实习生给下一届出关卡。新同学为了出题，必须把某个操作理解到位，知道哪种操作能导致什么灾难，这种出题过程本身就是最高强度的学习。我也在迭代中发现，真正让人快速上手的从来不是一本写满命令的说明书，而是几次贴着真实场景的失败和自救。

如果你们组也有一批新同学要加入，不妨把 git 培训当成一场协作冒险来设计，让事故以可控成本在训练场先发生一次。这比等事故在线上真发生，再让全组人跟着紧张，要划算得多。