企业官网建设流程全解析

1. 先搞懂Git的存储模型，再背指令

两年前我带过一个新人，他花了一个星期把Git指令背得滚瓜烂熟，git add、git commit、git push敲得飞快，结果第一次合代码就把同事的分支搞得一团糟。问题出在哪？他根本不理解这些指令背后动的是哪一块数据。

Git指令学习最大的误区就是上来就背命令。就像学开车，你记住了油门刹车离合的位置，但不懂发动机和传动系统，上了路照样熄火。Git所有的指令，本质上都是在操作三个区域之间的数据流动——工作区、暂存区、本地仓库，再加上一个远程仓库。

打个日常生活的比方：工作区是你家里的厨房，食材买回来堆在台面上；暂存区是备菜盘，你把要下锅的食材挑出来切好放进去；本地仓库是冰箱，做好的菜放进去能长期保存；远程仓库是邻居家的冰箱，你把菜分给邻居一份，大家都可以取用。

你在工作区里正常写代码、改文件，这些改动对Git来说是"未跟踪"或"已修改"状态。执行git add就是把文件从工作区"挑出来"放进暂存区，相当于把食材放上备菜盘。再执行git commit，就是把这批备好的菜封存进冰箱，生成一个不可变的快照，这就是一次提交。git push则是把本地冰箱里的菜复制到邻居家冰箱。反过来，git fetch是从邻居家冰箱把菜搬到自己家冰箱，git pull是搬下来之后顺便直接摆到厨房台面上。

理解了这个三层模型，很多指令就不需要死记了。git status告诉你三个区域之间有什么差异，git diff具体展示差异内容，git log查看本地仓库的提交历史。所有指令的核心逻辑都围绕"数据在哪、数据要去哪"。

再拆一个容易混淆的点：git add到底做的是什么？很多人以为只是"标记了一下"，其实git add会在.git目录里创建一个临时的二进制对象，把文件内容完整复制进去。这也是为什么项目文件很多很大时git add会卡顿，它真心实意地在复制内容。而.git目录就是整个仓库的心脏，里面存着所有提交对象、分支指针、配置信息。

还有一个概念必须尽早建立：Git存储的不是"差异"，而是完整的快照。每次git commit，Git会把暂存区的所有文件内容打包成一个树对象，引用上一提交作为父提交，形成一条链。这也是为什么Git分支切换非常快——它只是移动一个指针而已。

2. 日常高频指令，逐个拆开讲清楚

2.1 初始化与首次提交的正确姿势

新项目落地，第一步是git init。这个指令会在当前目录生成.git隐藏目录。需要注意：如果你在一个已经包含大量文件的目录里直接执行git init，所有文件都会变成未追踪状态，但这并不代表它们被纳入了版本控制，只有git add之后才真正纳入。

第一次提交前有一个容易被忽略的配置项：用户信息。很多人不设置就提交，结果提交历史里留下一个"unknown"的尴尬记录。建议尽早执行：

git config --global user.name "你的名字" git config --global user.email "你的邮箱"

--global表示全局生效，不需要每个仓库重复设置。这一点很像给快递包裹贴面单：收件人信息不填，包裹在流转链路上就不知道算谁的。

首次提交的推荐步骤是这样的：

git init git add . git commit -m "chore: 项目初始化"

git add .会把这目录下所有文件加入暂存区，但坑点在于，如果你没有一份.gitignore文件，node_modules、dist这些不需要入库的目录也会被一股脑拖进去。给项目做首次提交之前，务必先配置好.gitignore，把依赖目录、构建产物、本地环境配置排除在外。这也是很多新手在仓库体积失控之后才明白的教训。

2.2 add、commit、push：循环往复的基础节奏

日常开发的核心循环是：改代码 →git add→git commit→ 反复几次 →git push。

关于git add有几个实用变体：

• git add -p：交互式逐块暂存。你改了三个文件，但只想提交其中一个文件的某几行改动，用这个指令可以进去逐段确认。这是做精细提交的利器。
• git add -u：只暂存已跟踪文件的修改和删除，不会把新文件加进来。修改存量代码时很实用，避免误加新文件。
• git add -A：暂存所有改动，包括新建、修改、删除。

提交信息是另一个值得认真对待的事。git commit -m "fix login bug"这种提交信息等于没说。推荐采用约定式提交（Conventional Commits）风格，格式为类型(范围): 描述，比如fix(auth): 修复登录态过期后跳转错误、feat(api): 新增批量导出接口。好处是后续看历史日志、自动生成changelog、配合发版工具都方便。我自己维护项目时，历史提交信息就是"事故复盘手册"——能快速定位哪次改动引入了问题。

