企业官网建设流程全解析

1. 仓库初始化与基础配置

1.1 从零开始：先想清楚“这个仓库到底给谁用”

别急着敲命令。我见过太多人一上来就git init，提交了几次之后才发现用户名是全球默认值，提交记录里挂着一个“unknown”，或者仓库里混进了node_modules、日志文件、密钥文件这些不该提交的东西。Git 这东西最大的特点是：写错的提交历史，虽然能改，但改起来远比第一次做对要费事得多。

所以在初始化之前，先花 30 秒回答三个问题：

• 这个仓库是个人项目还是多人协作？
• 代码托管平台用的是哪一家（GitHub、GitLab、Gitee 还是公司内网）？
• 仓库里会不会有不该进版本管理的文件？

回答完这几个问题，下面这些命令才算是真正“对症”的操作：

# 初始化仓库，显式指定默认分支名 git init -b main # 如果 Git 版本较老（低于 2.28），先改默认分支名 git init git branch -m main

为什么要指定main而不是默认的master？不是政治正确问题，而是所有主流托管平台现在都以main作为新建仓库的默认分支。如果你本地是master，推送到远端时要多写一句-u origin master，别人拉下来一看分支名对不上，也容易造成困惑。既然能用一条命令消除未来所有分支命名的不一致，那就没必要省这一步。

然后配置用户信息。这一步很多人以为是“可选项”，实际上它是 Git 正常工作的前提。我在这条路上踩过坑：某次在公司电脑上提交代码，因为之前这台电脑的全局配置被某个老旧脚本污染了，提交出来的 author 信息是一串乱码，后果是 CI 系统直接把提交人判定成了机器人，导致代码审查流程直接卡死，后来花了大半天才把所有提交历史修复干净。

# 全局配置只做一次 git config --global user.name "你的名字" git config --global user.email "你的邮箱" # 检查当前项目配置 git config --local user.name git config --local user.email # 一次性打开配置文件查看所有项 git config --list

需要说明的是：--global配置在个人电脑上没问题，但如果是公司配发的电脑，我偏向用--local覆盖为项目内专用。原因很简单，多个项目的账号可能不一样，全局配置一旦设错，多个仓库同时受影响，排查起来非常耗费时间。

1.2 补齐忽略规则：这一步不做，后面全是坑

gitignore文件的价值在初始化阶段完全看不出来，但提交几次之后就明白了：某天你正要提交一段新代码，一git status发现满屏都是node_modules的文件路径，或者.env这种带密钥的文件就静静躺在待提交列表里。这时候没人帮你兜底，如果一时疏忽把密钥提交上去了，那几乎等于给所有能看到这个仓库的人发了一张服务器通行证。

我第一次带新人的时候遇到过类似的事故：对方把数据库连接串写进了配置文件，然后连着密钥一并提交到了仓库，等发现时已经推送到了远端。虽然最后通过历史重写清掉了记录，但这期间仓库一直处于风险暴露状态，光是通知所有协作者重新克隆、处理本地残留就折腾了一整天。

所以初始化的同时就要准备好.gitignore：

# 创建项目根目录下的 .gitignore touch .gitignore

不同语言、不同框架的忽略规则差异很大，我把自己常用的一个基础版本贴在下面，它覆盖了最常见的几类垃圾文件：

# 依赖目录 node_modules/ vendor/ # 构建产物 dist/ build/ target/ *.class # 日志和临时文件 *.log *.tmp .DS_Store # IDE 配置 .idea/ .vscode/ *.iml # 环境变量与密钥 .env .env.* *.pem *.key # 测试覆盖率 coverage/

这里有一个容易忽略的细节：.env和.env.*之间的区别。有些项目需要保留.env.example给其他开发者做参考，这个文件恰恰需要提交上去，所以如果把规则写成.env*，会连示例文件一起忽略掉，反而给想接手项目的人添了麻烦。我一般会先写.env和.env.*，再单独加一行!.env.example（比如这样）：

.env .env.* !.env.example

另外提醒一句：.gitignore只对“尚未被 Git 跟踪的文件”生效。如果你在补忽略规则之前已经把node_modules或者别的什么大文件git add进暂存区了，那光改.gitignore是拦不住它们的，得先用下面的命令把它们从索引里移出去：

