弥勒鹿开头先讲个我碰到比较多的问题。隔一段时间就有人抱着一张打印出来的“Git 常用命令大全”来问，说自己背了大半个月，今天一用还是慌，要么不敢 push，要么 push 上去发现把不该提交的文件也交上去了。这种感觉我很理解，因为 Git 本来就不是靠背命令学会的工具。你说它命令多，其实你真正高频使用的就是 20 来个；但这些命令之间是有前后顺序和语义关系的，如果没把“为什么这样用”想明白，背再多命令列表，上手照样手足无措。
这篇东西我想换个角度写。不按命令字典的字母顺序给你罗列，而是按一条真实的工作流来拆：从初始化仓库、日常提交、分支合并，到同步协作、历史撤销，再到让 Git 更顺手的配置。每一条都是我实际在项目里反复用过、同时在团队辅导新人时被问过最多遍的操作。你可以把它当作“遇到某个场景时应该敲哪条命令”的速查手册，也可以跟着顺序读一遍，把散落的命令串成一条自己能跑通的主线。刚入门的读者建议从头到尾看，已经用了一段时间但总觉得心里没底的，可以挑自己薄弱的环节直接跳到对应章节。
1. 先弄懂仓库里的三个存放区，常用命令才不需要死背
1.1 工作区、暂存区和本地版本库，这套流向解释了一半命令
我遇到过不少朋友，git add 和 git commit 是会的，但你再问他“暂存区到底缓存了什么”“为什么提交前必须 add”，他就只能告诉你“大家都这么敲的”。这样用 Git，等于在盲人摸象。
其实 Git 的日常命令只需要围绕四个位置来理解：工作区（你当前编辑文件的目录）、暂存区（一个中间存放区，可以临时挑选下次要提交的内容）、本地版本库（已经提交的历史节点都存在这）、远程版本库（托管在服务器/GitLab/GitHub 上供团队共享的地方）。文件在正常情况下就在这几个位置之间流动：
| 命令动作 | 数据从哪到哪 | 一次典型的应用场景 |
|---|---|---|
git add |
工作区 -> 暂存区 | 我改了 README.md 和 index.js，只想把 README.md 放进下一次提交 |
git commit |
暂存区 -> 本地版本库 | 暂存区内容确认无误，生成一个新的本地历史节点 |
git push |
本地版本库 -> 远程版本库 | 把本地提交同步到远端，让大家看到 |
git fetch / git pull |
远程版本库 -> 本地 | 拉取队友已经推到远端的新提交 |
git checkout / git switch / git restore |
版本库中的某版本 -> 工作区 | 放弃当前工作区改动，把某个文件恢复成上一次提交状态 |
你可以把暂存区理解成购物车。逛超市看到好东西不一定要立刻付款，先在购物车里挑挑拣拣，确定这波真正想买单的再一起结账。add 就是往购物车里放东西，commit 才是刷卡拉出小票、成为永久历史记录。很多人以为提交代码是“一步到位”，其实 Git 刻意把它拆成了两步，目的就是给你一个每次提交前重新审视的机会：这 3 个文件该一起提交吗？那个 .env 环境变量文件刚才是不是手滑加进来了？
有个新人曾经很认真地问我：“那我永远直接 git add . 再 git commit，不也一样吗？”大多数随手项目确实能这样跑，但只要你开始跟别人协作，或者你的项目有关键配置文件不能泄露，你就会意识到问题：add . 会把当前目录下所有改动不分青红皂白全部放进购物车，等于放弃了 Git 最值钱的“精细控制”能力。关于这点，后面会在提交章节里展开。
1.2 查看类命令：动手改东西之前，一定要先知道仓库是什么状态
另一个新手习惯是“上来就闷头敲命令，敲完再看屏幕”。我的建议是反过来：动手前先把状态打听清楚。Git 里有一批命令不修改任何东西，只是帮助摸清现状，它们是整个工作流的地图。
git status：最常用的查看命令。它告诉你当前在哪个分支、工作区里有哪些文件被修改过、有哪些文件已经加入暂存区，以及远程分支有没有落后提醒。每次操作前敲一下，比事后出乱子再痛苦排查划算得多。git diff：查看还没add的那些改动，具体改了什么内容。如果你在status里看到一堆修改，不确定这些改动是否都是这次想提交的，用git diff看具体文本最直观。git diff --cached：查看已经add进暂存区的内容跟上一个提交之间的差异。这也是提交前的一步自查，下面会专门讲。git log：查看本地提交历史。我几乎每次落座写代码前都会先看两眼 log，回忆自己上一次做完了什么、这几次提交的节奏是否合理。后面要追查“这段代码是什么时候加的、为什么加”也靠它。git log --oneline --graph --decorate --all：以图形方式把最近提交和各分支指向关系打印成一行行的简略信息。当分支变多、流程图太长时，这一条是快速定位全局的利器。git show <commit-hash>：查看某一次具体提交改了什么文件、什么内容。配合 log 用，能把一段模糊记忆还原成清晰的 diff。
还有一个很容易踩坑的经验：别在一个完全陌生的仓库里直接敲消耗型命令。比如 git reset --hard、git clean -fd，它们会真的改掉文件。如果对仓库状态不了解，第一步永远是 git status。每次你准备对 Git 做“破坏性动作”（重置、清理、强推）前，先想一想：这个命令会改动文件吗？如果答案会，我有没有弄清楚当前状态？这比任何命令速查表都管用。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 初始化与远端对接：从零开坑和交接项目，最容易出岔子的几个细节
2.1 git init 与 git clone，分别在什么时候用
当一个全新的项目刚刚创建好文件夹时，第一件事是往里跑 git init。它会在这个目录下生成一个隐藏的 .git 目录，所有 Git 历史、配置、引用都锁在这个目录里。此时你的仓库还只是本地的，没有和任何远端关联，需要后续用 git remote add 把远端地址绑定上来。
另一种更常见的情况是加入一个已经存在的项目。这时不要 git init，直接 git clone <仓库地址>。clone 会把远端历史的完整副本拉到本地，同时自动帮你把 origin（远端仓库的默认别名）配好，第一步就能开始工作。
我见过好几个朋友在这个环节翻车：他们习惯了 git clone 以后再新建一个同样名字的文件夹，结果把代码复制来复制去，最后本地出现一堆嵌套目录，提交的时候要么提交了外层空壳，要么把克隆下来的 .git 也误当成普通文件提交了。其实 clone 生成的目录名默认就是仓库名，直接在这个目录里改代码就好。如果你非要用别的目录名，可以追加参数，比如 git clone https://xxx/backend.git local-backend，这样代码会落到 local-backend 文件夹里。
2.2 首次推送必须设置上游关系：那个 -u 参数到底是什么意思
本地提交已经写好，执行 git push 的时候，新手往往会看到一长串提示“当前分支没有对应的上游分支”。这个上游关系（upstream）指的是：本地分支要把自己推送到远程哪个分支。没有它，Git 不知道该对接谁。
处理办法很简单：第一次推送时使用 git push -u origin main，把本地 main 分支和远端的 main 分支绑定。之后再在同一个分支上推送，只需敲 git push。这里的 -u 是 --set-upstream 的简写，是一个“一劳永逸”的关联操作。
同样的逻辑也适用于拉取和分支切换。前面提到的 git pull 和 git checkout 如果带上了跟踪信息，都会简洁很多，因为它知道自己在跟哪个远端分支打交道。
2.3 刚装好 Git 却发现命令不识别：常见环境变量问题的排查
关于安装 Git，很多人的痛点其实不是安装过程，而是装完之后在终端里敲 git 没反应。比如在 Windows 的命令提示符或 PowerShell 里，有朋友见过类似这样的报错：“git 无法被识别为 cmdlet、函数、脚本文件或可运行程序的名称”。这句话听起来挺唬人，实际含义很简单：系统在可执行程序的搜索路径里找不到 git 命令。
解决方法分两步。第一步回顾 Git 安装过程是否完整；第二步检查环境变量。Git for Windows 默认会安装到 C:\Program Files\Git，其中包含一个 cmd 子目录，里面才有 git.exe（尤其打开 Git Bash 用的核心程序）。你需要在操作系统的 PATH 环境变量里加上一条，把 C:\Program Files\Git\cmd 加进去。
比较常见的低级错误是只加了 C:\Program Files\Git，忽略了 cmd 那层子目录，所以还是找不到命令。加完之后还建议重启一次终端甚至重启系统，让环境变量重新加载。在 macOS 或 Linux 上相对省心，一般各发行版的软件源里都带 Git，装完即用。
3. 提交代码不是简单 add + commit：信息颗粒度、提交说明与事后检查
3.1 让一次提交只承载一类逻辑改动：git add 的三种姿势对比
git add . 虽然无脑，但风险很大。假设你同时在修一个 bug 和一个新功能，文件都改在同一批代码里，用 add . 会把两类无关改动混进同一个 commit。日后要回溯“这个 bug 是哪次改动弄坏的”“这个功能对应的提交在哪”，你会非常痛苦。
日常开发中我更常用的是这三种：
git add <具体文件>：最精准。比如我改了src/utils/helper.ts和src/page/home.tsx，如果它们属于两个不同任务，我会先git add src/utils/helper.ts，提交后再处理另一个文件。这样每次 commit 的边界非常清晰。git add -p：交互式地把一个文件里的不同 hunks（代码块）分开暂存。比如同一个文件里既有旧功能的重构、又有新逻辑的插入，用它可以只把其中一块相关改动加进暂存区。第一次使用会觉得繁琐，它每块都会问你是否暂存，但这是精细提交的神器。git add -u：只暂存已被跟踪且发生修改的文件，不会把新增的未跟踪文件也加进来。如果你改了老文件又新增了一个临时脚本，使用-u可以避免误把临时脚本提交上去。
我自己接手老项目时，尤其喜欢在提交前用 git add -p 过一遍改动。它逼着你逐块审视代码，反而能发现一些明显写错的地方，这种“提交前的强制复审”价值很高。
3.2 提交信息是写给人看的：commit 的内容结构和 --amend 修补
git commit -m "修改代码" 是另一个让 Git 历史变得几乎无用的做法。你三个月后回来看这段提交，完全想不明白“修改代码”到底改了什么。更好的提交信息应包含三要素：这次改了什么、为什么改、影响范围大概在哪。
比如下面这条：
bash复制git commit -m "fix: 修复用户首次登录时个人中心为空的问题
首次登录时 token 尚未刷新，导致个人资料接口提前请求返回空数据。
将请求时机改为 token 刷新完成后的回调里执行，并补充断言测试。"
第一行是主体，简短点题；空行之后是补充说明，讲清楚背景和解决思路。很多团队还会在信息前加类型前缀，比如 feat:（新功能）、fix:（修复）、refactor:（重构）、docs:（文档），方便后续看一眼 log 就能快速分类。
如果你提交完发现信息写错了，或者刚才漏提交了一个文件，不想为此增加一条没有意义的提交记录，可以用 --amend：
bash复制git commit --amend
--amend 是把当前暂存区的改动合并进上一次提交，并且重新打开编辑器修改提交说明，相当于对上一个 commit 做“后悔修正”。需要注意，--amend 会改写 commit 的哈希与时间戳，所以它只适合处理还没有推送出去的提交。如果这个 commit 已经推送到远端、队友也在基于它开发，别用 --amend 去改共享历史，否则大家会陷入要不要强推的混乱。
3.3 提交前先看 diff：你马上要记录的历史，最好亲眼确认一遍
我完全不信任记忆，只信任 git diff。每次提交之前，我的固定动作是：
bash复制git status
git diff --cached # 看暂存区相对上一个提交的差异
git diff --cached 会把你已经 add 的内容逐一显示出来。这一步能拦截一大类提交事故：临时调试代码没删干净、不小心把客户真实手机号写死进测试文件、.env 里的敏感信息被卷进来，等等。用眼睛扫一遍要提交的差异，其实只需要十几秒，却能避免让不干净的内容从此变成项目历史里难以擦除的印记。
有一位老同事的比喻我一直记得：提交记录相当于你写给未来的自己还有同事的一封封信。信寄出去之后，你当然不希望里面夹着错别字或者发货单。写前检查，是写 Git 信件的必要仪式感。
4. 分支管理：一个人多线作战、一个团队并行协作的核心命令组合
4.1 新建与切换分支：checkout -b、switch 和分支命名直觉
分支是 Git 最成功的“并行宇宙”设计。新功能、紧急修复、版本迭代放到各自独立的分支上，互不干扰。
创建并切换分支，最传统的一条是：
bash复制git checkout -b feature/login
如果只想切换已经存在的分支，则用 git checkout main。不过新版本 Git 里更推荐的是 git switch 系列，语义更准确，也避免“checkout 到底是在切文件还是切分支”的混淆：
bash复制git switch -c feature/payment # 新建并切换
git switch main # 切换已存在分支
git switch - # 快速切回上一个分支
分支命名的直觉也有讲究。团队协作的项目里，分支名最好带有任务标签，比如 feature/wx-pay-redirect、fix/avatar-not-display、chore/upgrade-deps。我见过有的团队直接把某个内部任务单号拼进去，如 feat/TICKET-2071-refund-flow，后续溯源时只要知道任务单号，一条命令就能找到所有相关提交，非常省事。
4.2 merge 与 rebase 的选择，以及冲突解决的真实处理流程
当开发分支写完，需要把代码合并回主干时，最常用的方式是 git merge。比如我在 feature/login 上完成工作，切回 main 执行：
bash复制git switch main
git merge feature/login
如果两个分支的改动毫无交集，Git 会自动做一次快进式合并，历史是一条直线；如果有冲突，Git 会明确告诉你“自动合并失败，需要手动解决”。这种冲突出现时，往往涉及到同一行代码、同一段逻辑被双方同时改过。
真实处理冲突的步骤大致是下面这几步：
- 打开冲突文件，搜索
<<<<<<<、=======、>>>>>>>标记。这三段之间是你的版本和对方版本的差异区域。 - 逐个判断应该保留哪一方、还是两方都要改才能保住逻辑。
bash复制<<<<<<< HEAD
const title = "我的页面";
=======
const title = "新版页面";
>>>>>>> feature/login
- 手动删除符号标记，整理出最终希望保留的代码。
- 保存文件后执行
git add，把解决完的文件标记为“已解决”。 - 再执行一次
git commit完成合并提交。
关于 merge 与 rebase 的争论，网上各执一词。我的个人态度是：合并主分支/主干方向的代码时，只要团队一致，两种都可以用；但默认情况下我更偏向 merge，因为 merge 会生成一个真实的“合并提交”，后人看历史时能清楚看到一次合并发生在哪个节点；而 rebase 会把提交“摘下再重新种到另一个分支上”，历史更像直线、更整齐，但代价是改写提交先后关系。
团队内部真正忌讳的是“每人都按自己的想法乱用”：有人历史全是 merge、有人把提交全部 rebase 成一条线，中间再叠加一堆冲突解决，最后历史图乱得无法直视。任选其中一种，并且写进团队的约定里，比纠结哪种绝对更好更重要。
4.3 临时切换工作的救命稻草：git stash 与 git cherry-pick
场景很常见：我正在 feature/login 上写某个功能，写了一半，线上突然报一个紧急 bug，必须切到 main 修复。而手头的代码修改又不能直接丢弃，此时 git stash 就该登场了。
bash复制git stash # 当前未提交的改动先存起来，工作区恢复干净
git switch main # 切到别的分支安心修 bug
...
git switch feature/login
git stash pop # 恢复之前存的改动
stash 就像一个临时储物柜。它还有一个我常用的高级组合——git stash push -m "wip: 登录页样式"，给每个暂存的改动取个名字，避免 stash 堆了好几份之后根本分不清谁是谁。恢复时如果遇到跟当前分支新代码的冲突，说明当时的改动和现在的代码已经不相容，需要手动处理，处理流程跟 merge 冲突一样。
cherry-pick 则负责“挑某一个提交的内容复制到当前分支”。比如线上紧急修复的提交哈希是 a1b2c3d，但这个修复只存在于 hotfix 分支上，你希望把它的内容应用到 main，可以执行：
bash复制git switch main
git cherry-pick a1b2c3d
它会把这一个提交的补丁内容重新应用到当前分支，形成一个新的提交，而不必把对方分支的其他提交一起合并过来。这在管理“只想要某个修复、不想要那一整个分支”的场景里，比手动复制代码可靠得多。
5. 同步与发布的命令链：push 被拒之后，大部分真相都在这里
5.1 fetch 和 pull：不只是“拉一下远端”这么简单
很多人的概念里“同步远端代码”只有一句 git pull。但 git pull 实际上拆开是两个动作的合体：先 git fetch 把远端最新提交下载到本地一个“隐蔽角落”（远程跟踪分支），再 git merge（默认策略）把远端的最新变化合并到当前分支。对刚开始接触 Git 的人，我建议至少手动使用几次 fetch，你会更清楚“远端更新了什么”和“要不要合并”其实是两件事。
你可以在不改变当前工作区的情况下，执行：
bash复制git fetch origin
git log --oneline main..origin/main
第一句是拉取远端状态到本地；第二句用来查看“远端 main 有、但本地 main 还没有”的全部提交。看清之后决定怎么处理，对减少惊吓很有帮助。强行让本地落后的分支执行 merge，很容易出现一堆意外冲突。
5.2 push 被拒绝：先别慌，通常是你忘了把远端的变化拉回来
有一次团队里一位同事急冲冲跑过来喊“我的代码推不上去”，终端里反馈的一句消息大概意思是“远端有本地没有的提交，已拒绝更新”。这种情况的成因其实不复杂：你的同事在你最后一次拉取之后，已经抢在你前面往远端提交了代码；Git 为了不覆盖别人的提交，默认不允许你直接推进去。
正确的处理链路是：先把远端最新代码拉下来，解决冲突，再重新推送：
bash复制git pull --rebase origin main
# 如果出现冲突，解决并 add 后继续
git rebase --continue
git push
这里的 pull --rebase 是把本地已经提交但还没推出去的 commit 暂时摘下来，在拉取完远端最新 head 之后，再把你的提交重新放回最前面。好处是历史里不会多出一个“合并提交”，你的提交记录始终紧跟远端之后，看起来更干净。也有团队更喜欢 git pull（默认 merge 模式），生成一个合并提交更直观。关键在于别养成“无脑 git pull，冲突就乱改一通”的习惯，那样只会让本地产生大量重复的合并节点。
另外一个我反复踩过的坑是：不要在 main 分支上直接写容易冲突的代码，更不要让一个多人长期共用的分支长时间不更新。每周至少 fetch 两三次、及时把远端变动合并回自己的个人分支，推送时遇到的冲突会比攒了两三周再一次性处理小得多。
5.3 删除远程分支与保护主干的习惯
分支的清理和创建同样重要。功能上线、修复合并完成之后，远端保留大量陈旧分支会让项目列表杂乱无章。删除远程分支可以这么操作：
bash复制git push origin --delete feature/old-login
本地删除分支则用 git branch -d feature/old-login，其中 -d 会在分支未合并时阻止你误删；如果你想强制删除并放弃未合并内容，才会用 -D。
远程分支的“保护”一般是靠平台设置实现的，比如 GitLab/GitHub 上把 main 设成保护分支，直接 push 被拒绝，必须走合并请求。这样即使有人不小心把本地本地折腾乱了，也不太容易直接污染主干。许多团队默认不让个人直接推送 main，这种做法能有效挡住不少低级失误。
6. 历史回溯与撤销操作的“后悔药”：reset、revert、restore 该选谁
6.1 撤销的最小作用域：还没 commit 的改动，别急着祭出大招
“我改错了文件，想回到原来的版本，怎么办？”这是问得最多的问题。答案取决于**:文件改动的状态到底在哪一层**。
如果改动还在工作区里、还没 add，最快的撤销方式是：
bash复制git restore <file>
它会丢弃工作区对该文件的修改，恢复到跟暂存区/HEAD 一致的状态。注意这个动作不能找回被丢弃的内容，所以使用前务必确认不是自己刚写了几百行的心血。
如果改动已经 add 进暂存区，想取消暂存但不删除工作区里的修改，用：
bash复制git restore --staged <file>
这相当于“把文件从购物车里拿出来”，但其本身内容还在工作区，不会丢失。很多 Git 教程里还会提到老式的 git checkout -- <file> 和 git reset HEAD <file>，它们在旧版本中是标准操作；新项目使用新的 restore 系列更不容易产生混淆，因为语法语义更明确。
6.2 还没 push 的提交，用 reset 可以按照软、混、硬三档回退
如果提交已经生成了，但还没有推送到远端，此时想反悔，那么 git reset 比 revert 更合适。reset 提供三档强度，分别作用于不同目标：
| 模式 | 命令示例 | 影响范围 | 典型用途 |
|---|---|---|---|
| 软重置 | git reset --soft HEAD~1 |
保留工作区和暂存区改动，仅移动 HEAD 指针 | 想重新整理上一条提交，把提交拆成多个或者改它的 message |
| 混合重置 | git reset --mixed HEAD~1（省略模式时默认） |
保留工作区改动，清空暂存区 | 你刚发现刚才的提交太多了，想把相关改动拿出来重新分组 add |
| 硬重置 | git reset --hard HEAD~1 |
工作区、暂存区、HEAD 全部回退 | 只想彻底丢掉某些本地提交 |
HEAD~1 表示上一个提交，HEAD~2 表示上两个提交，也可以直接指定提交哈希。那个执行后没有回头路的 --hard 模式要格外小心，它会把工作区里所有未提交的改动一并抹掉。新手最典型的事故就是悔恨地打出 git reset --hard HEAD，然后发现几天的劳动成果全没了。在跑任何 reset --hard 之前，请先敲一遍 git status，再确认没有需要保留的未提交内容。
6.3 已经 push 到远端的提交，尽量用 revert 新建反向提交
已经推送出去的提交，进入团队的共享历史后，原则上是“不要改写”的。因为如果本地 reset 完又 git push --force 强推到远端，会把远端的历史往前拽，其他同事下次 pull 时可能直接产生大量冲突，或者出现提交丢失。
最稳妥的反悔方式是 git revert。它会新建一个“反向提交”来抵消目标提交的改动，不会破坏原本的历史：
bash复制git revert <commit-hash>
revert 执行后会生成一个新的提交记录，这个提交的内容恰好是把目标提交改过的所有内容撤销回去。然后你正常 push 这个反向提交，远端历史往前推进一格，目标 commit 仍然存在、但它的效果被一个反向 commit 抵消了。对团队协作来说，这种向后兼容的撤销方式几乎不会引发历史混乱。
如果你需要撤销的是已经推送的连续多个提交，可以考虑用一条指令生成多个反向提交再一起推送，或手动分次执行 revert 并保持顺序。在共享分支上，我极少用强推去“纠正历史”，因为强推只适合个人独享分支，放到团队分支上往往等于给所有人带来麻烦。
6.4 清理未跟踪文件：git clean 的高危与低频
git clean 的作用是删除工作区里所有未被 Git 跟踪的文件和目录。它配合 git reset --hard，可以让当前目录彻底回到某次提交的纯净状态。但它极少出现在日常操作中，因为危险性相当高——一旦执行，那些从未被跟踪的文件（日志、临时备份、本地配置）会被直接删掉，没有第二次机会。
如果真想用它，首先用 git clean -nd 先预览一下将要删除的文件清单，看清楚不会误删再执行 git clean -fd。当你面对的是一个乱糟糟的目录，想一键“恢复出厂设置”时，这套流程才算比较靠谱。
7. 与其背更多命令，不如花十分钟配一个顺手的本地环境
7.1 必需的基础配置：user 信息、默认分支名与换行符处理
大部分人在 git commit 时碰到的第一道坎是“Git 不知道你是谁”，这其实是本地配置没写。安装后建议第一件事就是配置身份信息：
bash复制git config --global user.name "你的名字"
git config --global user.email "you@example.com"
这里的 --global 表示这台机器上的所有仓库默认使用这套身份。如果你在公司的仓库里希望用公司邮箱，个人仓库用另一个邮箱，可以在某个仓库里不使用 --global 覆盖成局部配置：
bash复制git config user.name "个人网名"
git config user.email "personal@example.com"
另外两项对跨平台协作尤其重要的配置：
bash复制git config --global init.defaultBranch main
git config --global core.autocrlf input
第一项是为了避免 git init 时生成一大堆不受欢迎的 master 字样；第二项解决 Windows / macOS 换行符不一致的问题。Windows 上如果协作对象全是 Linux/macOS，建议把 core.autocrlf 设为 true 或 input 并配合团队的规范，否则你经常会遇到“我只改了一行，git diff 却显示整个文件被改动”的诡异现象。
7.2 顺手好用的 alias，以及一个我亲测多年的提交前工作流
如果每次都要敲一长串 log 参数，确实容易让人变懒。Git 支持给命令起别名，配置起来很轻松。我贴一段个人比较精简的配置，你可以按习惯调整：
bash复制git config --global alias.st status
git config --global alias.co checkout
git config --global alias.br branch -vv
git config --global alias.lg "log --graph --oneline --decorate --all"
git config --global alias.last "log -1 HEAD --stat"
git config --global alias.unstage "restore --staged"
有了这些别名，日常高频操作可以变成 git st、git co、git lg。这不算花哨，只是减少了输入成本，关键是让“查看状态、了解历史”这种防御性操作不再有心理负担。
最后分享一个我自己坚持了很多年的小流程，也算是对这篇文章的总结：每天早上开工先 git fetch 了解远端变化；动手新需求之前先开一个新的功能分支；开发过程中频繁 git status 和 git diff，但提交按逻辑拆成小粒度；推送前先确保本地已经跟远端同步；遇到不确定的撤销操作先查 git status，宁可慢一步也不要乱敲破坏性命令。这套流程把我从“Git 什么时候会炸”的焦虑里解放了出来。当你把常用的十几个命令和它们背后对应的状态变化都理顺了，Git 就不再是一堆需要背诵的单词，而是一套你每天都用得顺手的工具箱。