企业官网建设流程全解析

1. 核心概念与工作流认知

先说点题外话。我不太推荐把Git当“工具书”去死记命令，那样今天学明天忘。真正好用的姿势，是先把它的核心模型刻在脑子里，之后你会发现大部分命令都是从这个模型“推”出来的。

Git和SVN这类老牌集中式版本管理最大的不同，就是它没有“中央权威”这东西。每个开发者本地都有一份完整的、带全部历史记录的仓库。这意味着你可以离线提交、离线查看历史、离线创建分支，哪怕远程服务器整个挂掉，你本地还是能继续开发和提交。这也是为什么Git能承载开源世界里那种“每个人都是主干开发者”的协作模式。

那这篇汇总，我按一条实际的项目开发链路来组织命令：

1. 起步阶段：仓库初始化、用户配置、忽略规则。
2. 日常编码：add、commit、status、diff，这是你一天里重复最多的操作。
3. 分支与合并：branch、checkout、merge、rebase，这是Git并发能力的核心。
4. 远端协作：clone、fetch、pull、push，这是多人协同的关键环节。
5. 历史回溯：log、reflog、reset、revert，这是挽回失误的后悔药。
6. 提效工具：stash、tag、别名等，这是顺手度和幸福感的来源。

每一类我都会讲一条核心的“为什么”，再补上实操命令和踩坑经验。下面开始。

1.1 三个区域：工作区、暂存区、版本库

Git日常操作中的所有混乱感，基本都来自于没搞清这三个区域。用一句话概括：

• 工作区：你肉眼看到、编辑器里正在改的那堆文件所在目录，也就是你电脑上项目文件夹里的内容。
• 暂存区：操作系统中隐藏的“中间盒子”，英文叫 staging area，很多老教程称之为 index。它记录的是“我准备把哪些内容打包进下一次提交”。
• 版本库：暂存区内容被 commit 之后，落定的历史快照就永久记录在这里。一个提交（commit）就是一份完整快照加提交信息、作者、时间、父提交。

日常生活最贴切的类比是快递打包。工作区是家里的所有物品，暂存区是已经放进快递盒、贴好单子的东西，版本库则是已完成揽收、运单号永久留存的包裹。你改了半天文件却忘记 add，或者 add 了没 commit，就是这个流程在半路断了。

![工作区、暂存区、版本库的关系说明：工作区修改——git add——暂存区——git commit——版本库]

注意：git add 之后、commit 之前，如果再次修改文件，那第二次修改仍然只存在于工作区，暂存区里还留着第一次 add 时的旧内容。这个细节是大量“我明明改了为什么提交的是旧版本”事故的根源。

1.2 HEAD 是什么，以及它为什么重要

Git 里有一个永远在动的指针，叫 HEAD。你只需要理解一句话：HEAD 通常指向当前所在分支的最新提交。

当你执行git commit，HEAD 会顺移自动前移到新提交；当你执行git checkout或git switch切换分支，HEAD 会跟着变；当你执行git reset --hard，HEAD 会强制拽回某个历史提交。

有了这个基础认知，后面讲 reset、checkout、rebase 的时候就不容易发懵。

2. 起步配置：仓库初始化与全局参数

2.1 初始化新仓库

在一个空目录或者已有项目根目录执行：

git init

这条命令会创建一个隐藏的.git文件夹。这个文件夹里就是仓库的全部家当，包括对象数据库、引用、配置、钩子脚本等。需要注意的是，它不是创世纪的开始，而更像在项目目录里放了一个“记录仪”，之后你对文件的所有操作才开始被 Git 追踪。

还有两种常用的 init 变体：

• git init -b main：直接把初始分支名设成 main，而不是默认的 master。新时代新项目我强烈建议这样干。
• git init --bare：这是给托管服务器准备的“裸仓库”。它没有工作区，只有历史和引用，专门用来接收 push。自己搭个人代码服务器的时候会用到，日常用不到。

2.2 用户信息配置

提交时 Git 必须知道你是谁。全局配置一次即可：

git config --global user.name "你的名字" git config --global user.email "you@example.com"

还有几个细节值得一起配了：

git config --global init.defaultBranch main # 默认分支名设为 main git config --global core.autocrlf input # Linux/macOS 下处理换行 git config --global alias.co checkout # 设置常用别名，后面说 git config --global pull.rebase false # pull 时用 merge 而不是 rebase，见后文