git rm -r --cached node_modules

--cached的意思是只把文件从 Git 索引里删掉，但保留在本地磁盘上。这一步做完之后，再执行git add .，忽略规则就真正生效了。

2. 日常提交与分支管理实战

2.1 提交的基本循环：add、commit、pull、push 的先后顺序

很多人觉得git add、git commit、git push是三个机械动作，背下来就行。但真正干活的时候，这个顺序里有个关键的隐藏步骤：push 之前先 pull——准确说是 push 之前先“同步”，哪怕你觉得自己在这个项目上是唯一一个开发者。

为什么？因为即使是你一个人维护的仓库，你也不可能保证自己在另一台电脑上没有提交过代码。更常见的情况是：你前天上半夜在家里电脑上改了一版推了上去，第二天到公司忘了这件事，公司电脑上还留着旧代码，你改完直接git push，远端直接报错Non-fast-forward，因为 Git 看到你的本地历史里缺少了家里那台电脑上的那次提交。

解决这个问题的最佳路径是：

# 先看一眼工作区状态 git status # 把改动放进暂存区（按模块分开提交，尽量不要一个 add 全带走） git add src/components/button.js git add src/utils/format.js # 写一个能说明问题的提交信息 git commit -m "重构按钮组件的样式逻辑，新增点击态" # 拉取远端改动，用 rebase 方式保持历史线性 git pull --rebase # 如果没有冲突，推送即可 git push

这里我需要单独解释一下git pull --rebase到底做了什么，以及为什么我推荐它而不是默认的git pull。

默认的git pull相当于执行git fetch加git merge，它会创建一个新的 merge commit，把两边的历史打成一个结。短期看问题不大，但一旦大量协作者都走这个方式，仓库历史会长出一堆密密麻麻的分叉和合并节点，后续用git log --graph查看演进过程时会非常吃力。而--rebase做的事情是：把你本地那些“还没推上去”的提交，先摘下来，等远端的提交全部落地之后，再把你的提交一次性重放到最新位置上方。这样历史就是一条直线，读起来非常干净。

但 rebase 有它的禁忌：永远不要 rebase 已经推送出去的提交。这句话记一辈子。自己本地还没 push 的提交随便 rebase，已经 push 到远端且别人可能已经基于它开发的提交，一旦 rebase 会重写哈希值，别人的本地历史会跟远端对不上，严重的甚至会直接把伙伴的开发环境搞成一团乱麻。

那有人在群里问我：“不能 rebase，又不想 merge 出一堆分叉，怎么办？”我的回答是：如果这是一次早已预期到的多人协作，让每个人在完成一个功能后主动 rebase 到最新main，体验会好很多。相反，如果你们团队习惯用 merge 保留功能分支的原貌，那从一开始就要统一，不要让几个人用 rebase，另外几个人用 merge，那才会真正制造混乱。

2.2 分支管理：什么时候开分支，开完了怎么合回来

分支不是越多越好。我见过有些新人特别喜欢每写一个小功能就开一个feature/xxx分支，结果是分支列表里躺着几十个分支，经常连自己都分不清哪个合并过了、哪个已经废了。

不会有统一答案适用于所有团队，但我自己遵循这么几条规则：

• 任何持续超过一天的开发工作，绝不直接在main上做。
• 分支命名遵循<type>/<description>格式，例如feature/user-login、fix/edge-case-null、chore/upgrade-validator。这样别人一眼就能从名字里知道这个分支在干嘛。
• 合并策略看场景：
  • 简单的功能、时间短的改动，用git merge --squash，把所有提交压缩成一个，历史非常精简。
  • 一个需要长期维护的大功能、需要保留完整演进脉络的，老老实实git merge --no-ff，保留一个明确的合并节点。

摘一段我平时在功能分支快要收尾时的操作序列：

# 切到功能分支 git checkout feature/user-login # 确保功能分支已包含 main 上的最新改动，避免合并时一次性冒出太多冲突 git fetch origin git rebase origin/main # 切回主干 git checkout main # --no-ff 表示强制生成合并提交，方便以后回滚整个功能 git merge --no-ff feature/user-login # 推送 git push origin main

这里有两点值得解释。

