企业官网建设流程全解析

1. 提交与合并，先搞懂这两个动作分别改变了什么

很多用 Git 的人，天天在敲git commit和git merge，但要问这两者到底有什么区别，能说清楚的人真不多。我见过不少团队里，新人把 commit 当保存按钮，把 merge 当“把代码挪过去”的操作，结果分支图一团乱麻，回滚的时候无从下手。其实这两个命令的差别，本质上就是“记录状态”和“汇总历史”的差别，理解了这个，你后面遇到的一切分支问题都会迎刃而解。

先给一个最直观的类比：commit就像你写文章时按下 Ctrl+S，把当前的快照存进本地仓库，它是你工作进度的存档点；而merge是把两条不同路径上的工作成果汇到同一条路上，像两条河汇成一条，它的核心动作是“融合”。注意这里的关键差异——commit 永远只影响你自己当前所在的分支，它在“你的时间线”上打一个点，标记“到此为止，这个状态我要保留”；而 merge 会影响到两条分支之间的关系，它把另一条分支上的历史接到当前分支的历史里，让两条发展路线从此共享子孙。

再往深一层看。commit 一旦创建，它就是永久的、不可变的，如果你觉得刚才的提交写错了，你并不是去“改”那个提交，而是创建一个新的提交来覆盖它的位置（或者用--amend替换最近那一次）。而 merge 创建的是一个“合并提交”（merge commit），这个提交特殊在它有不止一个父提交，它记录了“这次汇合，我是从哪两个方向过来的”。正是这个多父提交的结构，让 Git 能够在未来保留你分支的完整脉络——你一眼就能从历史图里看到 feature 分支是在哪个点长出来的，又是在哪个点并回去的。

还有一个很多人忽略的点：commit 是解决“状态保存”的手段，它本身不产生任何代码层面的“内容差异解决”动作；而 merge 是需要做“差异对齐”的。换句话说，你提交 100 次，每次都是干净利落、互不干扰的；但每 merge 一次，都可能需要面对冲突——因为 Git 需要判断两条分支上对同一处代码的修改到底听谁的。这个差异，也直接决定了对你心智模型的要求。日常开发中，commit 是高频动作，几乎无脑执行；merge 是低频但严肃的动作，执行之前你要心里有数。

所以结论先摆出来：commit 是“沿着自己这条时间线往前走”，merge 是“把另一个时间线缝合到当前时间线上”。这也是为什么很多团队会约定“提交要小、要频繁，合并要慎重、要经过审查”——前者的成本极低，后者的影响面极广。

2. 从底层对象模型看，commit 和 merge 的本质差别

如果你用过 Git 一段时间，大概听说过 Git 的“三个区域”和“四种对象”。这里不讲那些入门教程里的概念复读，直接拆开看创建 commit 和创建 merge 提交时，Git 底层分别做了什么。

2.1 commit 只是增加一个快照链条上的节点

Git 的一切都是对象：blob 存文件内容，tree 存目录结构，commit 存一次提交的元信息。当你执行git commit时，Git 会做这几件事：

1. 把暂存区的内容打包成 tree 对象（如果你的工作区有改动但没有git add，这部分不会进提交）。
2. 创建一个 commit 对象，它内部记载了这棵 tree 的指针、父提交的指针（就是上一个 commit）以及 author、committer、提交日期、提交信息。
3. 把当前分支的引用（也就是.git/refs/heads/下那个分支文件）从旧 commit 移动到新 commit。

看清楚没？commit 这个动作，本质上就是“在当前分支指针上，追加一个新节点”。它不需要关心别的分支在干什么，也没有任何“比较”和“协商”过程。只要你没有触发git hook或者 GPG 签名，这个动作几乎不会失败，失败多半也只是因为 user.name / user.email 没配置。