检查当前配置：

git config --list git config user.name # 单独查某个键

2.3 换行符与 .gitignore

跨平台协作最容易踩的暗坑就是换行符。Windows 用 CRLF，Linux/macOS 用 LF。Git 提供了 autocrlf 和 eol 等配置去自动转换，但说实话没有一种方案能让所有团队百分百满意。我的经验是：仓库内部统一用 LF，并为.gitattributes文件做兜底。

在仓库根目录新建.gitattributes：

* text=auto *.sh text eol=lf

这样能最大程度避免“明明没改文件，diff 里却全红”的换行符闹剧。

.gitignore用来声明哪些文件永远不应该被 Git 追踪。比如 Java 项目的target/、Node 的node_modules/、IDE 配置、日志等：

# 在项目根目录编写 .gitignore node_modules/ dist/ *.log .idea/ .vscode/ .DS_Store

重要教训：.gitignore只在文件“未被跟踪”时生效。如果你已经把文件提交上去了，再往 .gitignore 里写是没用的，必须先把文件从版本库里移除：git rm --cached 文件名。

3. 日常循环：add、commit 与状态检查

这是所有开发者每天重复最多的一组命令。很多新手在这一步的困惑不是不会用，而是“什么时候该 add，什么时候该 commit，commit 信息怎么写”。我把我的工作习惯直接摊开讲。

3.1 git status：先看病再开药

不要凭记忆瞎推当前仓库是什么状态，git status是你最靠谱的现场目击者。它会把三类文件分类列出来：

• Untracked files：工作区有新文件，Git 从未追踪过。
• Changes not staged：文件被修改过，修改内容还没进暂存区。
• Changes to be committed：已 add，等待 commit。

搭配一个短命令参数：

git status -s # short 模式，一坨输出变成一行一文件

-s模式输出的每行开头有两个字符位，第一列表示暂存区状态，第二列表示工作区状态。比如M表示修改了但没 add，M表示已 add，MM表示 add 之后又改了新的内容还没再 add。

3.2 git add：暂存操作的三种策略

git add <file> # 添加指定文件 git add . # 添加当前目录所有改动（含新文件） git add -A # 添加整个工作区所有改动 git add -u # 只暂存已被跟踪文件的修改/删除，忽略新文件 git add -p # 交互式分批暂存，只挑一部分改动进暂存区

工作中最常用的是-A，因为省事。但我强烈推荐在有复杂改动时用-p，它可以让你把同一文件的不同代码块拆开，一部分提交到一次 commit，另一部分留到下一次。这在高强度 code review 文化里简直是保命技能。

也经常有人问：git add 和 git add -A 到底啥区别？git add .只添加当前目录内（含子目录）的改动，而-A是整个仓库的改动。如果此时有一个文件在仓库的其他目录也被删了，你人在根目录下的子目录执行.，那个删除不会被记录；而-A会。建议平时直接无脑用-A。

3.3 git commit：提交信息不是玄学

git commit -m "fix: 修复登录接口偶发超时问题" git commit -am "跳过add直接提交已跟踪文件的修改" # 注意：只对已跟踪文件有效，新文件不行 git commit --amend # 修改上一次提交信息，或者补内容

写提交信息，我从一个老前辈那里学到一套很实用的结构：

• 第一行：动词 + 对象，不超过 50 个字符。动词用 fix、feat、docs、refactor、test 这类。
• 空一行后再写正文，说明为什么这么改，解决什么问题。多写“为什么”，少写“改了什么”。

为什么？因为半年后的你回看git log，会发现代码改动本身 diff 里全能看到，唯独当时的决策背景是任何地方都看不到的。

--amend是“悔棋卡”。适用于两种情况：提交信息写错了；或者刚才漏了个文件、改动不完整，想并入上一次提交而不是新开一笔。

git add -A git commit --amend -m "修正后的完整提交信息"

警示：amend 会改写提交哈希，所以只能改还没 push 到远端的本地提交。一旦 push 出去，队友已经基于它开发，amend 就会引出历史分叉，造成不必要的合并冲突。

3.4 git diff：看差异，别靠猜