git merge --no-ff的作用是生成一个明确的 merge commit，即使这个分支的所有提交可以按快进方式直接移动，它也坚持留一个合并节点。好处是：万一这个功能要整体回滚，只需要git revert这一个 merge commit 就能把整个功能撤掉，而不是一个个找散落的小提交；坏处是历史中会多一个“空”节点。我不会说--no-ff永远优于 fast-forward，但我个人在做大型功能时更偏好--no-ff，因为它让“功能边界”在历史中清晰可见。

还有一个操作叫git branch -d feature/user-login和git branch -D feature/user-login的区别。合并完后想清理本地分支，用-d检查；如果某个分支已经不要了，而且没合并过，用-D强制删。我见过有人用-D误删了还没合并到主干的整条分支，导致几天的工作直接蒸发，所以每次执行删除类命令前务必要三思——如果你的工作成果只存在于这个分支，删了就真没了。

顺带一提，git stash在这种情况下也能救急。如果你手上改到一半的代码还没写好 commit，突然需要切去修一个线上 bug，可以这样做：

git stash push -m "按钮组件样式未完成" git checkout -b hotfix/urgent-bug # ... 修复并提交 ... git checkout feature/user-login git stash pop

stash的本质是：把当前工作区和暂存区的改动保存到一个独立的栈里，然后把工作区恢复干净。stash pop会把栈顶的改动重新应用回来。需要注意的点是：如果 pop 时工作区已经有改动，并且两处改的是同一个文件的同一行，Git 会直接拒绝，并提示冲突。此时你也别慌，找到冲突文件手动解决后git add即可。

2.3 push 与 fetch：远端同步的两个层次

有些 Git 新手会把git pull和git fetch画上等号，这是不对的。简单说：

• git fetch只把远端的最新提交和分支状态下载到本地，但不改变你的工作区内容。
• git pull等于fetch + merge（或fetch + rebase，取决于命令参数），它会直接修改工作区。

在动手干大活之前，比如你要做一次大规模重构，我的建议是：先git fetch，看一看远端发生了什么变化，然后再决定是用 rebase 还是 merge 来整合，而不是直接一个git pull让 Git 替你选择合并策略。

# 将远端所有分支状态拉到本地 git fetch origin # 看看本地相对远端 main 超前/落后多少 git log --oneline main..origin/main git log --oneline origin/main..main

这两条git log命令很有用：第一条列出“远端有但本地没有”的提交，第二条列出“本地有但远端没有”的提交。只要跑一次这两个命令，双方分叉情况一目了然，再结合git log --graph --oneline --all看分叉图，心里就有底了。

另外，推送到远端时常用的-u参数值得解释一下。git push -u origin main中的-u全称是--set-upstream，意思是把本地分支和远端分支的关联关系写进配置。这个关系记录在.git/config文件里，设置一次之后，以后直接git push、git pull就能自动匹配到关联的远端分支，不必每次重复输入完整参数。很多人第一次 push 时不带-u，也能推送成功，但下次再 push 时 Git 会提示“当前分支没有上游分支”，还得手动搭一次桥，白白浪费时间。

3. 冲突解决全流程演示

3.1 冲突到底是怎么产生的：从代码行的维度看本质

先说结论：Git 的合并逻辑是“基于行”的。它比对两个版本中每一行的变更，如果两边改的是完全不同的文件，那很好办，各自共存就行；如果改的是同一个文件的不同区域，Git 也会自动合并，因为它们互不影响。只有当两个分支里的提交修改了同一个文件的同一处位置，且两边对这个位置给出了不同的新旧内容时，Git 才无法自行判定，于是抛出冲突。

举个例子，一张config.js文件里有一行：

export const timeout = 3000;

A 在上面改成了：

export const timeout = 5000;

B 在同一行改成了：

export const timeout = 8000;

当 A 先被合并进主干，随后轮到 B 的合并时，Git 就懵了：newer 版本中的这一行原来是3000，A 把它改成了5000，B 又把它改成了8000，那到底按哪个来？这种二义性 Git 无法判断，只能把决定权交还给人。

另一种更常见的情况是：A 在main分支上删除了一段代码块，B 在功能分支上恰好也要修改这段代码块。删改冲突同样会被视为同一处位置的差异。此时 Git 给出的不是代码行级别的合并结果，而是把这个文件标记成“both modified”，需要你手动决定保留哪一方、改动哪一方、还是两者都删。