一句话总结：commit = 在当前分支链条上追加快照节点。你说的“提交注释”，就是写进 commit 对象里的 message 字段。这里有个常见误区，很多人以为git commit是“保存所有改动”，其实它保存的是“你放在暂存区里的改动”。你没git add的内容，提交之后依然会留在工作区，以未暂存状态存在。很多人第一次用 Git 时，commit 完发现文件还在，以为提交失败了，其实就是暂存区的概念没理顺。

2.2 merge 创建的是“多父提交”，把两条链打成一个节点

而git merge <branch>执行时，Git 会根据两个分支的分叉点（merge base）做三路合并。具体来说，它要比较三个版本：你的分支、对方分支、以及它们共同的祖先。合并成功之后，Git 要么走 fast-forward 直接前移指针，要么创建一个新的 merge commit。

Fast-forward（快进）是不产生新提交的：当你的当前分支处于对方分支的直接祖先时，Git 直接把当前分支的指针移动到对方分支的位置，这条历史就是一条直线。听起来很完美对吧？但这也是很多团队禁用它的原因——快进合并虽然干净，却没有留下“这里发生过一次分支汇合”的痕迹，feature 分支上所有的 commit 都像直接长在主分支上，历史不好回看。

另一种是真正的 merge commit，这才是 merge 最经典的形态。它会创建一个带两个父提交的新 commit，这是 commit 和 merge 在底层模型上最显著的差异——普通 commit 只有一个 parent，merge commit 至少有两个 parent。正因为有这个结构，Git 才能在合并完成后，依旧追溯出“这条分支线是从哪个点分出来的、又是在哪个点并回来的”。如果你用git log --graph看分支历史，那些岔路和汇合点的结构，全靠多父提交才能画出来。

我见过不少人问“为什么 merge 之后要用git revert -m 1才能撤销，而不是直接git revert”，原因就在这个多父提交上。git revert一个普通的 commit，Git 知道它只有一个父节点，反向打补丁就完事；但 merge commit 有多个父节点，Git 必须由你指定“我要撤销到哪个父节点那一侧”，所以才有了-m 1或-m 2这样的参数。很多人在这一步踩坑，本质上就是没理解 merge 的对象结构。

3. 实操场景：什么时候该 commit，什么时候该 merge

理解完底层，咱落到实际开发里来。我把常见的操作场景和命令拆开讲，结合我自己的使用习惯，给你一套可以直接照抄的流程。

3.1 高频率的 commit 记录，让每一步改动可追溯

先说 commit 的实操。我个人的习惯是“一个逻辑改动一次提交”：修复一个 bug、加一个小功能、调整一处重构，都分别提交。这样做的好处太多了——你可以随时git log看每一步的用意，也可以用git bisect精准定位哪次提交引入了问题。要是你三天才提交一次，一次提交里塞了几十个文件的改动，出了问题你只能对着一个巨大的 diff 发愁。

每次提交前，花十秒钟做一次“自检三连”：

git status # 看当前工作区和暂存区状态 git diff # 看还没暂存的那些改动，确认没有误改 git diff --cached # 看已经暂存、即将进提交的内容

这三条命令我会在 commit 前几乎每次必敲，目的就是确认“我要提交的东西和我以为的东西是一致的”。这也是为什么我不太建议你无脑git commit -am "xxx"一把梭——-a会把所有已跟踪文件的改动全部暂存，万一里头混了个调试日志、临时配置文件，你就会把不该提交的东西带进历史。

再说一个热搜词里大家都很关心的命令：git commit --amend。这个命令我愿称之为“后悔药”，但也得把它的副作用讲清楚。--amend不是真的修改上一次提交，而是用一个新的提交替换它，新提交的父节点和旧提交的父节点一致，所以看起来“像是改写了上一次提交”。它最适合用在“刚提交完发现 message 写错了”“忘了把某个文件加入上一次提交”这些场景。

但注意——amend 会改写提交对象，等于改写历史。如果这个 commit 已经被你 push 到远端，并且别人已经拉下来了，你再去 amend，就会导致本地和远端的历史分叉，下一次 push 会被拒绝，只能强制推送。团队协作中，对已公开的提交执行 amend 是一个相当危险的动作。我的实践经验是：只在本地尚未推送时放心用，推送之后宁可多做一个新提交来修正，也别 amend。