提交之前检查改动，是个成本极低收益极高的习惯。三条命令覆盖主要场景：

git diff # 工作区 vs 暂存区（还没 add 的改动） git diff --cached # 暂存区 vs 上一次提交（已经 add 还没 commit 的改动） git diff HEAD # 工作区 + 暂存区 vs 上一次提交（所有本地改动）

默认 diff 输出非常原始。如果要看的是某几个文件的改动，或者只想看改动的统计而不想去啃大块补丁：

git diff --stat # 只看改了哪几个文件、增删多少行 git diff src/main.js # 只看某个文件 git diff HEAD~2 HEAD # 对比距今两次提交的状态

3.5 撤销未提交的修改：restore 与 checkout

工作区改到一半想放弃，或者文件被误删想找回，核心命令是 restore：

git restore <file> # 把工作区文件还原到暂存区版本（丢弃未add的修改） git restore --staged <file> # 把文件从暂存区撤销，变回未add状态，改动保留

--staged版本的场景很典型：你git add了个不该 add 的文件（比如密钥文件），但是又不想改动它，只想让它退出暂存区。这时候git restore --staged就是解药。

如果实在不习惯 restore，老式写法也可以：

git checkout -- <file> # 丢弃工作区修改 git reset HEAD <file> # 把暂存区的东西撤出来（老式写法）

不推荐混用老式和新式，挑一套用就成。

4. 分支操作：多开几条人生路线

4.1 分支的本质是老熟客指针

在了解新命令之前，先把这个观念钉进脑子里：

Git 分支本质上就是一个可移动的指针，指向某次提交对象。所谓“创建新分支”，就是让你在这个提交点再安一个带名字的指针。你可以在多个指针之间任意跳动，而历史的提交对象本身并没有被复制或破坏。

因此，Git 的分支操作极其轻量。它不像有些工具那样复制文件，也不占多少空间。可以任意多建分支来尝试不同想法。

日常命令速览：

git branch -a # 查看所有本地和远端分支 git branch <name> # 创建新分支（停留在当前分支） git branch -v # 查看各分支最新提交 git branch -m <old> <new> # 重命名分支 git branch -d <name> # 删除分支（-D 强制） git switch <name> # 切换到已有分支 git switch -c <name> # 创建并切换到新分支（老式：checkout -b）

关于新老命令：Git 2.23 之后引入了switch和restore，目的是把checkout承担的两类不同职责拆分。switch专职切分支，restore专职恢复文件。如果你是从新版本入门的，直接用switch不会错，语义也更清晰。

4.2 合并：merge 与冲突处理

合并最常用的是git merge：

git switch main git merge feature/login

Git 会自动找 main 和 feature/login 的分叉点，尝试把两边的改动合并到一起。如果两边改的是完全不同的文件，合并过程通常无感，Git 会直接生成一个新的“合并提交”。如果两边改了同一个文件的同一块区域，Git 就会停工，等你来仲裁。

冲突是什么样？打开冲突文件，你会看到这两组标记：

<<<<<<< HEAD 当前分支的代码 ======= 被合并分支的代码 >>>>>>> feature/login

处理步骤：

1. 手动编辑文件，把<<<<<<<、=======、>>>>>>>标记行删掉。
2. 保留你想要的代码版本。
3. 保存文件后git add <file>。
4. 最后执行git merge --continue，Git 会用你暂存的内容完成这次合并提交。

冲突不是 Git 的缺陷，它反而是 Git 谨慎工作的证明。真正要预防的其实是冲突次数过多——常见原因是两个分支长期没交互，或者代码职责边界不清楚。保持小步提交、频繁从主干拉取更新，能显著降低冲突概率。

4.3 rebase：让历史变得更线性

rebase的中文翻译“变基”很形象：把你当前分支上的提交，从原来的基点“拔”起来，重新安放到另一个基点之上。

git switch feature/login git rebase main # 把 main 的最新提交作为新基点，把自己的提交接上去

有人说 rebase 危险，我的观点是：危险的不是命令本身，而是在错误的场景乱用。规则只有一条——不要 rebase 已经公开、别人正在基于其开发的分支。

rebase 的价值体现在两点：