3.2 完整走一遍：制造冲突、发现冲突、解决冲突

我干脆用一个演示性的场景来复现整个过程。假设这是一个网页项目，大家一起维护src/utils.js，初始状态是这样的：

export function formatDate(date) { return date.toISOString().slice(0, 10); }

我和另外一位同事分别基于不同的分支改了同一个函数。

同事的分支（feature/date-format-pretty）把它改成了带中文格式的版本：

export function formatDate(date) { const y = date.getFullYear(); const m = String(date.getMonth() + 1).padStart(2, '0'); const d = String(date.getDate()).padStart(2, '0'); return `${y}年${m}月${d}日`; }

我的分支（feature/date-format-us）把它改成了带英文形式的版本：

export function formatDate(date) { const options = { year: 'numeric', month: 'short', day: 'numeric' }; return date.toLocaleDateString('en-US', options); }

两个分支基于同一个初始 commit 分道扬镳，现在我要把同事的分支合并进我的分支，或者反过来。我选择把同事的分支合并到我当前所在分支：

git checkout feature/date-format-us git merge feature/date-format-pretty

Git 立刻提示：

Auto-merging src/utils.js CONFLICT (content): Merge conflict in src/utils.js Automatic merge failed; fix conflicts and then commit the result.

打开src/utils.js文件，会看到这样的冲突标记：

<<<<<<< HEAD export function formatDate(date) { const options = { year: 'numeric', month: 'short', day: 'numeric' }; return date.toLocaleDateString('en-US', options); } ======= export function formatDate(date) { const y = date.getFullYear(); const m = String(date.getMonth() + 1).padStart(2, '0'); const d = String(date.getDate()).padStart(2, '0'); return `${y}年${m}月${d}日`; } >>>>>>> feature/date-format-pretty

这三段标记的含义是：<<<<<<< HEAD到=======之间的部分，是当前分支（我自己的分支）上的内容；=======到>>>>>>> feature/date-format-pretty之间的部分，是对方分支上的内容。别理解反了，这是新人最容易搞反的地方。

接下来我需要决定这个文件最终长什么样。假设这个项目本来就是面向中文用户的，所以我决定采用同事的中文格式版本，但保留我这边对toLocaleDateString的考虑，最终手改成这样：

export function formatDate(date) { const y = date.getFullYear(); const m = String(date.getMonth() + 1).padStart(2, '0'); const d = String(date.getDate()).padStart(2, '0'); return `${y}年${m}月${d}日`; }

删除所有冲突标记，保存后执行：

git add src/utils.js git commit -m "合并同事的中文日期格式实现"

这样一次完整的冲突解决流程就结束了。核心口诀是：冲突标记删干净，双方内容按需保留，最终文件确定后 add 再 commit。

3.3 高效解决冲突的三条经验法则

冲突这个东西，解决多了就有经验，我总结三条规律：

第一条，冲突越晚爆发越难搞。如果你知道自己要做一个持续好几天的功能，尽早把主干的最新改动合进来。比如每天上班第一件事就是git fetch origin、git rebase origin/main。这样每次面对的冲突范围都小，而且因为上下文都在脑子里，解决起来很快。如果拖到最后才一次性合并，动辄几百行的冲突标记会堆成一座小山，到那时候谁也不敢说自己有把握在两小时内不踩坑地解决掉。

第二条，能用工具辅助就不用手搓。推荐普通开发者至少学会一个可视化合并工具，比如 VS Code 自带的合并编辑器（GitLens 也强烈推荐）、SourceTree、Fork 等。但要注意，工具只是辅助呈现，真正做决定还是人。从实际操作来看，我在 VS Code 的冲突编辑器里看到HEAD和feature/xxx两边内容并排显示，选择“Accept Current Change”“Accept Incoming Change”“Accept Both”都是即时生效的，比手改冲突标记直观得多。但如果你在终端环境（比如服务器上）操作，没有 GUI 可用，那手改标记就是基本功，必须熟练。

第三条，遇到二进制文件冲突（图片、压缩包、Excel）时别想太多。Git 根本没法自动合并二进制文件，它只有一个选择：用当前分支版本或对方分支版本。你需要在冲突文件处确认最后一版应该是哪个版本，然后直接选择覆盖。这类冲突没有手写合并的可能。

