企业官网建设流程全解析

1. 为什么“背命令”这条路从一开始就走不通

刚入行那会儿，我也干过把git常用命令抄在便签纸上贴显示器边框的事。git add、git commit、git push三件套背得滚瓜烂熟，觉得自己已经掌握了版本控制。直到第一次遇到合并冲突，满屏的<<<<<<< HEAD让我盯着终端愣了十分钟，最后靠删掉整个文件夹重新克隆才把活干完。那次之后我才明白，git指令大全这种东西，如果只是罗列命令和参数，那跟背字典没什么区别——你记住了rebase这个单词，但根本不知道什么时候该用它、用了之后会发生什么、出了问题怎么退回来。

这篇内容想聊的，不是再给你一份冷冰冰的命令清单。网上随便一搜，git命令列表能拉出几百行，参数说明比官方文档还长。但真正干活的时候你会发现，卡住你的从来不是“不知道有这个命令”，而是“不知道现在这个局面该用哪个命令、用了之后仓库会变成什么样、搞砸了怎么救”。所以我打算换个思路，按实际工作场景来拆——你遇到什么问题，该用什么工具，背后的逻辑是什么，以及我踩过的那些坑。

适合谁看？如果你已经会基本的add、commit、push，但遇到分支合并、历史修改、误操作恢复这些事就心里发虚，那这篇内容就是写给你的。如果你完全没接触过git，建议先找个沙盒仓库把基础流程跑一遍再回来，不然有些场景你很难有体感。全文会涉及大量命令，但重点永远在“为什么”和“什么时候”上，而不是“这个参数有几个取值”。

提示：下面所有操作，建议都在一个专门用来折腾的测试仓库里先跑一遍。git的大部分操作在本地是可逆的，但涉及push --force和reset --hard的时候，手滑的代价可能是几小时的活白干。

2. 仓库初始化与日常提交：那些没人告诉你但天天在用的细节

2.1git init之后第一件事不是写代码

很多人git init完就急着git add .，然后git commit -m "init"。这个流程本身没错，但漏了一步：确认你的忽略规则。我见过太多仓库因为一开始没配.gitignore，把node_modules、__pycache__、.DS_Store甚至本地配置文件全提交进去了。等到发现的时候，这些文件已经在历史里躺了几十个提交，想清理就得动filter-branch或者filter-repo，那复杂度直接上一个量级。

正确的顺序应该是：git init→ 创建.gitignore→ 写几行代码 →git add→git commit。.gitignore的语法不复杂，但有几个容易忽略的点。比如*.log会忽略所有目录下的日志文件，但!important.log可以把它排除在外；build/忽略整个目录，而build不加斜杠会同时匹配文件和目录。还有一个坑：如果你已经git add了某个文件，再把它加进.gitignore是不生效的，得先用git rm --cached <file>把它从暂存区拿掉。

# 典型的 .gitignore 开头 node_modules/ dist/ *.log .env .DS_Store

2.2git add的三种粒度和一个后悔药

git add最常用的形式是git add .和git add <file>，但实际工作中经常遇到“我只想提交这个文件里的一部分改动”的情况。比如你改了一个配置文件，里面既有格式调整又有功能变更，想分成两个提交。这时候git add -p就是神器。它会逐个代码块问你“要不要暂存这一段”，你可以按y暂存、n跳过、s把大块拆成更小的块、e手动编辑。我第一次用的时候觉得这操作太 geek 了，但用过几次之后就离不开了，因为它能让你的提交历史干净得像教科书。

另一个容易忽略的是git add -u。它只暂存已经被跟踪的文件的修改和删除，不会把新文件加进去。这个在你想“只提交对已有文件的改动，先不管新写的草稿”时特别有用。

至于后悔药，git restore --staged <file>可以把文件从暂存区撤回到工作区，但保留你的修改。注意这个命令在旧版本里叫git reset HEAD <file>，现在两种写法都支持，但restore语义更清晰。

2.3git commit的信息不是写给现在的你看的

我见过太多commit message写“fix bug”、“update”、“修改”的仓库。这种提交历史，三个月后连作者自己都看不懂。好的提交信息应该回答两个问题：这个提交做了什么，以及为什么这么做。格式上我习惯用“动词开头 + 简短描述”作为标题行，空一行，然后写详细说明。比如：

修复用户登录时 token 过期未刷新的问题 之前的逻辑是在请求拦截器里判断 401 后直接跳转登录页， 但这样会丢失用户当前的操作上下文。现在改为先尝试刷新 token，刷新失败再跳转，并在跳转前保存当前路由。

git commit还有一个--amend参数，用来修改最近一次提交。这个在“提交完发现漏了一个文件”或者“提交信息打错字”的时候非常方便。但要注意：如果这次提交已经推送到远程，amend之后推送需要强制覆盖，在多人协作的分支上要格外小心。

