企业官网建设流程全解析

1. 为什么“git指令大全”值得每个开发者反复翻烂

刚入行那会儿，我对 Git 的理解就停留在add、commit、push三件套上，觉得版本控制嘛，能提交代码不就行了。直到有一次在团队协作中，我误操作把同事还没合并的分支直接push --force覆盖掉了，整个小组花了整整一个下午才把代码找回来。那次教训之后，我才真正开始系统性地整理 Git 指令，把每一条命令背后的逻辑、适用场景、风险点都摸了一遍。

这份“git指令大全”不是那种从官方文档里复制粘贴的速查表，而是我在实际项目里反复验证、踩坑之后沉淀下来的操作手册。它解决的核心问题很明确：让你在遇到任何版本控制场景时，都能快速找到对应的指令组合，并且知道为什么这么用、什么时候不能用。不管你是刚接触 Git 的新手，还是已经用了几年但总在某些场景下卡壳的老手，这份内容都能帮你把零散的指令串成一套完整的操作体系。

我见过太多人把 Git 当成一个“黑盒”，只会几个固定命令，一旦遇到冲突、回滚、分支混乱就手足无措。其实 Git 的指令设计非常有逻辑，每一条命令都是对某一种状态的精确操作。理解了这个逻辑，你就不需要死记硬背，而是能根据当前仓库的状态推导出该用什么指令。接下来我会从整体设计思路开始拆解，然后逐层深入到每个核心指令的实操细节，最后把我这些年遇到的典型问题和排查技巧整理成速查表。

2. Git 指令体系的整体设计与核心逻辑拆解

2.1 三个工作区域：理解 Git 指令的底层模型

很多人学 Git 指令觉得乱，根本原因是没有建立起“三个区域”的心智模型。Git 的所有指令，本质上都是在三个区域之间搬运数据：工作区（Working Directory）、暂存区（Staging Area）、本地仓库（Local Repository）。再加上一个远程仓库（Remote Repository），就构成了完整的四层结构。

工作区就是你当前看到的文件目录，你在这里编辑代码。暂存区是一个中间缓冲层，用来挑选哪些修改要进入下一次提交。本地仓库保存着所有已提交的历史版本。远程仓库则是团队共享的代码中心。每一条 Git 指令，你都可以问自己：它是在哪个区域之间操作数据？比如git add是把工作区的修改搬到暂存区，git commit是把暂存区的内容固化到本地仓库，git push是把本地仓库的提交同步到远程仓库。

这个模型一旦建立起来，你再看那些指令就不会觉得它们是孤立的。比如git reset有三种模式：--soft只移动本地仓库的 HEAD 指针，暂存区和工作区不动；--mixed移动 HEAD 并重置暂存区，但工作区保留修改；--hard则三者全部重置。理解了区域模型，你就能准确判断每种模式会影响到哪些区域，而不是靠死记硬背。

提示：新手最容易混淆的是git reset和git revert。前者是“时光倒流”，直接修改历史；后者是“将功补过”，创建一个新提交来抵消之前的修改。在多人协作的分支上，永远优先用revert，因为reset会改写历史，导致别人的本地仓库和远程仓库产生分歧。

2.2 指令分类逻辑：从“查看”到“修改”的递进关系

我把 Git 指令按照操作性质分成五大类，这个分类方式贯穿整份指令大全，后面每个章节都会按照这个逻辑展开。

第一类是查看类指令，包括git status、git log、git diff、git show等。这类指令不修改任何数据，只是帮你了解当前仓库的状态。很多人忽略这类指令，上来就add和commit，结果提交了不该提交的文件，或者漏掉了该提交的修改。我的习惯是，每次操作前先跑一遍git status，确认工作区和暂存区的状态，这个习惯帮我避免了至少一半的误操作。

第二类是提交类指令，包括git add、git commit、git commit --amend等。这类指令把修改从工作区逐步固化到本地仓库。这里的关键是理解“提交粒度”的概念。一个提交应该只做一件事，比如修复一个 bug 或者添加一个功能。如果你把多个不相关的修改混在一个提交里，后续回滚和排查问题都会非常痛苦。

第三类是分支类指令，包括git branch、git checkout、git switch、git merge、git rebase等。分支是 Git 最强大的功能之一，但也是问题最多的区域。合并和变基的选择、冲突的解决、分支的清理，每一个话题都值得单独展开。