一条最不爱听但最真实的经验是：如果某个文件频繁出现冲突，而且每次都是同一个区域，那大概率是你们的模块拆分不够干净。两个人长期改同一个函数、同一个配置文件，说明零件的边界不清晰，这不是 Git 的问题，这是架构的问题。用 Git 触发的痛来反推模块设计，比单纯怪自己手速不够快要有价值得多。

4. 回滚与撤销的完整方案

4.1 三条后悔药：checkout、reset、revert，别用错

“回滚”这个词在 Git 语境下其实是一个很宽泛的需求集合。不同阶段、不同状态下，该用的命令完全不同。我把它们分成三类场景来说明，这样会更容易对上号：

第一类：文件还没 add 到暂存区（工作区脏了，或者想丢弃某个文件的改动）。

# 丢弃单个文件的全部本地改动 git checkout -- src/utils.js # 丢弃所有本地改动（危险操作，慎用） git restore .

这条命令的本质是：用暂存区里的版本（或者说最近一次 commit 里的版本）覆盖工作区的文件。一旦执行，你在这个文件上做的所有未提交修改都会永久消失，没有后悔药可吃。

第二类：文件已经 add 进了暂存区，但还没 commit（想撤回git add操作）。

# 把文件从暂存区撤回，工作区保持现状 git restore --staged src/utils.js

或者老一点的语法：

git reset HEAD src/utils.js

这个操作的便利之处在于，它可以保留你对文件的修改，只是让这些修改不再处于 staged 状态。很多人在git add之后突然发现误加了一个不该加的文件，用这个命令就能把文件退回“尚未 add”的状态，安全且不损失任何内容。

第三类：已经 commit 了，想撤销这次提交。这里有两个方向完全不同的命令：

# 方式一：git reset 会移动 HEAD，并把提交历史抹掉重来 git reset --hard HEAD~1 # 丢弃最近一次提交以及所有改动，危险！ git reset --soft HEAD~1 # 丢弃提交，但保留改动到暂存区，安全 # 方式二：git revert 会创建一个新的反向提交，历史永不重写 git revert HEAD

这两者之间的区别，值得展开说说，因为搞懂它们才能正确选型。

git reset --hard是把 HEAD（当前分支指针）往回移，同时把工作区和暂存区里的内容也一切都恢复到那个历史时间点的状态。但危险点在于：这条命令会彻底丢弃目标提交及之后的所有本地改动。如果那部分改动还没推送给任何人，那还好，你在本地完成了一次“时间旅行”；如果已经推送出去了，不要在公共分支上执行 reset，因为别人本地还保存着旧的历史，你一 reset，光协调大家的同步问题就能把人逼疯。

git revert的逻辑则完全相反：它不移动历史，而是在当前历史的基础上追加一个新的提交，这个新提交的“内容”恰好是撤销目标提交的改动。例如某次提交把第 10 行从 A 改成了 B，那么revert生成的新提交会把第 10 行从 B 改回 A。git revert的好处是：历史完整保留，不存在“将来丢失提交”的风险，非常适合用在已经推送出去的公共分支上。

4.2 reset 的三种模式：hard、soft、mixed 到底差在哪

git reset除了--hard之外，还有--soft和默认的--mixed（不写参数时默认就是它）。它们的差别主要体现在三个地方怎么处理：HEAD 的位置、暂存区（index）的内容、工作区的内容。

举例来说，我连续提交了三笔改动，功能做到一半觉得这三笔提交粒度太碎了，想压缩成一个。可以这样做：

git reset --soft HEAD~3 git commit -m "合并完成用户登录功能的三个小提交"

注意HEAD~3表示“当前 HEAD 之前的第三个提交”这个位置。执行--soft回退之后，HEAD 指针移动了，但暂存区里还保留着最近三次提交的所有改动，我现在直接 commit 一次，就把三个碎提交压成了一个整体，对历史读者相当友好。

如果我想撤回“某一次已经执行了git add，但还没有 commit”的修改：

git reset # 等价于 git reset --mixed HEAD

这条命令把所有已 staged 的内容撤回为 unstaged，工作区文件保持原样，非常安全。

4.3 回滚到某个历史提交的三种具体玩法

假设你需要把整个项目的状态回滚到某个更早的提交。