2.4git status和git diff的组合拳

git status告诉你哪些文件变了，git diff告诉你具体变了什么。但很多人不知道git diff有几个变体：git diff看工作区和暂存区的差异，git diff --staged看暂存区和最后一次提交的差异，git diff HEAD看工作区和最后一次提交的差异。这三个的区别在提交前检查的时候特别重要——你git add之后想确认“我到底暂存了什么”，就得用--staged。

还有一个实用技巧：git diff --stat只显示每个文件的改动行数统计，不显示具体内容。在改动文件很多的时候，先看一眼统计，再决定要不要细看某个文件。

3. 分支与合并：从“不敢切分支”到“随便切”的跨越

3.1 分支的本质是一个可移动的指针

很多人对分支有心理负担，觉得“切分支”是个大动作。其实在git里，分支就是一个指向某个提交的指针，创建和切换的成本极低。git branch <name>创建一个新分支，git switch <name>切过去，整个过程在本地瞬间完成，不涉及任何网络操作。理解这一点之后，你就会明白为什么git鼓励“每个功能开一个分支”——因为成本几乎为零。

git switch是较新的命令，旧版本里用git checkout。两者的区别在于checkout还能用来恢复文件，语义太杂，所以后来拆出了switch和restore。如果你用的是比较新的git版本，建议养成用switch的习惯。

# 创建并切换到新分支 git switch -c feature/login # 查看所有分支（包括远程） git branch -a # 删除已合并的分支 git branch -d feature/login # 强制删除未合并的分支（慎用） git branch -D feature/login

3.2merge和rebase的选择不是信仰问题

关于merge和rebase的争论，网上能吵出几千楼。我的看法是：它们解决的是不同的问题，没有绝对的好坏。merge会创建一个新的合并提交，保留完整的分支历史；rebase会把你的提交“搬”到目标分支的最新提交之后，历史变成一条直线。

什么时候用merge？当你想保留“这个功能是在某个时间点从主分支分出去开发的”这个信息时。什么时候用rebase？当你想让提交历史更干净、更容易阅读时。我个人的习惯是：在本地开发分支上，用rebase同步主分支的更新；在把功能分支合入主分支时，用merge --no-ff保留合并记录。

rebase有一个黄金法则：不要对已经推送到远程的公共分支做rebase。因为rebase会重写提交历史，别人基于旧历史做的工作会对不上。如果你rebase了公共分支，别人拉取的时候就会遇到一堆莫名其妙的冲突。

3.3 冲突不是灾难，是信息

合并冲突的本质是：git不知道你想保留哪边的改动。它把两边的代码都标出来，让你自己决定。冲突标记长这样：

<<<<<<< HEAD 这是当前分支的代码 ======= 这是要合并进来的分支的代码 >>>>>>> feature/other

解决冲突的步骤很直接：找到所有冲突标记，决定保留哪部分（或者两部分都保留但调整顺序），删掉标记行，然后git add标记为已解决。但实际工作中，冲突往往比这复杂——可能涉及十几个文件，每个文件里有多处冲突。这时候git status会列出所有冲突文件，git diff可以看具体冲突内容。

我踩过的一个坑是：解决完冲突后忘了git add，直接git commit，结果git提示还有未解决的冲突。后来才知道，git add这个动作不仅是暂存，也是在告诉git“这个文件的冲突我已经处理完了”。

3.4cherry-pick：只想要那一个提交

有时候你在一个分支上做了五个提交，但只想把其中一个搬到另一个分支。这时候git cherry-pick <commit-hash>就派上用场了。它会把这个提交的改动“复制”到当前分支，生成一个新的提交。这个命令在“紧急修复要同步到多个版本分支”的场景下特别有用。

但cherry-pick也有坑：如果目标分支已经包含了这个提交的改动（比如之前合并过），cherry-pick会产生冲突或者空提交。另外，cherry-pick出来的提交和原提交的哈希值不同，所以如果后续要合并原分支，可能会遇到重复改动的问题。

4. 历史修改与误操作恢复：那些让你心跳加速的时刻

4.1reset的三种模式：软、混合、硬

git reset是误操作恢复的核心工具，但它有三个模式，用错了后果不同。--soft只移动HEAD指针，暂存区和工作区都不动；--mixed（默认）移动HEAD并重置暂存区，但工作区不动；--hard三者全重置，工作区的修改直接丢失。

# 撤销最近一次提交，但保留改动在暂存区 git reset --soft HEAD~1 # 撤销最近一次提交，改动留在工作区（未暂存） git reset HEAD~1 # 彻底丢弃最近一次提交和所有改动（危险） git reset --hard HEAD~1

