企业官网建设流程全解析

很多人学了三年 Git，还是复制粘贴那七八个命令。add、commit、push、pull，再多就发怵。可一旦遇到需要回滚、整理历史、修复冲突的场景，就只能靠删库重来或者去找“保命命令”的帖子。2026 年了，Git 自身的能力早就不是当年那个只能提交代码的工具，分支管理、历史改写、安全加固、仓库维护都已经内置得很成熟。这篇东西不是翻译 man page 的命令大全，是我自己在实际维护项目、带新人、处理线上事故时真正高频使用的一套命令清单，附带我踩过的坑和为什么这么用的思路。适合刚把 Git 用熟但想更进一步的人，也适合能给团队定规矩、做代码评审的人。

1. 2026 年使用 Git 前必须做好的三件事

1.1 确认 Git 版本并了解默认行为变化

在开始之前，先看看你本地 Git 版本。如果你还在用两年前装的 2.3x 或者更老的版本，那么很多我在下文提到的命令（比如switch、restore、sparse-checkout）都用不了，或者行为跟新版本不一致。2026 年的主流 Git 版本已经进入 2.4x 时代，安全策略和默认配置都有不少调整。

git --version

我见过不少团队，统一要求 Git 版本不低于某个基线，原因很简单：不同版本对换行符处理、子模块行为、甚至pull的默认合并策略都有差异，这些坑在团队协作时会变成莫名其妙的冲突。建议至少保持在 2.40 以上，如果公司有统一的安装包，直接跟着走就好。

另一个重要的默认行为变化是初始分支名。新版 Git 默认初始分支已经是main，但如果你从旧版本升级上来，或者在老仓库里初始化，可能还是master。这两种命名本身没有优劣，但团队内如果不统一，会出现“我推的main跟你的master不是同一个分支”这种低级问题。定好一条规则：新仓库统一用main，老仓库如果团队想切换，可以在仓库设置里改默认分支并同步删除旧分支。

1.2 先配置好你的身份和换行符

Git 提交记录里每一笔都带着作者信息。如果没设置全局 name 和 email，提交时会用一个根据机器名生成的默认身份，提交历史会变成一堆“unknown”。这个配置建议在安装后就做掉：

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

注意这里填写的邮箱尽量跟代码托管平台账号一致，这样提交能正确关联到你的账号头像。另一个关键配置是换行符：

git config --global core.autocrlf input # mac / linux git config --global core.autocrlf true # windows

小白最容易在这里翻车。Windows 默认换行符是 CRLF，Linux/mac 是 LF，跨平台协作时 Git 会看到大量“整行都改了”的假差异。设置core.autocrlf后，Git 会在提交时自动把 CRLF 转成 LF，在检出到工作区时再按平台还原。实际踩过坑的都知道，这配置没设对，diff 根本没法看。

1.3 配置别名和常用选项，让日常操作更快

Git 的原生命令太长了。我每天敲得最多的不是git status，而是git st、git ci、git lg。这些全靠别名。推荐一套我用了很久的配置：

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

注意lg这个别名特别有用，它会把提交历史画成一张带分支、带标签的拓扑图，肉眼审阅分支结构非常直观。还有人习惯加--simplify-by-decoration之类的参数，但我觉得基础版已经够了。

以上三件事做完，你才算有一个“正常的”Git 环境。下面进入正题。

2. 日常开发循环：从改代码到提交保存的正确姿势

2.1 用 status 和 diff 建立“改动感知”

在我看来，几乎所有人对 Git 的恐惧都来源于不知道当前仓库处于什么状态。因此第一个要养成的肌肉记忆是：动手改代码之前，先看一眼status。

git status

它告诉你三件事：哪些文件已修改但未暂存，哪些已暂存待提交，哪些是未跟踪的新文件。我见过有人一开始就git add .一把梭，结果把本地的临时文件、日志文件全部提交进去了，不仅污染仓库，还可能在别人拉取后产生路径冲突。正确逻辑应该是：先status看清楚，再决定哪些文件要进版本库。

如果需要看具体的修改内容，用：