第一种，临时看一下旧版本长什么样，不改变当前状态：

git log --oneline # 找到目标提交的哈希，比如 abc1234 git checkout abc1234

此时你会进入 detached HEAD 状态（游离的 HEAD）。别慌，它只是意味着你现在不在任何分支上，而是在一个历史快照上，可以随意查看、测试、甚至在这个状态下改代码。如果只想看看，看完后：

git checkout main

回到主干即可。但如果在这个状态下做了一些实验性改动，想把它保留下来，别忘了先新建一个分支指向当前状态：

git checkout -b experimental/old-version

第二种，把某个文件或多个文件恢复成旧版本的样子：

git checkout abc1234 -- src/utils.js

这个操作会用abc1234提交中该文件的内容，覆盖当前工作区和暂存区。注意它会同时影响工作区和暂存区，如果你只想覆盖工作区，执行完之后还需要用git restore --staged src/utils.js把暂存区退回去。

第三种，整个分支硬回滚到旧版本（仅限未推送的本地分支）：

git reset --hard abc1234

执行之后，分支点和工作区都回到abc1234的时刻。这个命令尽量只在确认要丢弃的改动尚未推送到远端时使用；一旦推送出去了，就改用git revert，或者在团队同步走偏的时候再考虑 reset。

4.4 一个真实的回滚事故复盘

最后分享一个我曾经经历的、让人印象极其深刻的事故复盘。当时某团队在一个项目上线前，发现线上环境报了一个非常严重的 bug，定位后确认是最近一次合并进去的功能导致的。当时大家的第一个反应就是：赶紧回滚。

有成员的角度很快：“直接在 master 上git reset --hard HEAD~1，把那笔合并退掉不就完了？”但这个 master 分支是整个团队的公共分支，已经有其他成员基于它建立了好几个特性分支，并且部分改动已经推送到远端。如果直接硬 reset，所有协作者都会进入“历史不一致”的混乱状态。

大家冷静下来之后，走的是这样一套流程：

1. 先git log --graph --oneline -10看清楚最近提交和合并节点的位置。
2. 确认要撤销的正是某个特定的 merge commit，于是执行：

git revert -m 1 <merge commit hash>

注意这个-m 1是专门用来 revert 合并提交的参数。因为合并提交有两个父提交：第一个父提交是合并时所在分支的 HEAD，第二个是合并进来的分支的 HEAD。-m 1表示保留第一父分支即可，即回到合并发生之前主干上的状态。

3. 推送 revert 产生的提交到远端，大家 pull 后一切恢复正常。这个过程中没有任何历史被重写，所以其他成员只需要正常同步即可，没有一个字是浪费的。

从这个复盘里能学到的经验是：回滚永远优先考虑 revert，直接 reset 永远是最后的手段，而且只能用于未推送的历史。这条规则再强调一次都不为过。

5. 常见问题与排查技巧速查

5.1 快速自诊法：先跑这三条命令，再决定要不要发帖求救

遇到 Git 行为异常，我的第一反应不是翻文档，而是按顺序跑三条命令：

git status git log --graph --oneline --all -10 git branch -vv

git status告诉你仓库当前处于什么状态：是否有未提交的改动、当前在哪个分支、以及是否有正在进行中的 merge/rebase/cherry-pick 操作。很多“奇怪行为”其实都是某个操作没做完、仓库卡在半中间导致的。比如你执行了一次cherry-pick，遇到冲突就暂时搁置去干别的了，过了半小时再回来，发现git status一直提示“You have unmerged paths”。解决办法需要结合具体场景再定，但如果你不先跑git status，可能连问题在哪都不知道。

git log --graph --oneline --all -10是一条只读命令，可以以图形化的方式快速估算出最近十笔提交之间的关系图。如果你怀疑自己“回滚错了”，或想确认本地和远端的差异，看这张图往往一目了然。

git branch -vv用于查看所有本地分支和其关联的远端分支状态（领先/落后多少个提交）。很多“push 不上去”“pull 报错”的问题，罪魁祸首都是分支没设上游，或者设了但不是你想的那一条。看这个命令的输出，能很快锁定问题范围。

5.2 高概率踩坑清单：每个我都亲眼见过或亲手踩过