• 历史更干净：不会产生一堆 “Merge branch 'main' into feature” 这种噪音提交。
• 二次合并冲突可提前：你可以在本地把 main 拉到 feature 下面，提前解决冲突，再推到远端，而不是等远端合并时才发现。

对比总结：

5. 远程协作：clone、fetch、push、pull

5.1 clone 与 remote

拿到一个现成项目，第一件事通常是克隆：

git clone https://example.com/repo.git # 默认克隆到 repo 目录 git clone <url> my-project # 指定本地目录名 git clone --depth 1 <url> # 浅克隆，只要最新历史，省时省空间

克隆之后，Git 会自动把源仓库命名为origin，这就是“遥远的源头”的意思。管理远程连接的命令：

git remote -v # 查看远程地址列表 git remote add upstream <url> # 添加一个额外远程（常见于开源协作） git remote remove <name> # 移除远程引用 git remote set-url <name> <newurl> # 修改远程地址

开源项目的标准姿势是：origin指向自己的 fork，upstream指向原仓库。日常git pull upstream main拉原仓库更新，git push origin main推自己的改动。

5.2 fetch、pull、push 的分工

三兄弟要分开说：

• git fetch：只下载远端数据，不合并，不修改你的工作区。它把远端最新状态放进了本地的“远端跟踪分支”，比如origin/main。安全，无副作用。
• git pull：等价于fetch + merge（默认配置下）。它先把远端变更抓下来，然后自动和当前本地分支合并。一步到位，但可能引入合并提交或者冲突。
• git push：把本地提交推送到远端，可能让远端分支前进。

各自的姿势：

git fetch origin git fetch --all # 拉取所有远程 git pull origin main git push origin main git push -u origin feature/login # -u 代表 set upstream，设置上游分支

-u值得重点强调。第一次推送新分支时加上它，之后你就再也不用写origin和分支名了，直接git push和git pull就能用。

5.3 上游分支机制与同步策略

理解“上游分支”这词很关键。每个本地分支可以跟一个远端分支建立关联，这个关联就是“上游”，英文叫 upstream tracking branch。本地的main通常跟踪origin/main。

检查关联：

git branch -vv

这个输出的含义通常是：本地分支名、指向的提交哈希、与上游的关系（领先或落后多少个提交）。

我自己的同步策略很简单，供参考：

1. 开工前先git fetch看情况。
2. 本地直接git pull --rebase，把自己的小改动放到远端改动之后，保持历史线性。
3. 如果冲突，提前解决，然后git push。

--rebase版的 pull 有一个隐患：如果你当前分支已经 push 过、别人也在用，就不要这么干。个人建议在团队规范里固定一种策略，避免有人 merge、有人 rebase 导致历史来回打架。

5.4 推送被拒的常见原因

git push被拒绝，绝大多数是本地分支落后于远端分支。此时远端有本地没有的提交，Git 为了保护已有提交，拒绝让推送覆盖它们。

正确应对：

git pull --rebase git push

如果已经不是同事协作，而是你自己在两台机器上操作同一分支，pull 之后 push 基本能把问题解决。除非真的需要“强推”，才用git push --force-with-lease。这个命令比老式--force安全得多，因为它推送前会检查远端是否已经变成你最后一次看到的状态，防止你把别人更新冲掉。

6. 历史查看与回溯

6.1 把 log 用出花

git log本身就可以用太多种玩法了。挑实用的：

git log --oneline # 一行一次提交 git log --oneline --graph --all # 用 ASCII 图展示拓扑结构 git log -5 # 最近5条 git log --author="某开发者" # 按作者过滤 git log --since="2 weeks ago" # 按时间过滤 git log -p src/main.js # 查看某个文件每一次的完整 diff git log --grep="fix" # 按提交信息搜索关键词 git log --stat # 查看每次提交改了哪些文件 git log -S "某个函数名" # 搜索“某段代码字符串何时被引入”

最后一个-S非常神奇：它能帮你找出仓库里某句代码（或者任意字符串）是哪次提交引入的。我曾在一次线上 bug 排查里，用它定位到一行正则表达式是什么时候、被谁加进来的，省下了不知道多少翻历史的时间。

6.2 git show：看一个提交的全部面貌

git show <commit-hash> # 查看提交的详细信息 + diff git show HEAD # 查看当前最新提交 git show HEAD~2 # 查看前两个版本 git show <branch>:<filepath> # 查看某个分支上某个文件的版本内容