第四类是远程类指令，包括git remote、git fetch、git pull、git push等。这类指令涉及本地和远程的同步，风险点主要集中在push --force和pull的合并策略上。

第五类是撤销与回滚类指令，包括git reset、git revert、git checkout --、git restore等。这类指令是“后悔药”，但不同场景下该用哪种“后悔药”，需要根据是否已推送、是否多人协作、是否要保留修改等因素来判断。

2.3 为什么选择命令行而不是图形界面

市面上有很多 Git 图形客户端，比如 SourceTree、GitKraken、VS Code 内置的 Git 面板等。这些工具确实降低了入门门槛，但我仍然强烈建议你把命令行指令练熟。原因有三个。

第一，命令行是 Git 的“母语”。所有图形界面本质上都是在调用 Git 命令，当你遇到图形界面无法处理的复杂场景时，最终还是得回到命令行。比如你想批量修改历史提交的作者信息，或者想用git bisect定位引入 bug 的提交，这些操作在图形界面里要么不支持，要么非常难找。

第二，命令行让你对仓库状态有更精确的感知。图形界面往往会隐藏一些细节，比如暂存区的具体内容、分支的跟踪关系、远程仓库的配置等。而命令行会把这些信息直接展示给你，让你在做决策时有更完整的依据。

第三，命令行指令可以写成脚本，实现自动化。比如你可以写一个脚本，在每次提交前自动跑一遍代码检查，或者批量清理已合并的本地分支。这些在图形界面里很难做到。

当然，我并不是说图形界面一无是处。在查看提交历史、对比文件差异这些场景下，图形界面确实更直观。我的建议是：日常操作以命令行为主，复杂的历史查看和差异对比可以借助图形工具辅助。这样既能保证操作的精确性，又能利用可视化工具提升效率。

3. 核心指令深度解析与高频场景实操要点

3.1 仓库初始化与配置：别小看这几条命令

git init和git clone是两条最基础的指令，但里面的细节很多人没注意。git init会在当前目录创建一个.git隐藏文件夹，这个文件夹就是整个版本控制的核心。如果你不小心删除了它，整个仓库的历史就没了。所以我的习惯是，在初始化仓库之前，先确认当前目录是不是正确的项目根目录，避免在错误的层级初始化。

git clone除了克隆代码，还会自动配置远程仓库的跟踪关系。默认情况下，克隆下来的仓库会有一个名为origin的远程，指向你克隆的地址。你可以用git remote -v查看这个配置。如果你需要同时推送到多个远程仓库，可以用git remote add添加额外的远程，比如同时推送到公司的代码托管平台和内部的备份服务器。

配置方面，git config是必须掌握的指令。最基本的配置是用户名和邮箱，这两项会出现在每一条提交记录里。我建议在全局配置里设置常用的用户名和邮箱，然后在特定仓库里用--local覆盖。比如你在公司项目里用工作邮箱，在个人项目里用私人邮箱，就可以通过局部配置来实现。

# 全局配置 git config --global user.name "你的名字" git config --global user.email "你的邮箱" # 当前仓库单独配置 git config --local user.name "工作用名字" git config --local user.email "工作邮箱"

还有一个非常实用的配置是core.autocrlf，用来处理不同操作系统之间的换行符差异。Windows 用 CRLF，Linux 和 macOS 用 LF，如果不配置，跨平台协作时会出现大量“整个文件都被修改”的假差异。我的建议是：Windows 用户设置为true，Linux 和 macOS 用户设置为input。

注意：git config --global的配置会写入用户主目录下的.gitconfig文件。如果你在多台机器上工作，可以把这份配置文件同步到云端，或者用脚本一键部署，省去重复配置的麻烦。

3.2 提交相关指令：从 add 到 commit 的完整链路

git add看似简单，但有几个高频场景需要特别注意。最常用的是git add <file>添加指定文件，git add .添加当前目录下所有修改。但git add .有个坑：它会把所有修改都加进去，包括你不想提交的临时文件。所以更推荐用git add -p进入交互模式，逐个确认每个修改块是否要暂存。这个方式虽然慢一点，但能有效避免误提交。

git commit的基本用法是git commit -m "提交信息"，但提交信息的质量直接影响后续的排查效率。我见过太多“fix bug”、“update”这样的提交信息，过一个月回头看根本不知道改了什么。好的提交信息应该包含三部分：做了什么、为什么做、影响了什么。比如“修复用户登录时 token 过期未刷新的问题，影响登录模块和权限校验模块”。