我个人的经验是：--soft和--mixed可以随便用，因为改动还在，最多重新提交一次。但--hard一定要在确认工作区没有未提交的重要改动时再用。如果不小心--hard了，还有一个救命稻草：git reflog。

4.2reflog：你的时间机器

git reflog记录了HEAD的每一次移动，包括提交、重置、合并、切换分支等等。即使你reset --hard删掉了提交，只要reflog里还有记录，就能找回来。用法很简单：git reflog看列表，找到你想回到的那个状态对应的哈希值，然后git reset --hard <hash>或者git cherry-pick <hash>。

但reflog不是永久的。默认情况下，git会保留 90 天的reflog记录，过期会被清理。所以如果误操作之后过了很久才发现，可能就找不回来了。另外，reflog是本地记录，不会随着push同步到远程。

4.3stash：临时保存工作区

正在写一个功能，突然来了个紧急 bug 要修，但当前代码还没写完不想提交。这时候git stash可以把工作区和暂存区的改动“存起来”，让工作区回到干净状态。修完 bug 提交后，再用git stash pop把改动恢复回来。

stash有几个实用参数：git stash -u会把未跟踪的文件也存起来；git stash list查看所有 stash 记录；git stash apply stash@{2}恢复指定的 stash 但不删除记录；git stash drop stash@{2}删除指定记录。我习惯用apply而不是pop，因为pop在恢复失败时可能会让 stash 记录消失，而apply更安全。

4.4 恢复被删除的文件和提交

如果误删了一个文件还没提交，git restore <file>可以从最后一次提交里恢复。如果已经提交了删除操作，可以用git revert <commit>创建一个“反向提交”来撤销删除。revert和reset的区别在于：revert不修改历史，而是新增一个提交来抵消之前的改动，所以在公共分支上更安全。

还有一种情况：你不小心把某个分支删了，但那个分支上有还没合并的提交。如果记得分支名，可以用git reflog找到分支最后一次指向的提交，然后git branch <name> <hash>重建分支。

5. 远程协作：推送、拉取与那些让人抓狂的报错

5.1push被拒绝的三种常见原因

git push被拒绝是新手最常遇到的挫败之一。报错信息通常长这样：! [rejected] main -> main (non-fast-forward)。原因很简单：远程分支有你本地没有的提交，git不允许你直接覆盖。解决办法是先git pull把远程改动拉下来合并，再push。

但pull本身也可能出问题。如果本地有未提交的改动，pull会报错说“Your local changes would be overwritten”。这时候要么先stash，要么先commit。我个人的习惯是：在pull之前永远保持工作区干净，要么提交要么 stash，这样能避免很多不必要的麻烦。

还有一种拒绝是权限问题，报错里会出现Permission denied或403。这通常意味着你没有目标仓库的写权限，或者认证信息过期了。检查一下远程地址和凭证配置。

5.2fetch和pull的区别

git fetch只把远程的改动下载到本地，但不合并到当前分支。git pull等于fetch+merge（或者rebase，取决于配置）。我推荐在pull之前先fetch看一眼远程有什么变化，比如git fetch origin然后git log HEAD..origin/main --oneline看看多了哪些提交。这样心里有数之后再决定是merge还是rebase。

git pull --rebase是很多人喜欢的配置，它会把你的本地提交“搬”到远程最新提交之后，保持历史直线。但这个操作在本地有未推送的合并提交时可能会出问题，所以用之前最好确认一下本地历史。

5.3 远程分支的跟踪与清理

git branch -vv可以查看本地分支和远程分支的跟踪关系。如果某个本地分支没有对应的远程分支，或者跟踪关系断了，可以用git branch -u origin/main重新设置。远程分支被删除后，本地的origin/main引用不会自动消失，可以用git remote prune origin清理掉那些已经不存在的远程分支引用。

还有一个场景：你push了一个新分支，但后来发现名字打错了，想删掉远程分支。命令是git push origin --delete <branch-name>。注意这个操作在有些仓库配置下可能被保护规则阻止，需要管理员权限。

5.4 多人协作时的提交策略

在多人协作的分支上，我强烈建议养成“先拉后推”的习惯。每次push之前先pull --rebase，把自己的提交放到最新代码之后。这样能最大程度减少合并提交，让历史更干净。如果遇到冲突，在本地解决完再推，而不是把冲突推给别人。

另外，功能分支的生命周期不要太长。一个分支如果活了两周还没合并，大概率会和主分支产生大量冲突。我习惯把大功能拆成小提交，分多次合并，每次合并的冲突量都可控。

6. 排查问题的固定套路：从“懵了”到“有章法”

6.1 先看状态，再看差异，最后看历史

遇到任何git问题，我的第一步永远是git status。它会告诉你当前在哪个分支、有哪些改动、有没有冲突、有没有未跟踪的文件。第二步是git diff或git diff --staged，确认具体改了什么。第三步是git log --oneline -10，看看最近的提交历史，确认HEAD的位置对不对。