这个表里的每一项都来自实操中的事故案例。有的看起来很基础，但恰恰是这些“基础场景”在高压环境下最容易出错。比如第 3 条“在错误分支上改了一堆代码”，几乎每个开发者都干过，当时最大的心理压力是“我这几小时的工作是不是白费了”。正确答案是：完全不至于。用git stash暂存，切到正确分支再stash pop，改动几乎原样保留，顶多重新处理一下冲突标记。这种事经一次教训，第二次处理就会快很多。

5.3 关于 force push 的一个清醒备忘

git push --force（或者更精确的git push --force-with-lease）是 Git 世界里最有争议的操作之一。

--force的意义简单粗暴：用本地的历史数据，强制覆盖远端的同名分支。如果你在公共分支上乱用，别人已经推送上去的提交就会从远端消失，而且消失得悄无声息。更可怕的是，因为《Git 分布式设计》的特性，别人本地不一定已经 fetch 到你的新历史，他们会浑然不知地继续在自己旧历史的基础上 commit，最终导致一串串更大的混乱。

--force-with-lease稍微聪明一点：它允许你强制推送，但前提是远端分支的状态和你上一次从远端抓取到的状态一致。换句话说，如果有别人又往远端提交了新东西，--force-with-lease会拒绝你的强推，从而在一定程度上防止了误操作覆盖。

我的建议是：公共分支上用--force-with-lease是底线操作，--force尽量只在“个人专用分支”上使用。所谓的“个人专用分支”不仅是名字上标明了feature/xxx，更关键的是确认没有其他人拉取过这个分支的提交。

5.4 一些能给工作提效的小技巧

最后分享三个我日常工作里用到的、能显著减少重复劳动的小技巧：

第一个，利用git reflog找回一切。git reflog基本可以理解为“Git 的后悔日志”，它记录了每一次 HEAD 变动。如果有一天你误执行了git reset --hard，想去恢复原来的状态，但有忘记原来那个 commit 的哈希，别慌，git reflog会输出最近一段时间内 HEAD 移动过的所有位置，在里面找到目标提交的哈希，然后用git cherry-pick或者git reset回去即可。可以说它就是 Git 用户在走投无路时最后的救命稻草。

git reflog

第二个，写好一个好的 commit message 模板。别小看这个，团队协作时意义极大。我个人常用的模板：

<type>: <subject> <BLANK LINE> - 变更了什么 - 为什么变更 - 可能影响什么

type 用feat（新功能）、fix（修复）、refactor（重构）、chore（杂项）等。使用这个模板后，翻看git log --oneline时几乎能做到“一目了然”，并且 git blame 时也不会一头雾水。

第三个，小心使用git add .，多用手动 add 指定文件。git add .虽然方便，但它会把当前目录下的所有未跟踪文件和修改过的文件全部装进暂存区。在一个充满临时文件、调试输出或自动生成文件的仓库里，这几乎必然会引入垃圾提交。为了降低风险，我的习惯是：先git status看一遍，再git add <file1> <file2>精确添加，最后再git status确认一下再 commit。慢是慢一点，但几乎不会出错。等熟练之后，你甚至会习惯把git add和git commit合并成一条命令的组合来用，比如：

git add src/utils.js src/constants.js && git commit -m "fix: 修复日期格式化函数对空值的处理"

这一串写法的好处是：如果git add因为路径不存在或有问题而失败，后面的&&会让 commit 自动不执行，配合良好的习惯几乎不会产生“提交了一堆多余文件”的尴尬。

结尾的一点经验之谈

Git 这东西，说到底是分布式版本管理的工具，它不限制你怎么用，但坑不坑人完全取决于使用习惯。我这些年最大的体会是：不要在压力最大的时刻去尝试不熟悉的高级命令。真正能把 Git 用得稳的人，其实靠的不是花样百出的命令，而是扎实掌握那几条常用命令的正常工作方式，然后在遇到无法理解的意外时，先跑git status和git reflog看清楚自己在哪里，再决定下一步怎么走。磁盘上的代码没了可以重写，历史乱了也能翻 reflog 找回来，但团队协作中的信任一旦被误操作消耗掉，修复成本远高于任何一条命令能带来的便利。希望这篇分享能帮你在日常开发里少踩几个坑，也让团队里对 Git 不太熟的新人能少一趟浑水。