如果你提交之后发现漏了文件或者提交信息写错了，可以用git commit --amend来修补最近一次提交。这个指令会打开编辑器让你修改提交信息，同时可以把暂存区的新修改合并进上一次提交。但要注意，--amend会改变提交的哈希值，如果这次提交已经推送到远程仓库，就需要强制推送，这在多人协作的分支上是有风险的。

# 修改最近一次提交的信息 git commit --amend -m "新的提交信息" # 把漏掉的文件补进最近一次提交 git add forgotten_file git commit --amend --no-edit

还有一个场景是合并多个提交。比如你在开发一个功能时提交了五次，但希望合并成一个干净的提交再推送。可以用git rebase -i HEAD~5进入交互式变基，把后面四个提交的pick改成squash，这样它们就会被合并到第一个提交里。这个操作在提交 PR 之前非常有用，能让代码历史更清晰。

3.3 分支管理指令：创建、切换与合并的实战细节

分支是 Git 的核心竞争力，但也是问题最集中的地方。git branch用来查看、创建、删除分支。git branch不带参数会列出所有本地分支，加-a会列出包括远程分支在内的所有分支。创建分支用git branch <分支名>，删除分支用git branch -d <分支名>。如果分支还没合并，-d会拒绝删除，这时候可以用-D强制删除，但要确认这个分支的修改确实不需要了。

切换分支用git checkout <分支名>或者新版的git switch <分支名>。switch是 Git 2.23 引入的，专门用来切换分支，比checkout更语义化。因为checkout既能切换分支又能恢复文件，容易混淆。我现在的习惯是：切换分支用switch，恢复文件用restore，这样职责清晰，不容易出错。

合并分支用git merge <分支名>，把指定分支合并到当前分支。合并有两种情况：如果当前分支是目标分支的直接祖先，Git 会执行“快进合并”，直接把当前分支指针移到目标分支，不会产生新的提交。如果两个分支有分叉，Git 会创建一个新的合并提交。如果你希望即使可以快进也保留分支历史，可以用--no-ff参数强制创建合并提交。

# 切换到主分支 git switch main # 合并功能分支，保留合并记录 git merge --no-ff feature/login # 删除已合并的功能分支 git branch -d feature/login

变基（rebase）是另一种整合分支的方式。git rebase <目标分支>会把当前分支的提交“搬”到目标分支的最新提交之后，形成一条线性的历史。变基的好处是历史干净，没有多余的合并提交；坏处是会改写提交的哈希值，如果当前分支已经推送到远程，就需要强制推送。我的原则是：本地分支用变基保持整洁，已推送的公共分支用合并保留历史。

3.4 远程协作指令：fetch、pull、push 的正确打开方式

git remote用来管理远程仓库的配置。git remote -v查看当前配置的远程仓库，git remote add <名称> <地址>添加新的远程，git remote remove <名称>删除远程。默认的远程名称是origin，你可以改成任何你喜欢的名字，但建议保持默认，避免团队协作时产生混淆。

git fetch和git pull的区别是新手最容易搞混的。fetch只是把远程仓库的最新数据下载到本地，但不会自动合并到当前分支。pull相当于fetch加merge，会直接把远程的修改合并到当前分支。我强烈建议在多人协作的项目里优先用fetch，先看看远程有什么变化，再决定是合并还是变基。直接用pull有时候会触发意料之外的合并，产生不必要的合并提交。

# 拉取远程所有分支的最新数据，但不合并 git fetch origin # 查看远程分支和本地的差异 git log HEAD..origin/main --oneline # 确认无误后再合并 git merge origin/main

git push是把本地提交推送到远程。基本用法是git push <远程名> <分支名>。如果本地分支和远程分支同名，可以简写成git push。第一次推送新分支时，需要加-u参数建立跟踪关系，之后就可以直接git push了。

git push --force是危险操作，它会用本地历史覆盖远程历史。如果别人已经基于远程分支做了提交，这些提交就会丢失。如果确实需要强制推送，比如你变基了本地分支，可以用--force-with-lease代替--force。--force-with-lease会先检查远程分支是否有人推送了新提交，如果有，就拒绝推送，避免覆盖别人的工作。