3.2 低频的 merge，合并前先分清三种合并策略

再来看 merge 的实操。这里的第一个重点，是搞清楚--ff、--no-ff和--ff-only三种策略的区别，因为大部分人对 merge 的疑惑都源于此。

这三条里面，我个人的建议是：合并 feature 分支到 main 时默认--no-ff，因为它会给历史留下一个清晰的“合并事件”节点，方便后来的人回溯“这个功能是什么时候合进主干线的”。而平时想把 main 的最新更新拉进自己的 feature 分支、但不想产生一堆无意义的 merge commit 时，我反而会倾向用 fetch + rebase，或者git pull --rebase来保持历史干净——这也就是热搜词里“merge rebase”的来源。这个话题稍微展开一下：rebase 和 merge 解决的是同一个问题（合并两边的改动），但策略相反。文章后面我会单独用一个章节讲清楚它们的取舍，这边先按住不表。

再强调一个 merge 前必须养成的习惯——先保证工作区是干净的。如果你本地有未提交的改动就直接 merge，极有可能在合并过程中撞上“本地改动被覆盖”的提示。我在团队里一直跟大家强调一个原则：任何可能改变历史结构的操作，都先git status确认工作区干净，再git stash或者先 commit，否则出问题你根本分不清是合并引入的冲突还是你自己手头的烂摊子。

3.3 配合推送策略，合并前先解决远端历史分叉

其实 merge 在本地用起来很简单，复杂的是“远端已经领先”这个情况。我在实际协作中经常遇到这一幕：我在 feature 分支上把代码合并到了 main，准备git push，结果提示被拒绝，因为远端 main 上有别人刚推的提交。这时如果你不做任何处理直接git pull，Git 会自动生成本地合并提交（如果没设置 pull 的默认合并策略），历史就会多出很多“Merge branch 'main' into feature”这样没什么信息量的节点。

我的习惯是：git pull --rebase拉取远端更新，把本地开发的小提交“垫”到远端提交之后，历史一条直线，整洁得多。但这条策略有个要求——本地提交千万不要有已经推到远端的分支共享的提交，否则 rebase 会把别人的提交也一并重放，历史改写面会迅速扩大。简单说就是：自己私有分支随便 rebase，公共分支绝不 rebase，这个分寸要拿捏好。

4. 冲突现场：merge 遇到冲突，如何定位、解决与回退

merge 在所有 Git 操作里最劝退新人的地方，就是冲突。我见过不止一个开发者在冲突面前抓狂，然后直接把自己的分支删了重新拉。其实冲突并不可怕，它只是 Git 在告诉你：“两边都改过同一个地方，我没办法替你乱猜，请你来裁决。”而裁决之前，你得先看懂 Git 在冲突标记里给你留了什么线索。

4.1 冲突标记里藏的信息，一眼定位改动来源

当你 merge 两个分支发生冲突时，Git 会在冲突文件里植入这样的标记：

<<<<<<< HEAD // 当前分支（你正在 merge 时的位置）上的内容 ======= // 被合并进来的分支上的内容 >>>>>>> feature/xxx

注意看，HEAD和feature/xxx这两个标签非常关键——它们告诉你说，上方是当前分支的版本，下方是对方分支的版本。特别要说一嘴，很多人以为<<<<<<< HEAD里的一定是正确的，这不一定，两边可能是“各自的正确”：你在主分支修了 bug，他在 feature 分支也修了同一个 bug，但方式不同，你需要在两者中做取舍，甚至组合起来才是最终答案。