这三步能解决大部分“不知道发生了什么”的情况。比如你发现代码莫名其妙变了，git status显示某个文件被修改了，git diff一看是编辑器自动格式化的结果，那就git restore掉。再比如你发现提交历史里多了一个不认识的提交，git log一看是同事推上来的，那就正常拉取合并。

6.2 用git bisect定位引入 bug 的提交

git bisect是一个被严重低估的工具。它的原理是二分查找：你告诉它一个“好”的提交和一个“坏”的提交，它会自动切换到中间的那个提交，让你测试，然后根据结果缩小范围，直到找到第一个引入问题的提交。

git bisect start git bisect bad # 当前版本有问题 git bisect good abc1234 # 这个版本是好的 # git 会自动切换到中间提交，测试后标记 good 或 bad git bisect good git bisect bad # 重复直到找到问题提交 git bisect reset # 结束二分查找

这个工具在排查“某个功能之前好好的，最近突然坏了”这类问题时特别高效。如果提交历史有几百个提交，手动一个个试要疯掉，bisect只需要 log2(N) 次测试。

6.3git blame不是用来甩锅的

git blame <file>会显示每一行代码最后是被哪个提交修改的。很多人把它当成“甩锅工具”，但其实它的真正用途是理解代码的演变。比如你看到一行奇怪的代码，blame一下发现是两年前为了兼容某个旧版本加的，现在那个版本已经不用了，就可以放心删掉。

git blame -L 10,20 <file>可以只看某几行的归属。git blame -w会忽略空白改动，避免格式化提交干扰视线。这些参数在排查历史遗留问题时很实用。

6.4 常见报错速查表

7. 把git用成肌肉记忆的几个习惯

7.1 别名配置：让常用命令少敲几个字

git允许给命令配别名，配置写在~/.gitconfig里。我常用的几个：

[alias] st = status -sb co = switch br = branch -vv lg = log --oneline --graph --decorate -20 last = log -1 HEAD --stat unstage = restore --staged amend = commit --amend --no-edit

git lg是我用得最多的，它用图形化方式显示最近 20 个提交的分支结构，一眼就能看出合并关系。git st比git status输出更紧凑，适合快速查看。

7.2 提交前的自检清单

在git commit之前，我习惯跑一遍这个清单：git status确认没有多余文件、git diff --staged确认暂存内容符合预期、git log -1确认上一次提交信息格式正确。这个习惯帮我避免了很多“提交了不该提交的文件”或者“提交信息写错”的尴尬。

还有一个细节：如果项目有pre-commit钩子（比如代码格式化、lint 检查），确保它正常运行。有时候钩子失败会导致提交被阻止，但报错信息可能被忽略。我见过有人反复commit失败却不知道是钩子在报错，最后发现是代码里有语法错误。

7.3 定期清理和整理

本地分支太多的时候，git branch的输出会变得很长。我习惯每周清理一次已经合并的分支：git branch --merged | grep -v main | xargs git branch -d。这个命令会删除所有已经合并到当前分支的本地分支，但保留main。

远程分支的清理用git remote prune origin，它会删除本地缓存的、远程已经不存在的分支引用。这个操作不会影响远程仓库，只是清理本地的引用列表。

7.4 遇到问题先别搜，先看git自己怎么说

很多人遇到git报错的第一反应是打开搜索引擎。但其实git的报错信息通常已经包含了解决思路。比如non-fast-forward的报错里会提示你先pull；冲突报错会列出冲突文件；权限报错会提示你检查认证。花十秒钟读完报错信息，往往比搜十分钟更有效。

如果报错信息太长看不完，可以只看最后几行，那里通常是关键提示。或者用git <command> --help查看该命令的完整文档，里面会有常见问题的说明。

7.5 保持学习：git的进阶工具

当你把基础命令用熟之后，可以了解一下git worktree（同时检出多个分支到不同目录）、git submodule（嵌套仓库管理）、git hooks（自动化脚本）这些进阶功能。它们不是日常必需，但在特定场景下能大幅提升效率。

比如git worktree允许你在同一个仓库里同时检出多个分支到不同文件夹，这样你可以在一个目录里写功能，另一个目录里修 bug，不用来回切换分支。这个功能在“紧急修复和日常开发并行”的时候特别有用。

最后分享一个我自己的体会：git的命令有几百个，但日常工作中真正高频使用的也就二三十个。把这二三十个用熟、用透，理解它们背后的逻辑，比背下所有命令更有价值。遇到没见过的问题，git的文档和reflog通常能给你兜底。真正让你从容的，不是记住了多少命令，而是知道出了问题该从哪里开始查。