git diff # 看工作区与暂存区的差异 git diff --staged # 看已暂存的内容与当前提交的差异

这里的差别很容易搞混。diff看的是你还没add的改动，diff --staged看的是你准备提交的内容。很多新人一直敲git diff，说“我改了代码怎么看不到差异”，其实就是因为已经把文件add了，改看--staged。

2.2 用 add 精确控制提交内容，而不是无脑 add .

git add .是最方便的命令，也是最容易出问题的命令。正确做法是分文件或者分目录地添加：

git add src/utils/format.js git add src/api/user.js tests/api/user.test.js

为什么这么较真？因为一次提交应该只做一件事。如果你同时改了日志工具和用户接口，这两个文件应该拆成两个提交，方便后续单独回滚。据说“提交原子性”是代码评审里最常被提到的词，其实就是这个意思：一条提交可以被理解、可以被解释、可以被回滚而不影响无关内容。

如果你想在提交前快速审查自己的修改，可以先暂存部分文件，再git diff --staged看差异是否合理。这套流程比较适合需要严谨对待变更的场景，比如维护生产仓库。

2.3 提交信息怎么写，才能让队友和你自己看懂

git commit -m "fix bug"这种提交信息我强烈建议不要用。三年后你自己回看历史，一行“fix bug”根本不知道修了什么。写提交信息的技巧是：第一行概括改动，空一行后写具体原因。比如：

git commit -m "fix: 修正订单金额计算溢出问题 浮点累加在极端数据下会出现精度丢失，改为使用整数分单位计算。 Closes #123"

如果你用的是git commit不带-m，Git 会打开编辑器，这样写多行说明更舒服。团队如果强制规范格式（比如 Conventional Commits），那就按团队的来。我自己习惯在信息里附带关联到的 Issue 编号，这样日后看历史可以直接跳转。

2.4 提交之后发现漏了东西怎么办

最常见的场景：刚 commit 完，突然发现少了一个文件，或者想改一行注释再进同一个提交。这时候用：

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

--amend把新改动合并到上一个提交并重写它，--no-edit表示沿用原本的提交信息。要特别注意：不要amend已经推送到远端并被人拉取过的提交。这会让别人的仓库历史和你的历史分叉，产生不必要的合并冲突。只在本地提交上使用，这是原则。

2.5 常用的历史查看命令组合

除了git log --oneline，我比较常用的一招是：

git log --oneline --author="你的名字" -n 20

排查自己最近几天改了什么很方便。还有：

git log -p src/core/engine.js

这个命令会把指定文件每一次提交的差异全部打出来，适合追溯一个模块的演化过程。配合git blame看某一行是谁在什么时候改的，能省去很多“这行代码为什么这么写”的疑惑：

git blame src/core/engine.js -L 85,95

-L指定行号区间，我只对特别可疑的代码段使用，否则输出会太长。

3. 分支管理：合并、变基与冲突解决的实战套路

3.1 switch 和 checkout 到底用哪个

2026 年，官方推荐用git switch做分支切换，用git restore做文件恢复，这两个命令把原来checkout一个命令承担的两种职责拆开了。这样不容易误操作。

git switch feature/login # 切到已有分支 git switch -c feature/payment # 创建并切到新分支 git restore README.md # 丢弃工作区对该文件的修改

对应老命令是git checkout feature/login和git checkout -b feature/payment。都能用，但新命令的语义更清晰。特别提醒一下，switch有一个参数很实用：

git switch - # 切回上一个分支

在几个分支间来回比较时，这一条命令可以省不少事。

3.2 merge 和 rebase 的选择逻辑

这是团队里吵架最多的话题。先说区别。git merge会把两个分支的历史合并成一个新的合并提交，保留两个人各自的分叉记录；git rebase则是把你的提交逐个摘下来，接到目标分支的最新提交后面，得到一条线性历史。

我自己的实践经验是：

• 功能分支为了跟上主分支的最新进度，用rebase更干净，后续合并回主分支时历史是直线。
• 需要保留真实协作痕迹，或者功能分支已经公开共享，别乱 rebase，直接 merge 更安全。

一个典型操作：