这个场景最典型的就是“json merge conflict”。热搜词里提到的 json merge conflict 我在实际项目里碰到过好多次，而且大多数时候不是代码逻辑冲突，而是格式调整导致的全文件冲突——比如一个 json 文件被你格式化成了新的缩进，对方也改了缩进，然后 Git 的 diff 算法就懵了，把整个文件都标记成冲突。遇到这种，我的建议是：先别急着手动一行行改，先用git merge --abort退出去，检查两边到底是不是只有格式层面的差异，如果是，那就应该让其中一方重新调整格式后提交，另一方 rebase 后再合并，避免把无意义的格式变动灌进历史。真要是非得解决，推荐用一个第三方 diff 工具，比如 IDE 自带的比较器、Beyond Compare 或者 Meld，可视化处理会比在终端里面对尖括号高效得多。

4.2 解决冲突的正确姿势与提交流程

手动解决完冲突后，必须做一个动作：git add将改动后的文件标记为“已解决”。注意，这是很多人漏掉的一步——只保存了文件，没git add就立刻尝试git merge --continue，Git 会提示你没有暂存的合并结果。正确流程是：

git merge feature/xxx # 报冲突后 git status # 找出哪些文件处于 Unmerged 状态 # 手动编辑冲突文件，处理每一处 <<<<<<< ======= >>>>>>> git add <file> # 逐文件标记为已解决 git merge --continue # 或直接 git commit（等价，但前者会自动带上merge信息）

有几个容易踩的坑，我单独拎出来讲。第一，解决冲突时千万不要用git checkout --ours或git checkout --theirs无脑覆盖——你还是得看具体内容，因为完整覆盖往往意味着丢掉另外一边的合法改动。第二，冲突文件里所有<<<<<<<、=======、>>>>>>>必须全部清干净，不能只改了你关注的那部分就草草提交。曾有同事在提交前保留了一个>>>>>>>，导致代码编译不过，查了半天才发现在一个很隐蔽的注释里。第三，冲突解决完成后，测试是不变的硬要求——merge 本身不改变代码逻辑，但你把两边内容组合在一起，运行时是否兼容、依赖是否有版本差异，这都不是编译期能保证的，该跑的测试别跳过。

4.3 回退 merge 的两种思路：reset 与 revert

merge 操作本身也是可以撤销的，但“怎么撤”取决于你的处境。如果是本地刚 merge、还没 push，最简单的办法是git reset --hard HEAD@{1}或者用git reflog回退，甚至直接在 IDE 里（比如 Idea 的 Log 面板）右键 reset 到 merge 之前的那个提交。热搜词里的“idea中如何回退merge操作”，本质就是定位到 merge 之前的提交，做一次reset。这里有个细节，reset --hard会把工作区代码一并恢复到目标提交的状态，本地的未提交改动会丢失，所以执行前务必确认 stash 或已提交。

但要是 merge 已经推送到了远端，情况就不一样了。你不能再 local 强行 reset，因为远端历史已经被别人拉走了，你再 force push 改动历史，会让所有协作者的仓库陷入混乱。这时正确做法是git revert -m 1 <merge-commit>。-m 1的意思是“保留第一个父节点（通常是合并前主干线的状态），撤销合并带来的改动”。

我要提醒的是，revert 一个 merge commit 之后，如果后续想重新把这条分支合进来，会遇到一个让很多人懵圈的坑：直接再 merge 一次，Git 会告诉你“已经是最新的”，什么也不做。为什么？因为 revert 本质上是一个新的提交，它只是把那次合并的内容效果撤销了，但分支历史结构上，那条 feature 分支的提交节点已经通过原来的 merge commit 连进来了，Git 认为它已经合并过了。此时如果你真想重新合入，通常要用git revert <上次revert的commit>，把那次“撤销”给撤销回来，或者用git rebase --reapply-cherry-picks之类的手段。这种场景太容易发生在 UI 操作上——同事在 Idea 里点了一下 Revert，代码回滚了，但分支关系也乱了。所以我在实际工作中，都会问一句“这个 merge 到底 push 了没有”，再决定用 reset 还是 revert，这一步分清了，后面能少掉一半麻烦。

5. commit 和 merge 最容易被搞混的边界：rebase、amend 与 fast-forward