提示：在团队协作中，永远不要对公共分支（如 main、develop）使用强制推送。如果确实需要回滚公共分支的提交，用git revert创建一个反向提交，而不是用reset改写历史。

3.5 撤销与回滚指令：不同场景下的“后悔药”选择

撤销操作是 Git 指令里最需要谨慎对待的部分，因为不同场景下适用的指令完全不同。我整理了一个决策流程，帮你快速判断该用哪条指令。

如果修改还在工作区，没有add，直接用git restore <file>丢弃修改。如果已经add到暂存区，但还没commit，用git restore --staged <file>把修改从暂存区撤回到工作区，然后再决定是丢弃还是继续修改。如果已经commit但还没push，可以用git reset --soft HEAD~1撤销提交但保留修改，或者用git reset --hard HEAD~1彻底丢弃这次提交和修改。

如果已经push到远程仓库，情况就复杂了。如果是个人分支，可以用git reset回滚后强制推送。如果是公共分支，应该用git revert <commit>创建一个反向提交，这样既撤销了修改，又不改写历史。revert会生成一个新的提交，内容与要撤销的提交相反，比如原来添加了一行代码，revert就会删除这行代码。

# 撤销最近一次提交，保留修改在暂存区 git reset --soft HEAD~1 # 撤销最近一次提交，保留修改在工作区 git reset --mixed HEAD~1 # 彻底撤销最近一次提交和修改 git reset --hard HEAD~1 # 创建一个反向提交来撤销指定提交 git revert <commit-hash>

还有一个特殊场景是恢复被删除的文件。如果文件被rm删除了但还没commit，可以用git restore <file>恢复。如果已经commit了删除操作，可以用git checkout <commit> -- <file>从历史提交中恢复文件。这个指令会把指定提交中的文件版本复制到工作区，然后你可以重新add和commit。

3.6 暂存与清理指令：stash 和 clean 的实用技巧

git stash用来临时保存工作区和暂存区的修改，让你可以切换到其他分支处理紧急任务，处理完再回来继续。基本用法是git stash保存当前修改，git stash pop恢复最近一次保存的修改并删除该记录，git stash apply恢复但不删除记录。如果你有多个 stash 记录，可以用git stash list查看，用git stash pop stash@{2}恢复指定的记录。

git stash的一个高级用法是git stash -p，进入交互模式，选择性地暂存部分修改。比如你同时改了三个文件，但只想暂存其中两个，就可以用这个方式。还有一个场景是git stash之后切换分支，处理完再切回来pop，这个流程在紧急修复线上 bug 时非常实用。

git clean用来删除未跟踪的文件和目录。默认情况下，git clean不会删除未跟踪的文件，需要加-f参数强制删除。如果还要删除未跟踪的目录，加-d参数。我建议在执行git clean之前，先用git clean -n预览一下会删除哪些文件，确认无误后再执行。

# 预览会删除哪些未跟踪文件 git clean -n # 删除未跟踪文件和目录 git clean -fd # 连同忽略的文件一起删除（慎用） git clean -fdx

注意：git clean -fdx会删除.gitignore中忽略的文件，比如编译产物、依赖包等。执行前一定要确认这些文件可以重新生成，否则可能会丢失重要数据。

4. 完整实操流程：从零搭建一个规范的 Git 工作流

4.1 项目初始化与分支策略设计

假设我们要开始一个新项目，第一步是初始化仓库并设计分支策略。我推荐的分支模型是：main分支保持稳定，只接受经过测试的合并；develop分支作为日常开发的主分支；功能分支从develop切出，完成后合并回develop；发布时从develop切出release分支，测试通过后合并到main和develop。

# 初始化仓库 git init git add . git commit -m "初始化项目结构" # 创建 develop 分支 git branch develop git switch develop # 创建功能分支 git switch -c feature/user-login

这个流程的关键在于：每次创建功能分支前，先确保develop是最新的。可以用git fetch origin拉取远程最新，然后git rebase origin/develop把本地develop更新到最新。这样功能分支就是基于最新的代码开发的，减少后续合并冲突的概率。

4.2 日常开发中的提交与同步操作

日常开发中，我习惯每完成一个小功能点就提交一次。提交前先跑git status确认修改范围，然后用git add -p逐个确认要暂存的修改块。提交信息按照“类型: 描述”的格式写，比如feat: 添加用户登录接口、fix: 修复 token 过期未刷新的问题。