git commit --amend是高频使用的修正指令，用来修改最后一次提交。比如提交之后发现少加了一个文件，或者提交信息写错了：

git add 忘记加的文件 git commit --amend --no-edit

--amend会把当前暂存区的改动合并到上一条提交里，--no-edit表示沿用原来的提交信息。注意：amend等于创建了一个新的提交对象，替换掉旧的提交。如果这个提交已经被push到远程，别人已经拉取了，你再去amend然后强推，会造成历史分叉。这一点后面讲回滚时还会展开。

git push到远程没什么特别，只需要知道第一次推送新分支时，要指定上游：

git push -u origin 分支名

-u是--set-upstream的简写，意思是为当前本地分支绑定一个远程追踪分支。绑定之后，后续只需要git push或git pull，Git就知道该跟谁通信。

2.3 status、diff、log：查询类指令怎么读

这几个指令是日常信息获取的来源，但很多人只会看个大概，没有真正读懂。

git status有两种推荐用法：

git status # 简洁信息 git status -sb # 分支跟踪关系 + 短格式

-sb会在第一行显示当前分支和与上游的领先/落后情况，比如[ahead 2]表示本地比远程多两个提交。下面逐项列出改动文件，分两类：Changes not staged for commit和Changes to be committed，分别对应工作区和暂存区的差异。

git diff的玩法：

• git diff：工作区和暂存区的差异
• git diff --cached：暂存区和本地仓库的差异

这个区分非常关键。很多人提交之后才发现提交内容不是自己想要的，就是因为没有区分这两层差异。在每次提交前，养成习惯执行git diff --cached检查一下即将提交的内容，能避免大量低级失误。

git log最实用的是图形化简洁输出：

git log --graph --oneline --decorate -10

--graph用ASCII线画出提交分叉结构，--oneline每条提交只显示一行，--decorate显示分支和标签指向，-10只看最近十条。进阶一点，git log -p会逐条显示每个提交的完整差异，虽然信息量很大，但排查问题或Code Review时很有用。

3. 分支与合并：协作场景下的核心操作

3.1 分支的本质：廉价指针

Git的分支设计是整个工具最精髓的部分。一个分支本质上就是一个指向某个提交对象的可变指针。创建分支只是新建一个指针，不复制文件、不修改内容，所以成本几乎为零。这也是为什么Git鼓励"频繁开分支"——在Git里，分支是一种工作流组织方式，而不是什么重型操作。

常用分支指令：

git branch 新分支名 # 创建分支 git branch # 列出本地分支 git switch 分支名 # 切换分支 git switch -c 新分支名 # 创建并切换

我用git switch而不是老式的git checkout -b，因为checkout身兼多职——既能切分支、又能恢复文件、还能检出历史版本，语义混乱。git switch和git restore是Git 2.23开始拆分的两个新指令，职责更清晰：switch只管切分支，restore只管恢复文件。

3.2 merge与rebase：两种合并逻辑

合并就是把一个分支的改动汇总到另一个分支。Git有两套合并策略：git merge和git rebase，这两者的差异是很多开发者的困惑之源。

git merge的逻辑是"汇合"。把dev分支合并进main分支时，Git会找到两个分支的共同祖先，把dev上所有新增改动和main上所有新增改动做三路合并，生成一个新的merge commit。历史图上会呈现分叉再合并的形状。

git rebase的逻辑是"搬移"。把dev分支rebase到main分支上，Git会把dev分支上的提交逐个摘下来，按顺序重新应用到main分支的最新提交之上。好处是历史是线性的，很干净；代价是dev分支的提交对象被重写了，它们的哈希值和提交时间都变了。

实际项目中怎么选？我的经验是：不共享的分支，用rebase来同步主干，保持历史线性；共享的分支，只用merge，绝不用rebase。因为rebase重写历史，一旦其他人已经基于这个分支开发，rebase之后别人的提交就像飘在空中一样，会引发连锁冲突。

在本地开发流程中，我推荐这样组合：

git switch dev git rebase main # 把main上的新提交，垫到dev下面 git switch main git merge dev # dev是线性的，merge时自动快进

这样main的历史会保持完全线性，而且dev其实已经把main的新代码合并过一遍了，merge时基本不会冲突。

3.3 合并冲突：处理时的完整思路

冲突是每个Git使用者绕不开的坎。本质上，冲突发生在Git无法自行决定"该保留哪边改动"的时候——比如两个人改了同一个文件的同一行。

当我遇到冲突提示，处理流程是：