说实话，Git 里很多概念不是单独存在，而是几个相近操作组合在一起后产生了微妙的边界。热搜词里反复出现 merge rebase、git commit --amend、git merge into，就把这个边界推到了大家面前。我单独开一节，把这两三组易混的概念彻底讲透。

5.1 merge 与 rebase：同一问题，两种叙事风格

merge 和 rebase 都是“把一条分支的改动合并到当前分支”的操作，但它们对历史的叙述方式完全相反。merge 是“如实记录”，就是你从哪分的叉，从哪并的汇，都原封不动画出来；rebase 是“改写叙事”，它把你当前这条分支上的提交一个个抽取出来，然后“垫到”目标分支的最新提交之后，你本地的分支历史看起来像是直接从那条分支上长出来的。

这两个词对应的场景其实很清晰：rebase 适合自己维护的本地特性分支，你可以把主干的最新进展 rebase 到自己的分支下面，让历史保持线性，方便 review，也方便后续用git log追踪；merge 适合发布节点和公共分支，因为公共分支的历史必须稳定，不能被任何人的 rebase 改写。所以很多团队约定“对你自己的分支用 rebase 变成最新，对主分支用 merge 收编功能”。这个约定不是说绝对正确，但对我来说实践下来非常好用。

5.2 commit --amend 的本质是“替换”，不是“修改”

前面讲个人实操时已经提到了--amend的基本用法，这里补充一个更重要的操作场景：它不仅能改 message，还能往上次提交里补充遗漏的文件。做法是：

git add 遗漏的文件 git commit --amend --no-edit

--no-edit的意思是沿用上一次的提交信息，不加这个参数的话，Git 会弹出编辑器让你重新输入 message。这个操作特别适合“上一个提交里少了某个新文件”的场景。但请务必记住——它产生的是一个全新的 commit 对象，旧 commit 会被丢进回收区，过段时间由git gc清理。如果你已经把这个 commit 推到了公共分支，就千万别 amend 了，否则别人拉下来的历史和你的正好错开半个身位，整个团队的仓库会变得异常混乱。

另外还有一个顺带的技巧，就是想“未推送的多个提交合并成一个”时，你其实可以连续做几次git commit --amend --no-edit，把新的改动不断揉到最顶上一个提交里。不过这种改写在多人协作中同样只适用于你刚创建、尚未共享的分支。真要应对局部整理，更正统的做法还是git rebase -i，可以把多个 commits 合并成一个、调整顺序、改 message 等等，scenario 更丰富，但对新手的操作门槛也更高，这里就不展开啦，自己熟了你就会发现它的好。

5.3 fast-forward 直连 vs 真实 merge：你用的是哪一种

还有一个容易混淆的点，就是 fast-forward 到底算不算 merge？严格来说，fast-forward 是 Git 合并策略的一种，但它和“创建 merge commit”完全不同。fast-forward 发生时，Git 只是把你当前分支的指针从旧位置直接移动到你想要合并的分支的最新位置，因为当前分支就是对方分支的一个祖先节点，历史之间没有任何分叉，所以不需要创建任何新提交。

这就是为什么很多团队会觉得 fast-forward 合并后“看不出来当时有过一个 feature 分支”。他们更希望保留“功能合并”这个事件节点，好评估“这个功能从开始开发到合入主干、大概经历了多少提交、跨度有多大”，所以会强制--no-ff。而有些个人维护者则喜欢 fast-forward，因为历史干净整洁，整个仓库只有一条直线。本质上这两种选择没有绝对的对错，你们团队想要哪种叙事风格，用哪种策略。只要记住一点——如果你用了--ff-only，意味着你完全拒绝创建 merge commit，一旦检测到分叉就会被拒绝执行，这条命令在自动化脚本里尤其常见，因为它是一种“保险生效就成功、失效就中断”的确定性策略。

6. 常见报错与处理速查：这些坑我基本都踩过

最后把热搜词里出现的几个具体词条逐一拆解，整理成一份可以直接照着处理的速查表。这些报错每个都是真实场景里高频出现的，我敢说你迟早会遇到。