git switch feature/login git fetch origin git rebase origin/main

这里fetch再rebase，而不是直接git pull，是为了避免把默认的 merge 行为带进来。

3.3 冲突解决的完整步骤

不管怎么注意，冲突总会出现。我第一次遇到冲突时慌得要命。其实冲突的本质就是 Git 不知道该怎么合并你对某一行和另一个人对同一行的不同修改。处理过程如下：

1. 用git status找到标记为UU或both modified的文件。
2. 打开文件，搜索冲突标记<<<<<<<、=======、>>>>>>>。
3. 手动把内容改成你想要的结果，删除冲突标记。
4. 保存文件，git add这个文件。
5. 继续git rebase --continue或git merge --continue。

如果改到一半觉得不对劲，想回到冲突前的样子：

git rebase --abort

这不是“失败”，而是保护自己不把坏状态提交上去。冲突和解决冲突是日常开发的必修课，多处理几次就会熟练。需要特别留意的是解决冲突时不要顺手把对方的改动全部丢掉，至少看一眼冲突区域上下文的代码。

3.4 用 rerere 记住你的冲突解决方式

git rerere全称是 reuse recorded resolution，即“复用冲突解决”。开启后 Git 会记住你之前解决冲突的方式，下次遇到完全相同的冲突会直接应用。

git config --global rerere.enabled true

这个配置我强烈建议打开。因为在一个大型重构过程里，同一个冲突可能会在 rebase 不同批次提交时反复出现。没有 rerere 的话，你要手动解很多遍一模一样的冲突；开启后，第一次手动解决，后面 Git 自动处理。这是很多老手效率高但从不解释的秘密之一。

3.5 分支清理，保持仓库整洁

合并完功能分支后，把已经合并过的分支删掉：

git switch main git branch --merged git branch -d feature/login # 安全删除本分支 git push origin --delete feature/login # 删除远端分支

git branch --merged先列出所有已经合进当前分支的本地分支，确认无误再删。如果分支有未合并的提交，-d会拒绝删除，这时如果确实要强制删除，用-D。这个保护机制比较有用，可以避免误删工作成果。

4. 远程协作：推送、拉取、撤销的完整方案

4.1 理清 fetch、pull、push 的关系

在团队协作中，最基础也最容易被误解的就是这三个命令。git fetch只是把远端的新提交下载到本地，但不会改动你的工作区和当前分支。git pull等于 fetch + merge（或者 fetch + rebase，取决于配置）。git push则把你本地提交上传到远端。

我建议在需要保持工作区干净时显式使用fetch，然后自己决定是merge还是rebase，而不是直接pull。例如：

git fetch origin git log --oneline HEAD..origin/main

HEAD..origin/main会列出本地没有但远端分支上有的提交，也就是合并前应该审阅的改动。这个操作看得很清楚，能避免盲目pull之后撞上大冲突。

4.2 用跟踪分支关联远端

设置上游分支：

git push -u origin feature/login

-u是--set-upstream的简写。设置之后，在该分支上执行git pull或git push就不需要再带远端名和分支名了。如果 clone 一个仓库，本地会自动把main关联到origin/main，但自己新建的分支必须手动设置一次。

查看本地所有分支的跟踪关系：

git branch -vv

如果某个分支显示[origin/feature/x]，说明跟踪已建立。这对维护多个功能分支的人特别重要。

4.3 拉取时保持线性历史：pull --rebase 的适用场景

如果你在一个公用分支（比如团队每天都在往里合代码的main）上本地还有未推送的提交，执行git pull默认会产生一个 merge 提交。这个提交会把历史变得杂乱。我的习惯是：

git pull --rebase

这会把本地尚未推送的提交临时取下来，拉取远端新提交后，再把本地提交重新放上去。得到的是一条线性历史，回看git log --graph非常干净。

不过要注意一个边界：如果你从来没有把本地提交推送到远端，rebase 一般很安全；只要远端分支上没有别人基于你的旧提交工作过，就随便 rebase。反之，如果这些提交已经被其他人拉取过，rebase 会制造新的分叉，反而更麻烦。