# 查看当前状态 git status # 交互式暂存 git add -p # 提交 git commit -m "feat: 添加用户登录接口" # 推送到远程功能分支 git push -u origin feature/user-login

如果开发过程中develop分支有新的提交，需要同步到功能分支。我推荐用变基而不是合并，这样功能分支的历史会更干净。操作方式是：先git fetch origin，然后git rebase origin/develop。如果变基过程中出现冲突，Git 会暂停并提示你解决冲突。解决完冲突后，用git add暂存解决后的文件，然后git rebase --continue继续。

4.3 合并请求与代码审查的指令配合

功能开发完成后，需要把功能分支合并到develop。在团队协作中，这通常通过合并请求（Merge Request）或拉取请求（Pull Request）来完成。在提交合并请求之前，我建议先做三件事：第一，用git rebase origin/develop把功能分支更新到最新；第二，用git log --oneline origin/develop..HEAD查看功能分支相对于develop的所有提交；第三，用git diff origin/develop...HEAD查看完整的代码差异。

# 更新功能分支 git fetch origin git rebase origin/develop # 查看功能分支的提交列表 git log --oneline origin/develop..HEAD # 查看完整差异 git diff origin/develop...HEAD

代码审查通过后，合并到develop。如果团队使用平台提供的合并功能，直接在界面上操作即可。如果需要手动合并，可以切换到develop，先git pull更新到最新，然后git merge --no-ff feature/user-login合并功能分支，最后git push推送。

4.4 版本发布与热修复的完整流程

当develop分支积累了足够的功能，准备发布新版本时，从develop切出release分支。在release分支上只做 bug 修复，不再添加新功能。测试通过后，把release分支合并到main和develop，并在main上打标签。

# 创建发布分支 git switch -c release/v1.0.0 develop # 修复发布前的 bug git commit -m "fix: 修复发布前的样式问题" # 合并到 main git switch main git merge --no-ff release/v1.0.0 git tag -a v1.0.0 -m "发布版本 v1.0.0" # 合并回 develop git switch develop git merge --no-ff release/v1.0.0 # 删除发布分支 git branch -d release/v1.0.0

如果线上发现紧急 bug，需要热修复。从main切出hotfix分支，修复后合并到main和develop，并在main上打新的标签。这个流程确保线上问题能快速修复，同时修复内容也会同步到后续的开发分支。

5. 常见问题与排查技巧实录

5.1 合并冲突的排查与解决思路

合并冲突是最高频的问题。当两个分支修改了同一个文件的同一区域时，Git 无法自动决定保留哪个版本，就会产生冲突。冲突文件里会出现<<<<<<<、=======、>>>>>>>这样的标记，分别表示当前分支的修改、分隔线、目标分支的修改。

解决冲突的步骤是：第一，用git status查看哪些文件有冲突；第二，打开冲突文件，手动决定保留哪些内容，删除冲突标记；第三，用git add暂存解决后的文件；第四，用git commit完成合并，或者用git rebase --continue继续变基。

我处理冲突的习惯是：先用git diff查看冲突的具体内容，然后打开文件逐个解决。如果冲突文件很多，可以用git mergetool调用可视化合并工具，比如 VS Code 的内置合并编辑器。解决完所有冲突后，一定要跑一遍测试，确认合并后的代码能正常工作。

提示：如果冲突解决到一半发现搞错了，可以用git merge --abort或git rebase --abort放弃合并，回到操作前的状态。这个指令在冲突复杂、一时半会儿解决不了的时候非常有用。

5.2 误操作后的数据恢复方法

误操作是每个开发者都会遇到的。最常见的是误删分支、误回滚提交、误强制推送。针对不同情况，恢复方法也不同。

误删分支后，可以用git reflog查看操作历史，找到被删除分支的最后一次提交哈希，然后用git branch <分支名> <哈希>恢复分支。reflog是 Git 的“操作日志”，记录了 HEAD 的每一次移动，包括提交、切换分支、回滚等。默认情况下，reflog会保留 90 天的记录，足够你找回大部分误删的内容。

# 查看操作历史 git reflog # 找到被删除分支的提交哈希后恢复 git branch recovered-branch abc1234

误回滚提交后，同样可以用reflog找到回滚前的提交哈希，然后用git reset --hard <哈希>恢复到那个状态。如果误强制推送覆盖了远程分支，需要先在本地的reflog里找到被覆盖的提交，然后重新推送到远程。如果本地也没有记录，可以尝试在远程仓库的“活动”或“回收站”功能里找回，但成功率取决于平台是否保留了历史记录。