git status # 查看哪些文件处于 unmerged 状态 git diff # 查看冲突详情

冲突区域在文件里被标记为这样：

<<<<<<< HEAD 当前分支的改动内容 ======= 被合并分支的改动内容 >>>>>>> dev分支

手动编辑文件，保留需要的部分，删掉<<<<<<<、=======、>>>>>>>这些标记行。全部处理完：

git add 冲突文件 git commit # 完成冲突合并

有一点必须强调：解决冲突时不要只保留一边的内容。新手容易犯的错误是看到冲突标记就慌，直接删掉对方的代码。正确思路是理解对方的意图，和你自己的改动比对，必要时跟对方沟通，然后写出兼顾两边的代码。

另外，用VS Code这类自带Git图形界面的编辑器时，冲突会出现三个选项按钮：Accept Current、Accept Incoming、Accept Both。但实际项目中，这三个按钮提供的选择往往是错的——因为真实的需求经常是"两者都不完全保留，而是组合后再改一下"。把冲突解决当成一次代码审阅，而不是一次"二选一"。

4. 回滚与撤销：关键时刻保命的指令

4.1 reset：本地历史的三种回退模式

git reset是本地回退的利器，它的三种模式对应着操作三个数据区域的不同层次。

git reset --soft HEAD~1 # 撤销提交，但保留暂存区 git reset --mixed HEAD~1 # 撤销提交，保留工作区改动但清空暂存区 git reset --hard HEAD~1 # 彻底撤销，所有改动消失

--soft相当于把"提交"这个动作收回，你已经暂存的文件内容不受影响，适合提交信息写错、想重新分组提交的场景。--mixed是默认模式，把提交和暂存都撤销，但工作区文件保持现状，适合"提交后发现改动不完整、想重新整理"的场景。--hard是最危险的，工作区和暂存区的所有改动直接丢弃，而且没有后悔药可吃——当然，如果你的IDE开了文件历史记录，可能还能找回来，但这已经超出了Git的能力范围。

所以我的建议是：git reset --hard是高三学生撕卷子式的操作——很爽，但只在确切知道自己在干什么时才用。一个更稳妥的做法是，reset之前先开一个临时分支保存现在的状态：

git switch -c backup-before-reset git switch 原分支 git reset --hard HEAD~1

万一发现回退错了，git switch backup-before-reset就能全盘找回来。

4.2 revert：安全撤销远端历史

前面说过，git reset --hard会重写历史，一旦提交已经push到远程，再strong push会干扰所有协作者。对于已经共享的提交，正确姿势是git revert。

git revert HEAD的逻辑不是删除那个提交，而是创建一个新的提交，把目标提交的改动反向应用回去。原提交继续留在历史里，只是它的效果被新提交抵消了。这样做的好处是历史不被重写，所有协作者的仓库保持同步。

revert还有几个实用变体：

git revert HEAD # 撤销最近一次提交 git revert 提交哈希值 # 撤销指定提交 git revert --no-commit 提交哈希值 # 暂缓操作，连续撤销多个提交

--no-commit很实用，先把多个要撤销的提交放进暂存区，一次性手动检查后统一提交。比如要撤销最近三个提交，但其中有一个的改版有一部分还需要保留，这时候就适合先一步步revert到暂存区，把要保留的部分改回来，再走一次commit。

4.3 找回丢失的提交：reflog是最后的保险单

git reflog是我认为最被低估的指令之一。它记录的是HEAD指针的所有移动历史——包括reset、rebase、merge、checkout，几乎所有操作都会在reflog里留下痕迹。这也是为什么即使做了git reset --hard，只要没过太久，提交对象通常还能找回来。

场景：你执行了git reset --hard HEAD~3，第二天发现其实应该保留那次提交的某个文件。执行：

git reflog

输出会列出类似这样的记录：

f0c2a1e HEAD@{0}: reset: moving to HEAD~3 b7d91f4 HEAD@{1}: commit: feat: 新增导出功能 3f2ab8d HEAD@{2}: commit: fix: 修复缓存穿透

可以看到被reset掉的那个提交是b7d91f4，那么：

git cherry-pick b7d91f4

就能把这个提交重新捡回来，只挑取这一个提交的改动。reflog条目默认保留时间是90天，足够覆盖大多数反悔场景。这就是Git给每个使用者的后悔药。

5. 从指令到工作流：真正学会用Git

5.1 一套可直接参考的日常开发工作流

指令学了不用等于没学。我把自己常用的工作流拆成一套固定流程，跟着走基本能应对大多数项目协作场景。

第一步：同步主干

git switch main git pull --ff-only