4.4 推送被拒绝怎么办

场景是这样的：你用git push推代码，结果提示! [rejected]。原因通常是远端有比本地更新的提交。此时先git fetch origin再git log --oneline HEAD..origin/main看看远端差异。如果确实只是远端新增了提交，用：

git pull --rebase origin main git push

如果远端已经存在本地会覆盖的分支，但你有意要用本地覆盖远端（比如你正在强行修正一个错误推送的功能分支），才考虑：

git push --force-with-lease origin feature/login

--force-with-lease比--force安全，因为它在推送前会检查远端分支是否跟你上次看到的一致，如果别人已经推了新的提交，它会拒绝覆盖。这个细节很有用——--force会无条件覆盖，而--force-with-lease则在你和队友同时都往这个分支推提交时保护你不误伤别人的工作。

4.5 撤销已经推送到远端的提交

不要在生产环境用git reset去回滚远端分支，因为重置历史会导致别人本地分叉。正确做法是用git revert生成一个反向提交，把“撤销”这件事记录到历史里：

git revert HEAD

这样相当于提交一个新版本，把上一次提交的内容倒回去，历史仍然是一条直线，所有已经拉取过这段代码的同事都能平滑更新。revert能指定任意一个提交，比如：

git revert abc1234

如果只想把某个提交从历史中彻底抹掉（不推荐在共享分支做），才需要git rebase --onto或git filter-repo这类改写历史的手段。

5. 进阶命令：用好这些，才算真正会 Git

5.1 stash：临时挂起工作现场

突然要切到别的分支看一个 bug，但你当前分支改了一半，不想提交。这时候git stash就是救命稻草：

git stash # 默认暂存已跟踪文件的修改 git stash -u # 连未跟踪的新文件一起暂存 git stash list # 查看暂存列表 git stash pop # 恢复最顶上的一份暂存 git stash drop stash@{1} # 删除某一份暂存

我习惯在每次stash之前先用git status检查一下，确认哪些文件会被带进去，避免把调试日志也暂存了。另外，stash有-m参数可以加备注，比如git stash push -m "注册页样式未完成"，多份暂存时非常有用。

踩过的大坑：在git stash pop时如果跟当前工作区冲突，Git 会保留修改但可能有冲突标记，需要手动解一次。别慌，这是保护机制，不是出错。

5.2 reflog：后悔药的仓库

reflog是 Git 的“操作日志”，记录了 HEAD 指针的每一次移动。哪怕你reset到了一个旧提交，或者 rebase 失败重来，只要 reflog 里还能找到那个提交指针，就能找回“丢失”的提交。

git reflog

它会列出类似HEAD@{0}、HEAD@{1}的记录，对应每次操作的新的 commit id。想回到某个状态，就：

git reset --hard HEAD@{2}

但要小心，reset --hard会丢弃工作区里的改动。在此之前，最好先确认是否有未提交的修改，可以git status检查后决定是否先 stash。

我自己真实遇到过：一次 rebase 操作把功能分支的一个提交给弄丢了，团队里没人能记得那个提交的 hash。当时就是靠git reflog找到的，然后用git cherry-pick把它捡回来。可以说 reflog 是最后的防线，但确实是最可靠的。

5.3 cherry-pick：把指定提交复制到其他分支

不需要整条分支合并，只想把某一次提交的改动拿到当前分支，用：

git checkout main git cherry-pick abc1234

这个命令在修复线上 bug 时很常用：你在main上开发了一个修复，测试通过后，需要把同一个修复同步到正在维护的release-2.x分支，此时直接挑拣那个提交过去，而不是把整个 main 合并过去。如果 cherry-pick 过程中遇到冲突，同样是手动解决后git cherry-pick --continue，想放弃就--abort。

5.4 bisect：二分定位引入 bug 的提交

有一个很难排查的问题：功能在一个月前是好的，现在坏了。不知道是哪一次提交引入的。git bisect就是为这种场景设计的。原理很简单：在坏版本标记 bad，在好版本标记 good，然后用二分查找帮助定位第一次出现坏行为的提交。