第三种写法简直是个隐藏的宝藏：不切换分支就能看别的分支上的某个文件长什么样。

6.3 reset 三阶段：软、中、硬

git reset是让许多初学者头皮发麻的命令，因为它能移动 HEAD 指针并影响暂存区和工作区。把三档理解清楚就不怕了：

git reset --soft HEAD~1 # 只移 HEAD，暂存区和工作区都保留 git reset HEAD~1 # mixed，默认，移 HEAD，暂存区复位，工作区保留 git reset --hard HEAD~1 # 全丢，回到上一次提交的快照，工作区+暂存区永久丢弃

场景示例：

• commit 后发现信息写错了、想重新来：git reset --soft HEAD~1，然后改提交信息再 commit。
• 一个 commit 里混入了不该提交的文件：git reset HEAD~1（或者git reset --mixed HEAD~1），让文件退回未 add 状态，再重新挑拣。
• 本地分支已经一团乱，彻底放弃当前改动回到上次提交：git reset --hard HEAD~1。

警告必须写清楚：--hard会直接丢弃工作区里未被提交的修改。我见过不止一个人，刚写完几小时的代码，因为在终端敲历史命令时按了向上的箭头不小心回放到了reset --hard，结果全没了。所以，--hard之前务必三思。

6.4 revert：面对已推送提交的“安全撤回”

如果出错提交已经 push 到远端，千万别 reset，reset 会改写公共历史。这时用revert：

git revert <commit-hash>

revert不是把那条提交删掉，而是在已有历史之上“反向应用”一次修改，生成一个反向的新提交，把之前的改动抵消掉。它不改变历史，所以团队成员 pull 的时候不会遇到历史分叉的恶心问题。

我经常告诉团队：本地没 push 的错，用 reset；已经 push 的错，用 revert。这条红线遵守了，远程协作基本不会乱。

6.5 reflog：失而复得的后悔药

最容易被忽略的命令之一是 reflog。我称它为 Git 的“操作日记”。它记录了 HEAD 指针在本地每一次移动的轨迹——包括那些被你 reset --hard 掉、看起来“永远消失”的提交。

git reflog # 类似输出 # 5a2b3c4 (HEAD -> main) HEAD@{0}: commit: fix: adjust style # 92f1e20 HEAD@{1}: checkout: moving from feature to main # ...

如果发现之前误删了分支或者 reset 丢了一堆提交，可以这样找回来：

git reflog # 找到目标提交哈希 git branch rescue <哈希> # 以该提交为起点重新拉一个分支 git switch rescue # 切过去检查内容

只要你本地对那个提交做过任何操作，reflog 都有机会把它捞回来。真正回不去的时候是 gc 已经清掉了次月前的旧对象，但这通常要过很久。所以，reflog 是我在无数事故现场最依赖的保命工具。

7. 藏匿工作区：stash

7.1 stash 的典型场景

正在某个分支上改代码，临时需要切到另一个分支去紧急修复一个问题。但改动还没完成，不想提交。这时候用 stash 把现场“原封不动”收起来：

git stash # 暂存当前改动，工作区恢复为干净状态 git stash save "带说明的暂存" # 带名字的暂存 git stash list # 查看暂存列表 git stash pop # 恢复最近一次暂存，并从列表删除 git stash apply # 恢复暂存，但保留列表记录 git stash drop # 删除一条暂存 git stash clear # 清空所有暂存

stash 默认只会暂存已经被 Git 跟踪过的文件修改。如果你新建了一个文件还没 add 过，它是不会被 stash 带走的。要让新文件也被暂存：

git stash -u # -u 包含 Untracked 的新文件

pop和apply的区别，就像你从储物柜里取东西：取完顺手清空柜子，还是取完还留着存根。日常切换用pop；想同一份改动同时用到多个分支，用apply。

7.2 多分支切换中的 stash 冲突

有时候会碰到：切到别的分支，stash pop 时提示冲突。原因很简单——你存的那份改动的上下文，和当前分支的这个文件状态对不上了。

处理办法：Git 会把能合并的合并，冲突部分仍然用<<<<<<<标记，手动解决然后git add。如果发现恢复错了场景，可以用git checkout <file>丢弃工作区内容，然后查看 stash 列表重新操作。