6.1 username and email must be set before commit

这条是很多新手在第一次 commit 时遇到的第一堵墙。它的含义就是：Git 在创建 commit 对象时，必须记录是谁提交的，但你的全局配置里没有 user.name 和 user.email，于是 Git 拒绝执行。

解决方式有两种：

# 全局配置（对所有仓库生效） git config --global user.name "你的名字" git config --global user.email "你的邮箱" # 仓库级配置（仅对当前仓库生效） git config --local user.name "你的名字" git config --local user.email "你的邮箱"

我的建议是，如果一台电脑只属于你个人办公，就用全局配置一次搞定；但如果你在同一台机器上以不同身份提交不同项目（比如公司项目和开源项目），那一定要用--local单独配置，避免把公司邮箱漏到开源仓库里。顺带一提，commit 信息是永久记录的，一旦提交后修改 user.name / user.email 也改变不了历史里已有的记录（除非改写历史），所以第一次配置就尽量别填错。

6.2 ssh 认证失败与 git clone/pull/push 被打回

“ssh认证失败 git” 这个热搜词背后，几乎都是同一类问题：你的本地仓库通过 SSH 协议访问远端，但 SSH 密钥和远端仓库配置对不上。排查路径一般是这样的：

1. 先ssh -T git@请代入你的服务器地址检查 SSH 连接本身是否通。
2. 如果提示 permission denied，去检查你本地的~/.ssh/目录里有没有正确生成密钥对（ssh-keygen），以及是否已经把公钥添加到了代码托管平台的账户里。
3. 如果密钥明明是对的但依旧失败，多半是远端仓库路径配错了，检查远端地址是不是git@host:group/repo.git。
4. 还有一种情况是首次连接时 host key 提示确认，得手输yes确认。

这种问题本身和 commit/merge 没直接关系，但它会在你 clone 一个仓库、准备做第一次 commit 之前就拦你一道，所以一并放进速查表。

6.3 git merge into 与分支选择的认知偏差

“git merge into”这个热搜词，其实暴露了一个很常见的命令理解偏差——不少人以为 merge 有个“into”参数，可以把 A 分支合并到 B 分支。实际上git merge的动作永远是“把指定分支合并进当前分支”，没有“into”这个词。你要把 feature 合入 main，正确的操作顺序是：

git checkout main git pull --rebase origin main # 先保证 main 是最新的 git merge feature/xxx

站在哪个分支上执行，就合并到哪个分支。这是一个天然的安全机制，也因为这一点，我特别建议新手在 merge 前养成先看git branch的习惯，确认自己正站在目标分支上。很多人误把git merge feature当成“把当前分支合到 feature”，结果把主干分叉得一团糟，根源就是没搞清 merge 的“方向”。

收尾：一点点个人的实操体会

Git 用了这么多年，我自己最大的体会就是：commit 和 merge 这两个动作，本质上代表了两种不同的心智模式。commit 是“对自己负责”——你今天写了什么、改了哪个问题，留下清晰的节点，将来自己回看或者别人接手时，都能看懂每一步；merge 是“对别人负责”——你把手上的成果与别人的成果汇合，这块做得好不好，直接影响整个团队的工作效率和项目历史的可读性。它们没有高低之分，只是各自的职责和风险等级完全不同。

所以如果你想在团队里把 Git 用好，别急着追求那些花哨的命令，先把这两个基础动作的边界练到肌肉记忆：每次 commit 前想清楚“这个提交是否足够小、是否只包含这个意图的改动”，每次 merge 前想清楚“当前分支是否干净、目标分支是否为最新、要保留怎样的历史结构”。把这一层想明白了，rebase、amend、cherry-pick 那些进阶操作都只是顺水推舟的事情。

如果这篇文章能帮你把这两个动作的底层差别理清楚，那我觉得比收藏一堆“Git 高级命令大全”要有用得多。毕竟命令是死的，什么时候该用哪个命令、用了以后对历史产生什么影响，这才是真正属于你的实战经验。