5.3 大文件与敏感信息的处理方案

Git 仓库里不小心提交了大文件或敏感信息，是另一个高频问题。大文件会让仓库体积膨胀，克隆和拉取变得非常慢。敏感信息比如密码、密钥，一旦提交到远程仓库，即使后续删除了，历史记录里仍然可以找到。

如果刚提交了大文件还没推送，可以用git reset --soft HEAD~1撤销提交，然后用git rm --cached <大文件>把文件从暂存区移除，再重新提交。如果已经推送了，需要用git filter-branch或BFG Repo-Cleaner工具来清理历史记录。这两个工具会重写整个仓库的历史，操作前一定要备份。

# 从暂存区移除大文件但保留在工作区 git rm --cached large-file.zip # 把大文件加入 .gitignore echo "large-file.zip" >> .gitignore # 重新提交 git commit -m "移除大文件并添加到忽略列表"

敏感信息的处理原则是：一旦提交到远程仓库，就视为已泄露。正确的做法是立即更换泄露的密码或密钥，然后再清理仓库历史。清理历史只是防止后续泄露，不能挽回已经泄露的事实。

5.4 常见问题速查表

这张表里的每一条都是我实际遇到过的场景，解决方案也是经过验证的。建议你把这张表保存下来，遇到问题时先查表，再根据具体情况调整。

6. 指令之外的功夫：让 Git 真正成为效率工具

6.1 别名配置：把长指令变成短指令

Git 的别名功能可以大幅提升操作效率。比如git status可以简写成git st，git checkout可以简写成git co。配置方式是用git config --global alias.<别名> <原指令>。

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 lg是我最常用的别名，它会以图形化方式展示所有分支的提交历史，非常直观。你还可以配置更复杂的别名，比如git config --global alias.undo "reset --soft HEAD~1"，这样git undo就能撤销最近一次提交。

6.2 钩子脚本：自动化检查与规范约束

Git 钩子（Hook）是在特定操作前后自动执行的脚本。比如pre-commit钩子在每次提交前执行，可以用来跑代码检查、格式化、单元测试。如果钩子脚本返回非零值，提交就会被阻止。

我通常在项目里配置pre-commit钩子来跑 ESLint 和 Prettier，确保提交的代码符合规范。配置方式是在.git/hooks目录下创建pre-commit文件，写入脚本内容，然后赋予执行权限。不过.git/hooks目录不会随仓库一起提交，所以团队协作时需要用工具来管理钩子，比如 Husky。

#!/bin/sh # .git/hooks/pre-commit npm run lint npm run test

这个脚本会在每次提交前跑 lint 和测试，任何一项失败都会阻止提交。虽然会稍微降低提交速度，但能有效防止有问题的代码进入仓库。

6.3 从指令到工作流：建立自己的操作习惯

最后我想说的是，Git 指令只是工具，真正重要的是建立一套适合自己的工作流。我的习惯是：每天开始工作前先git fetch拉取远程最新；开发过程中每完成一个小功能就提交一次；提交前用git diff检查修改内容；推送前用git rebase更新分支；合并请求前用git log确认提交历史。

这套习惯让我在多人协作中很少遇到冲突，即使遇到也能快速解决。Git 的学习曲线确实有点陡，但一旦跨过那个坎，你会发现它带来的效率提升是巨大的。我见过很多开发者用了几年 Git 还在用最基础的几个命令，遇到问题就上网搜，搜到指令就复制粘贴，完全不理解背后的逻辑。这种方式在简单场景下能应付，但一旦遇到复杂情况就会卡住。

我的建议是：不要满足于“能用”，要追求“知道为什么”。每学一条新指令，都问自己三个问题：它操作的是哪个区域？它会影响哪些数据？它在什么场景下使用？把这三个问题搞清楚，你就能从“背指令”变成“用指令”，真正把 Git 变成自己的效率工具。

这份指令大全里的每一条指令和每一个场景，都是我在实际项目中反复验证过的。你可以把它当作速查手册，遇到问题时快速定位；也可以当作学习材料，从头到尾过一遍，建立起完整的 Git 知识体系。不管你是哪种用法，我都希望它能帮你少踩一些坑，少走一些弯路。