还有一个小技巧：stash 其实也是支持按分支管理的，git stash apply stash@{2}可以恢复指定某一条。

8. 标签管理

8.1 轻量标签与附注标签

发布版本时打 tag 是个好习惯。两类 tag：

git tag v1.0.0 # 轻量标签，单纯指向某次提交 git tag -a v1.0.0 -m "发布第一个稳定版本" # 附注标签，带打标签者、日期、说明

附注标签才是“完整对象”，它存了打标签的人和注解，适合正式发布。轻量标签则适合临时标记某个点。

补一个实用参数：给历史提交打标签。

git tag -a v1.0.0 <commit-hash> -m "补标"

8.2 标签与远端

标签不会随 push 自动上传，需要单独推送：

git push origin v1.0.0 # 推单个标签 git push origin --tags # 推送所有本地标签 git tag -d v1.0.0 # 删除本地标签 git push origin :refs/tags/v1.0.0 # 删除远端标签

如果你希望发布流程跟 tag 完全绑定，可以考虑在 push 版本号 tag 后，再通过 CI 触发构建。这比“看代码版本靠猜”靠谱得多。

9. 高频疑难杂症与避坑检查清单

9.1 Git 仓库里混进了不该提交的文件

密钥文件、大文件、编译产物，处理方式是先停止追踪但不删除本地文件：

git rm --cached config/secret.key

然后补充进 .gitignore。此操作会把“删除该文件跟踪”记入提交，push 后远端也就删掉了。

如果是超过 100MB 的大文件，建议不是硬塞进仓库，而是上 Git LFS 或者走对象存储。

9.2 提交信息写错 / 提交里漏了文件

• 还没 push：git commit --amend就能解决。
• 已经 push：不要 amend。追加一个新提交来修正即可。

9.3 误删分支或误 reset --hard

先别慌，用 reflog 捞：

git reflog git branch rescue <哈希>

只要时间离得近，几乎都能救回来。

9.4 pull 时频繁冲突

排查方向：

• 多人同时修改同一文件同一区域：建议拆任务边界，或者约定文件归属。
• 分支长期没同步主干：养成至少每天 pull 一次主干的习惯。
• 换行符问题让 diff 看起来全冲突：检查 .gitattributes 是否配好。

9.5 快捷指令速查表

手速最快的还是别名。我常用的会写进全局配置：

git config --global alias.st status git config --global alias.co checkout git config --global alias.br branch git config --global alias.ci commit git config --global alias.lg "log --oneline --graph --all" git config --global alias.last "log -1 HEAD"

配完之后git st、git lg用起来非常酸爽。

10. 实操心得与工作流建议

命令汇总归汇总，真正让 Git 好用的其实是工作流的习惯。最后分享几个我这些年打磨出的实操心得，不一定适合所有团队，但大概率能帮你少走弯路。

第一，提交粒度要小。一次 commit 就做一件事，比如修复某个函数、新增一个接口。不要攒了一堆改动再“一刀切”提交。小提交的 diff 好 review、回滚也精准，出问题定位更容易。

第二，提交前一定看一眼git diff。经常有人大意把调试日志、临时代码一起提交了。提交前的一两分钟扫一眼 diff 能拦住九成失误。

第三，分支命名含有语义。feature/user-login、fix/payment-timeout这种一眼就看得出意图的名字，比test1、ddd强太多。

第四，进阶之后再去折腾 .git/hooks 和自定义脚本。团队可以写一个 pre-commit 钩子做自动代码格式检查，用 pre-push 做 CI 轻量校验，这一套配合下来，能省去大量“垃圾提交”污染历史的成本。

第五，遇到不会的命令先git help <命令>。Git 自带的手册是所有命令的最高权威，而大多数搜索结果的博客内容反而可能是旧版本的行为。

Git 这东西，学起来并不难，真正值钱的是你能不能在每一个关键操作前想清楚“我现在在哪一步，下一步去哪”。把工作区、暂存区、版本库、远端、HEAD 这几根线理清楚，所有命令的呈现都会变得顺理成章。剩下的，就是在无数个小项目里反复练手，把肌肉记忆刻进每天的编码节奏里。希望这份汇总能成为你随时翻开的那张地图。