git bisect start git bisect bad # 当前版本是坏的 git bisect good v2.1.0 # 假定 v2.1.0 是好的

接下来 Git 会切到一个中间提交，你运行测试后告诉它是好还是坏：

git bisect good # 或 git bisect bad

反复几次，最终会定位到那个罪魁祸首提交。对于长期维护的大型仓库，这个命令对排查性能回退和功能异常都非常高效。

5.5 worktree：一个仓库检出多个工作目录

很多人在同时改两个分支时被迫频繁 stash 或 clone 两份仓库。git worktree可以让你在本地一个仓库里，为另一个分支单独创建一个工作目录：

git worktree add ../project-feature feature/login

这样你可以在一个目录里用 main 分支改 bug，在另一个目录里用 feature/login 分支写新功能，互不干扰。切换分支时也不用随身携带“未完成的工作”。用完删除：

git worktree remove ../project-feature

这个功能对前端或者后端这种需要多分支并行开发的场景帮助非常大。

5.6 sparse-checkout：只要仓库的一部分

如果你的仓库很大（比如包含了很多子文件夹），而你只需要其中几个目录，稀疏检出能大幅节省磁盘和拉取时间：

git sparse-checkout init --cone git sparse-checkout set src/config src/utils

设置后拉取只会下载这些目录下的文件。这个功能尤其适合在超大仓库或者 monorepo 里做定向开发。注意稀疏检出不会改变提交历史，只是控制工作区的文件可见性。

5.7 子模块的正确打开方式

子模块是很多团队的心头痛。能用好它的前提是理解：子模块不只是“一个子仓库”，它是父仓库某个提交时点上的一个版本引用。常用命令：

git submodule add https://example.com/path/to/repo.git vendor/some-lib git submodule update --init --recursive git submodule status

需要注意的是，升级子模块后父仓库也会产生一个“指向新版本”的提交，这个提交要单独提交推送。如果你只是修改了子模块内部的文件，父仓库里显示的也是变动状态，需要先在子模块里提交推送，再到父仓库里提交引用更新。顺序反了会导致别人拉下来后子模块处于“分离 HEAD”状态。

5.8 仓库维护：gc、maintenance 与 fsck

大型仓库用久了会出现很多冗余对象，性能下降。Git 自带的垃圾回收虽然会自动触发，但我们可以显式手动执行：

git maintenance start # 启用后台维护 git gc --auto # 自动回收不可达对象 git fsck --no-dangling # 检查仓库对象完整性

git maintenance是 2.30 之后引入的命令，官方推荐用它来做定期优化。另一个容易被忽略的：git fsck检查是否有关联损坏的对象，在备份仓库前做一次，能避免把坏对象备份上去。

6. 高频问题排查速查表

下面这些是我这几年被问得最多的问题，整理成一张表，直接照做就可以。

这张表不是万能药，但覆盖了日常和救急两大场景。如果某条命令的实际效果和你想象的差距很大，先跑git status，再跑git diff，确认你当前处于哪个状态。绝大多数误操作都是因为搞混了工作区、暂存区、本地仓库和远端仓库这四个层面。

7. 我最后想分享的几个小细节

回过头看我这些年用 Git 的经验，最大的改变不是从“会背命令”变成“会查命令”，而是学会了在动手之前先思考当前操作处于 Git 的哪个层面。工作区的修改可以被stash保存，暂存区的内容可以被reset撤销，本地提交可以被rebase重整，远端提交只能被revert或带保护的push --force-with-lease修正。这四层分清楚了，大部分命令你都能推测出用途。

另外，如果你在团队里经常做代码评审，试着要求每一个提交只解决一个问题、每条提交信息能独立被读明白、每个人在合入功能分支前自己先跑一遍git log看清楚将要合入的内容。这些习惯比任何一条高级命令都更能减少事故。我自己从踩过reset --hard丢代码、push --force覆盖队友工作的教训里走出来的经验告诉我：Git 不怕操作多，就怕你不知道自己正在改写什么、影响谁。每一次敲回车之前，花三秒钟在脑子里过一下这句，你的 Git 水平会立刻提高一个段位。