--ff-only要求远程更新只能通过快进合并拉取，如果有分叉就直接报错，防止意外生成merge commit污染历史。

第二步：开功能分支

git switch -c feature/xxx功能

分支命名我参考了业界常见的约定：feature/（新功能）、fix/（修复bug）、chore/（杂务）、refactor/（重构）。这样远程分支列表一拉，每个分支在干什么一目了然。

第三步：高频小步提交

git add 相关文件 git commit -m "feat(user): 新增用户昵称修改接口"

这里踩过的一个经验：提交粒度要小，小到"这个提交如果出问题，我能一眼看出哪一行导致的"。一个功能拆成四五次提交很常见，每次提交只包含一个逻辑单元。等所有功能完成后，再考虑要不要合并成一次优雅历史。

第四步：推送与开合并请求

git push -u origin feature/xxx功能

在GitLab/GitHub上发起Merge Request，让其他成员review。合入之前，确保分支基于最新的main：

git switch main git pull --ff-only git switch feature/xxx功能 git rebase main git push --force-with-lease

--force-with-lease比--force安全得多——它会先检查远程分支是否被你本地认知之外的人更新过，有人更新过就不强推，避免覆盖别人的提交。

5.2 常见协作事故复盘：从错误中学指令

这里复盘一个我之前实际遇到过的事故场景。某次团队协作，A同学在某功能分支上连续提交了十几次，准备合并时发现和main分支的冲突越来越多。他嫌rebase麻烦，改用git merge main，结果冲突海量出现，手动解决了两三个小时，最后因为文件状态混乱，索性git reset --hard origin/main把整个分支改成远程main的样子，所有功能代码丢了半天，最后靠reflog才找回来。

这段经历总结了几条惨痛教训：

• 功能分支长期不更新main，会产生大量累积冲突。正确节奏是每天开始或结束时同步一次main，冲突分散化，每次只有一点点。
• 解决冲突不要攒到最后一次解决。rebase时每次冲突只涉及当前那一个提交的改动，思路清晰；merge main时一下子把十几次提交的改动和main的改动混在一起，排查难度大很多。
• git reset --hard真的会让人紧张到出汗。关键时刻还是先备份现场再操作。

还有一个高频事故：git push被拒（non-fast-forward）。原因是远程分支有了你本地没有的提交，比如别的协作者已经推送了新修改。此时不要强行--force，正确操作是：

git pull --rebase git push

--rebase会把远程的新提交当作基底，你本地的改动以rebase方式垫在其上，历史保持线性。这比直接用git pull生成一个merge commit要干净得多。

5.3 提效技巧：别名、模板与钩子

指令用得久了，你会开始追求效率。我最先做的一件事是配置了一套Git别名：

git config --global alias.st status git config --global alias.co checkout git config --global alias.br branch git config --global alias.cm "commit -m" git config --global alias.lg "log --graph --oneline --decorate -10" git config --global alias.unstage "reset HEAD --"

之后git st、git co、git cm "feat: xxx"、git lg就成了肌肉记忆里的动作。省下的时间不多，但减少了不少打断心流的阻力。

再推荐一个容易被忽略的配置：提交信息模板。如果你希望团队所有成员的提交格式统一，可以在仓库根目录放commit-template.txt，然后：

git config --local commit.template ./commit-template.txt

提交时执行git commit会自动打开模板，照着填信息即可，省去记忆格式的成本。

还有一类提效工具是Git钩子（Hooks）。.git/hooks目录下放着各种钩子脚本，比如pre-commit可以在提交前自动跑lint和测试，commit-msg可以强制执行提交信息规范。我自己项目里配置过一个最简单的pre-commit钩子：

#!/bin/sh npm run lint

如果lint没过，提交直接被拒绝。这类自动化看起来很朴素，但真正用起来，对代码质量的保障比什么口头约定都管用。

关于Git的指令学习，我在实际带项目的过程中最大的体会是：不要把Git指令当成要背的语法清单，而是当成一套数据流转的操作工具。理解了每个指令改变的是哪个区域、指针移到了哪里、数据流向了何方，绝大多数指令都可以触类旁通。最开始不熟悉的阶段，感觉像是在跟一个脾气古怪的同事打交道——指令没学扎实就会踩坑；坚持下去之后，它就成了最可靠的协作者。

最后分享一个实用的小技巧：如果你对一个指令的某一种参数组合不熟悉，创建一个临时目录，git init后随便建几个文件，去做各种实验——reset、rebase、cherry-pick，随便玩，反正只是实验环境。在真实项目里不敢做的操作，在临时目录里大胆做一次，比看十遍文档都管用。