企业官网建设流程全解析

简介：这是《GIT基本命令》Word文档，面向刚接触Git的开发者与运维人员，按实际工作流系统梳理分布式版本控制的高频操作。全书约349KB，内含1个docx文件，结构清晰，覆盖SSH密钥配置、仓库克隆与更新、代码提交与还原、分支管理、远程仓库同步、冲突解决、标签操作、stash暂存与rebase等核心主题，每一类均配有可直接复制的命令示例，适合作为日常开发中的速查手册。已有378人学习参考，对于希望快速上手Git并减少版本管理踩坑的新手而言，这份要点式笔记能帮助快速建立操作框架，并在合并分支或回滚版本时提供明确指令依据。

1. 为什么说 GIT 基本命令不是“commit + push”？从一次备份事故说起

有一次帮同事救代码，他把项目提交到本地仓库，以为已经备份了；可他把整个依赖目录和本地配置都加了进来，远程推不上去，推上去也是一堆无用文件。问题出在他把 GIT 基本命令理解成“记住几个动词”，完全没意识到这些命令操作的是三个不同的区域：工作区、暂存区和仓库。真正的基本命令是一条从git init到git status、git add、git commit，再到branch、merge、pull、push的状态转移链。熟练的人不是背下来的，是看一眼git status就知道下一步该用哪个命令。这篇按本地、分支、远程三条线讲清命令的边界和参数，并把新手最容易翻车的几个场景单独列成避坑清单。适合刚装好 Git 却不敢乱动历史、以及要给新同事做技术普及的人。

2. 本地三区闭环：从 git init 到 git commit 的每一步都不该省

GIT 基本命令的本地部分，本质上是在“工作区 / 暂存区 / 仓库”三个区域之间做状态转移。工作区就是你在编辑器中看到的文件；暂存区是 Git 内部用 index 文件维护的一份清单，记录“下一次提交里要包含哪些内容”；仓库才是已经挂进版本历史的提交对象。对新人，这三个区域分不清，commit 就成了黑匣子，出了问题也只能靠猜。

2.1 git init 与首次配置：先解决“你是谁”再动手

很多人装好 Git 之后第一件事就是git init，然后写代码、git add .、git commit，结果提交记录里全是“unknow”。原因不是命令错了，而是没配置提交者身份。Git 每次提交都会把user.name和user.email写进 commit 对象，不配置的话，Git 会直接拒绝生成提交，并提示你去设置身份。

# 在项目根目录初始化仓库，生成 .git 目录 git init # 配置提交者姓名和邮箱，--global 表示对当前用户所有仓库生效 git config --global user.name "Your Name" git config --global user.email "you@example.com" # 查看当前仓库实际生效的配置 git config --list

逻辑很简单：git init只是生成了一个.git目录，这个目录就是版本库本体，所有历史、分支、配置都装在里面。git config把身份写进~/.gitconfig。如果你只在一台电脑上工作，--global就够了；如果公司仓库和个人仓库需要不同身份，就不要加--global，而是进到某个仓库里单独设置，这样优先级更高。

git config的配置级别有三级：--system、--global、--local。生效优先级是 local > global > system，也就是说在某一个仓库里单独设的user.email会覆盖全局配置。我一般建议团队在 README 里写明必填配置，避免有人拿自己邮箱提交到公司仓库。另外一个很实用的小命令是git config user.name，它只读当前身份，不打开整个配置文件。

第一次提交前，还应该顺手建好.gitignore。依赖目录、编译产物、日志和本地环境配置都不要进版本库，不然第一次git add .就会把一堆垃圾带进去。可以用下面这种方式快速验证忽略规则：

# 先写忽略规则再 add，比事后清理省事得多 echo "node_modules/" > .gitignore echo "*.log" >> .gitignore # 查看某文件是否正被某条规则忽略 git check-ignore -v node_modules/pkg/index.js

git check-ignore -v会精确告诉你这个文件被哪一行规则挡住，排查“为什么 add 不进去”的时候非常好用。注意，忽略规则只对未跟踪文件生效；已经被 Git 跟踪的文件，就算写进.gitignore也照样会被提交。要想让它停止跟踪，得用后面避坑章节里说的git rm --cached。

2.2 git add 的三种姿势与暂存区本质

在三个区域里，暂存区是最容易被跳过的一个。很多人的习惯是git add .然后git commit，完全不管中间这层 index 到底记了什么。git add做的事不是复制文件，而是把当前工作区文件的内容生成一个 blob 对象，并把这个对象的路径和哈希更新到索引里。换句话说，暂存区是“下次提交的照片草稿”。

# 暂存所有改动，包括删除和新文件（符合 .gitignore 的除外） git add -A # 只暂存当前目录及其子目录的变化 git add . # 只暂存已经被 Git 跟踪的文件修改和删除，不处理未跟踪的新文件 git add -u # 逐块检查后暂存，适合拆分提交、避免夹带敏感信息 git add -p # 查看简化状态，第一列是暂存区，第二列是工作区 git status --short

git add -A、git add .、git add -u这三个命令很多人以为差不多，实际上有区别。-A是整个工作树，无论你在哪个子目录执行，都会把全仓库的变化纳入进来；.是把当前目录及其子目录的变化纳入进来；-u只处理已经被跟踪文件的改动和删除，新文件不会进暂存区。日常开发里，我习惯用git add -A做一次全量暂存，再用git status --short确认没有携带异常文件。

git status --short的输出是两列符号。左边表示暂存区状态，右边表示工作区状态。比如M file表示文件已修改但还没提交到暂存区，MM file表示暂存区里有一版修改，工作区里又改了一版。这也是一个常见翻车点：你先git add了一次，然后又改了文件，结果 commit 提交的是旧版本，新改动还在工作区里。所以代码改完不要只 add 一次，提交前再看一眼状态。

git add -p是一个被严重低估的命令。它会把文件里的改动按 hunk 拆开，让你逐个选择是否暂存。遇到一个大文件里混着两件事，比如一个功能改动和一个日志输出，就能用-p把它们拆成两个提交。按y暂存当前块，按n跳过，按e编辑块内容。新手第一次用可能会觉得界面奇怪，但拆提交时它是最好用的后悔药之一。

2.3 git status 和 git diff：提交前一定要看的两个命令

我见过不少开发者的提交习惯是“改完直接 commit”，从来不跑git status和git diff。这样做的结果就是提交信息写得跟实际改动对不上，或者把调试代码提交上去自己都不知道。git status是看全局状态，git diff是看具体内容改动，两者加起来才是一个完整的提交前检查。

# 查看文件整体状态，包括未跟踪、已暂存、未暂存 git status # 工作区 vs 暂存区：看还有哪些修改没 add git diff # 暂存区 vs 仓库：看这次将要被 commit 的内容 git diff --cached # 工作区 vs 仓库：看相对上次提交的全部改动 git diff HEAD # 只看改动涉及哪些文件，不展开具体内容 git diff --name-only

git diff默认比较的是工作区和暂存区，所以它可以回答“我改了什么但还没 add”。git diff --cached比较的是暂存区和当前提交，也就是“提交按钮按下去之后，仓库会多出什么”。提交前最该看的不是git diff，而是git diff --cached，因为这才是 commit 真正会用到的内容。如果你想看从上次提交到现在的全部变化，包括已暂存和未暂存的，那就用git diff HEAD。

git status的完整输出还会提示分支领先或落后多少，这在本地开发时很直观。比如Your branch is ahead of 'origin/main' by 2 commits，说明本地有 2 个提交还没 push。这个提示比你自己去记状态可靠得多。

最后一步就是提交。git commit -m "feat: add user profile page"是最简单的写法。如果不带-m，Git 会打开默认编辑器让你写提交信息，很多新手第一次看到 vim 就愣住了，不知道怎么退出。可以在安装配置时顺手设置成 VSCode 或别的编辑器：

git config --global core.editor "code --wait" git commit -m "feat: add user profile page"

提交信息不是随便写几个字就完事，基本格式是“做什么 + 为什么”。比如feat: 调整模块结构比更新了有用得多。团队里如果有人把提交信息全写成“fix”，过两个月看git log谁都看不懂。这个习惯不用等团队规范，自己先执行就有价值。

3. 分支与合并：把 GIT 分支合并从“乱套”变成可预期的操作

GIT 基本命令到了分支这一层，才开始真正体现出它的价值。没有分支，所有代码都在一条时间线上，改错一个地方就是连锁反应。分支合并在线工程里每天都会发生，但不少人对merge、rebase、cherry-pick之间的关系说不清楚，于是遇到冲突就只能靠复制文件来“硬合并”。这一章的目标是让你做完一次分支合并后，不用靠猜。

3.1 创建、切换与删除：branch、switch 和 checkout 的正确分工

分支在 Git 里只是一个 40 位哈希的引用，指向某个 commit。创建分支就是在这个指针上贴一个新名字，成本极低。所以 Git 鼓励你多开分支，而不是等一个大功能快做完了才开分支。基础命令有三个：git branch用来创建和删除，git switch用来切换，git checkout是老版切换命令但身兼两职。

# 基于当前分支创建一个新分支 git branch feature # 切换到已有分支 git checkout feature # 推荐使用语义更纯粹的 switch 命令 git switch feature # 创建并切换 git switch -c feature # 删除已经合并过的分支，安全删除 git branch -d feature # 强制删除未合并分支，仅在你确定这些提交不要了的时候用 git branch -D feature

为什么推荐git switch？因为老命令git checkout既用来切换分支，也用来恢复文件，比如git checkout -- file会把工作区文件还原成暂存区状态。这两个动作是相反的语义：一个是改 HEAD 指针，一个是改动工作区内容。命令混在一起，新手容易把刚写的代码 checkout 掉。从 Git 2.23 开始，官方拆出了git switch和git restore，建议新项目直接教这两个。

切换分支时有个很容易踩的坑：如果工作区里有未提交的改动，而目标分支和当前分支对同一个文件的状态不一致，Git 会拒绝切换，报错提示“Your local changes would be overwritten”。这不是 Git 不让你切换，而是它不想替你决定怎么处理这些未提交内容。解决方式要么git commit，要么git stash暂存。跨界切换前先看一眼git status是基本素养。

git branch -d与-D的区别也值得记住。-d会检查待删除分支上的提交是否已经被合并；如果没合并，它拒绝删除，防止你丢提交。-D是跳过这个检查的强制删除。我建议日常多用-d，只有当你确认这个分支彻底没用了，才用-D。删除分支只是删掉名字，commit 对象不会立刻消失，但如果不做任何追溯，它们就真的变成孤儿了。

3.2 merge 和 rebase：两种整合方式怎么选

分支合并有两种常用手段：git merge和git rebase。它们的最终结果都是把一个分支的改动整合到另一个分支，但产生的历史形态完全不同。很多团队冲突不在代码上，而在“应该用 merge 还是 rebase”的认知上。我的判断标准很简单：要看这个提交是否已经被别人拉走，公共分支用 merge，纯本地私有分支可以用 rebase。

# 先切到集成分支 git switch main # 如果 main 没有新提交，会直接快进到 feature 的提交 git merge feature # 强制生成一个合并提交，保留“功能分支存在过”的痕迹 git merge --no-ff feature # 把 feature 上的提交重放到 main 最新提交之后 git switch feature git rebase main

先解释快进：当 main 从创建 feature 之后一直没有新提交，那么 merge 就是把 main 这个指针直接挪到 feature 所在的提交上，没有新增 commit，这就是 fast-forward。大多数情况建议用git merge --no-ff，它能强制产生一个合并提交，把“什么时候把功能合进来的”这个节点明确写在历史上。如果直接快进，feature 的提交会平滑拼进 main，看起来像一直在 main 上开发，后面 review 代码时会缺少一个合并边界。

git rebase做的事情则是把 feature 上的提交摘下来，重新挂到 main 的最新提交之后。commit 的内容没变，但 commit 的哈希会全部改变，因为父提交变了。对纯本地分支来说，rebase 可以避免产生大量合并提交，让历史变成一条干净的线。但一旦其他人已经从这个分支拉过代码，rebase 重写历史会让对方的仓库出现两条不一致的开发线。

团队协作时，公共分支上的提交也不要随意 amend。已经推送过的提交被 amend，等于变成了另一个提交对象，所有人下次 pull 都会产生分叉。正确做法是新增一个提交来修正问题，或者用回滚命令。记住一句话：merge 保留历史，rebase 整理历史，但重写历史是要付出代价的。

3.3 冲突不等于翻车：一次冲突解决的完整命令流

很多人第一次看到CONFLICT (content): Merge conflict in main.go就慌了，觉得自己把代码弄坏了。其实冲突只是 Git 的一种提示：两个分支对同一个文件的同一块区域做了不同修改，Git 不知道哪个才对，所以把决定权交给你。冲突不可怕，真正可怕的是用“复制粘贴整个文件”来绕过冲突。

假设你在main分支上改了config.yaml的一行，你的同事在feature分支上也改了同一行。你切回 main 执行git merge feature，Git 会报冲突。这时先不要乱动，执行git status，你会看到文件状态是both modified，这意味着两侧各自有改动：

git switch main git merge feature # 假设冲突出现，查看冲突文件清单 git status

打开冲突文件，你会看到类似<<<<<<< HEAD、=======、>>>>>>> feature的标记。<<<<<<< HEAD和=======之间是当前分支（main）的内容；=======和>>>>>>> feature之间是 feature 分支的内容。你要做的不是把其中一个删干净，而是判断保留哪个、修改哪个，最后把三个标记行全部删掉。

# 编辑完冲突文件后，标记为已解决 git add . # 继续完成合并提交 git merge --continue # 如果中途决定放弃合并，回到 merge 之前状态 git merge --abort

git merge --continue会打开编辑器让你确认合并提交信息，默认信息已经很完整，直接保存退出即可。要注意的是，git add .之后冲突状态就解除了，但 Git 不会校验你是否真的解决正确，只会记录你的决定。所以合并完要立刻把相关文件打开看一眼，跑一遍测试或编译，再推远程。

git merge --abort是合并操作的后悔药。如果冲突太多，或者发现合错分支了，--abort会把工作区和索引恢复到 merge 之前的样子，看起来什么都没发生过。还有一个相关命令git merge --quit，它只退出合并流程而不回滚，适合你手动解决了冲突但不想启动编辑器的情况。建议每个新人都把这三个命令背下来：add、continue、abort。

4. 远程协作：push / pull 之前把 GIT 基本命令再捋一遍

本地命令再熟，一旦接上远程仓库，就会多出一层“本地分支和远程分支”的对应关系。远程协作的关键不是记住push和pull这两个动词，而是理解fetch、remote、origin这些概念。很多人在 SSH 认证失败上反复折腾，其实问题不在网络，而在没有理顺本地和远端的连接配置。

4.1 从 clone 开始，还是手动 init 后接 remote？

接远程仓库有两条路：一种是用git clone把别人已有的仓库复制下来；另一种是本地已经用git init建好了仓库，再手动关联远程地址。这两条路的命令不一样，选错就会在git remote add之后收到 “remote origin already exists” 的提示。

# 在已有远程仓库的基础上开始，地址用 SSH 格式 git clone git@github.com:user/repo.git # 本地已有仓库，手动关联远程地址 git remote add origin git@github.com:user/repo.git # 查看当前仓库关联了哪些远程地址 git remote -v

git clone会做三件事：把远程仓库的提交下载到本地、默认创建一个名为origin的远程别名、把远程分支记录到refs/remotes/origin/下。所以你 clone 完不用再git remote add，直接git status就能看到本地分支和 origin/main 的关系。如果你现有本地仓库已经写了代码，不要在 clone 新仓库之后把文件复制过去，正确的做法是在托管平台建一个空仓库，然后执行git remote add origin <地址>。

git remote -v是排查远程故障的第一步。它会显示当前仓库绑定的所有 fetch 和 push 地址。有时候我们想切换远程地址，比如从 HTTPS 改成 SSH，可以用：

# 修改已有远程地址 git remote set-url origin git@github.com:user/repo.git

很多 SSH 认证失败其实是绑定的地址协议不对。HTTPS 方式要求用户名密码或 token，SSH 方式要求密钥。用git remote -v看一眼 URL 前缀，能省掉大量排查时间。另外，不要在仓库里保存远程地址中带密钥的 URL，尤其是.git/config会明文记录这部分信息，提交历史里一旦出现密钥就应该视为泄露并立即更换。

4.2 fetch 与 pull：先看清楚再合并

git pull可以看作两个命令的组合：先git fetch，再做一次git merge。但组合在一起后，它掩盖了一个重要事实：fetch 本身是不会改变你当前工作区和本地分支的。很多冲突之所以发生，是因为用户直接 pull，没看清远程到底改了什么，就自动进入合并流程。

# 只拉取远程更新，不合并到本地分支 git fetch origin # 查看 main 与 origin/main 之间的提交差异 git log --oneline main..origin/main # 查看具体文件差异 git diff main origin/main # 只允许快进式拉取，如果分叉就失败 git pull --ff-only # 用 rebase 方式拉取，避免产生多余合并提交 git pull --rebase

git fetch拉取下来的远程状态在origin/main这个引用里。你可以把origin/main当作一个只读的追踪分支，用来对比“远程已经到哪了、本地还没到哪”。git log main..origin/main表示“查看仅在 origin/main 上出现的提交”，也就是远程有的、本地没有的提交。看完之后你再决定是git merge还是git rebase。

git pull --ff-only是个很安全的设置：如果本地分支没有产生分叉，就直接快进到远程最新状态；如果本地有独立提交，它宁可失败也不生成一个莫名其妙的合并提交。这对集成分支很有用。git pull --rebase则是把本地未推送的提交重放到远程最新提交之后，适合功能分支。两者的选择原则跟第 3 章 merge/rebase 一致：公共集成分支别乱 rebase，个人功能分支优先 rebase。

如果你正处于“改了代码但还没提交，临时需要 pull”的状态，可以直接用git pull --rebase --autostash。它会先把未提交的改动藏起来，完成 rebase 后再弹回来，这比你自己手动git stash再 pop 更省事。不过这个命令不要在第一次 pull 时就拿来用，最好先理解 stash 的机制，出了问题才知道怎么恢复。

4.3 push 的安全行为和 SSH 认证失败排查

git push是把本地分支的提交上传到远程分支。它也有一个快进要求：如果远程分支已经出现了本地没有的提交，Git 会拒绝推送，报错提示non-fast-forward。这是保护机制，防止你用本地旧历史覆盖远程新提交。遇到这种拒绝，先fetch看差距，再 pull，不要直接--force。

# 第一次推送时设置上游关联，之后可以直接 git push git push -u origin main # 查看本地分支和远程分支的关联关系 git status -sb # 强制推送的保守替代方案，只在远程没有变化时生效 git push --force-with-lease

-u的作用是把本地分支的 upstream 设置成origin/main，之后直接git push就不带参数了。git status -sb的输出里会显示[ahead 1]这样的标记，一眼就能看出本地领先或落后多少。--force-with-lease是强制推送的安全版本：它会先确认远程分支的状态还和你上次 fetch 到的一致，才允许覆盖；如果远程已经被别人改动过，它就拒绝执行。这个机制比git push --force多一层保险，我基本只在重开公共 CI 时才考虑使用。

SSH 认证失败是安装配置教程里最常见的问题。表现有很多种：clone 时提示Permission denied (publickey)，或者ssh: connect to host ...超时。最常见的场景是本地生成的公钥没有添加到托管平台。

# 测试 SSH 连接是否成功 ssh -T git@github.com # 如果提示没有加载密钥，启动 ssh-agent 并添加私钥 eval "$(ssh-agent -s)" ssh-add ~/.ssh/id_ed25519 # 查看公钥内容，复制到托管平台的 SSH Key 列表 cat ~/.ssh/id_ed25519.pub

ssh -T是一个测试连接命令，连接成功后托管平台通常会返回一句欢迎语，然后退出，这是正常的。ssh-add把私钥加载进内存，如果提示No such file，说明私钥路径不对，先确认你生成的是id_ed25519还是id_rsa。多台电脑或不同账号切换时，还会遇到 “remote origin already exists” 或 “please make sure you have the correct access rights” 的提示，这时可以检查git config --list，看当前仓库绑定的账号身份是否对应正确的密钥。密码忘了一点不丢人，密钥和远程地址才是真正的主角。

5. Git 基本命令避坑：5 个让新手破防的场景与自查方法

基本命令不难，难的是在出错时知道是哪条命令的副作用。下面这 5 个场景是团队日常提问里最常见的，全都按“现象 → 原因 → 解决”拆开讲。读完以后你不需要背住所有参数，只需要记住一个原则：凡是会覆盖历史或工作区的命令，执行前先看一眼git status。

5.1 第一坑：提交时把独立文件、日志和密钥一起推上去了

现象：第一次提交时执行了git add .，结果node_modules、dist、.env全进了仓库，推上去之后远程仓库变得巨大，甚至有可能因为一份.env泄露了内部地址。

原因：git add .会把当前目录下所有没有被忽略的文件都纳入暂存区，包括配置文件、构建产物和各种日志。.gitignore没建立或者建立太晚，Git 不会主动帮你识别“不该提交的文件”。

解决：把.env这类文件从 Git 跟踪列表里移除，但保留在本地磁盘上，然后提交这次移除动作：

# 把 .env 写进忽略规则 echo ".env" >> .gitignore # 停止跟踪但保留本地文件 git rm --cached .env # 查看改动，确认 .env 已不在跟踪列表 git status --short

git rm --cached是把文件从索引里移除，工作区文件不会受影响。提交之后，远程仓库里的.env仍然会留在历史记录中，所以如果里面是真实密钥，光删掉还不够，要更换密钥。新建项目时，我建议第一份提交只放.gitignore和 README，先确认忽略规则生效，再开始写业务代码。

5.2 第二坑：在公共分支上顺手 commit --amend，把同事的历史搞乱

现象：你在 main 分支上提交了一个修复，然后发现提交信息写错了，执行git commit --amend修改后推送到远程，其他同事拉取时出现两条历史，甚至 push 被拒绝。

原因：git commit --amend的本质是重新生成一个提交对象，新对象的哈希和原来完全不同。它只是把“当前提交”替换成了“另一个提交”，如果原来的提交已经被其他人拉走，那么重写会让两边历史无法对上。

解决：--amend只适合本地还没推送的提交，或者只属于你一个人的私有分支。公共分支上的提交信息写错，用git revert追加一条新提交来修复，而不是修改原提交：

# 追加一个反向提交，保留原始历史 git revert HEAD

git revert HEAD会生成一条新提交，内容正好抵消上一次修改。这样做的代价是历史里多了一条记录，但团队其他人的仓库不会产生分叉。记住这个边界：重写历史前先问一句“这个提交有没有被别人看到过”，看到过就不能改。

5.3 第三坑：reset --hard 把未提交的改动一起抹掉了

现象：写了半天代码，打算撤掉一次提交，执行了git reset --hard HEAD，结果工作区里的未提交改动全没了，连新建文件也消失了。

原因：git reset --hard的作用不只移动 HEAD 指针，它还会把暂存区和工作区一起重置到指定状态。任何未未提交、未暂存的改动都会被直接覆盖掉。更惨的是，未被 Git 跟踪的新文件根本不进入索引，reset 对它们不理不睬，所以也无从恢复。

解决：执行危险命令之前，先把当前改动存起来：

git stash git reset --hard HEAD git stash pop

git stash会把工作区和暂存区的改动保存到一个临时栈里，然后让你在一个干净状态下做 reset，最后用git stash pop把改动恢复回来。如果已经执行了 reset 才发现问题，赶紧用git reflog找到 reset 前的 HEAD 位置，再git reset --hard回去。但未被跟踪的文件仍然救不回来，所以我对新人只有一条建议：重要工作要么提交，要么持续备份，拖越久越危险。

5.4 第四坑：git pull 默认合并，把分支图搞得像蜘蛛网

现象：明明只是拉取远程更新，却生成了一堆Merge branch 'main' of ...这样的提交，分支图看起来十分混乱，但代码没有任何冲突。

原因：git pull默认执行的是 fetch + merge。如果本地和远程在同一个分支上各自都有新提交，Git 会直接生成一个合并提交来把两边串起来。这个提交本身无害，但对集成分支来说会污染历史。

解决：拉取时明确告诉 Git 你要线性历史，或者在全局配置里改掉默认行为：

# 当前命令：只允许 fast-forward，分叉就报错 git pull --ff-only # 通用做法：把 pull 的默认策略改为 rebase git config --global pull.rebase true

改成pull.rebase true后，git pull等价于git pull --rebase，本地尚未推送的提交会被挪到远程最新提交之后。这样分支线是平滑的。要注意，如果本地提交和远程提交改动了同一段代码，rebase 过程中同样会触发冲突，解决方式和 merge 冲突一样，解决后执行git rebase --continue。不要因为怕冲突就退回默认 merge，冲突本身不是需要消除的问题。

5.5 第五坑：大小写重命名和换行符差异，Git 假装没看到

现象：把README.md重命名为readme.md，执行git status却没有任何变化；或者同一个文件在 Windows 和 Linux 上来回编辑后，Git 显示整份文件都被修改，实际上只改了一行。

原因：Git 默认会继承文件系统的大小写行为。在 Windows 和 macOS 上，文件系统通常不区分大小写，所以 Git 不会把一个只改了大小写的文件视为修改。换行符则是由于core.autocrlf在各机器上配置不一致，Windows 用 CRLF，Linux/macOS 用 LF，Git 在 diff 时把换行符差异也算进了修改里。

解决：先消除这两类“看不见的差异”。想让 Git 跟踪大小写重命名，在大小写不敏感的文件系统上可以绕一段改名操作：

git mv README.md README2.md git mv README2.md readme.md

换行符则需要团队统一配置。拉取时让 Git 把远程内容转成 LF，提交时按仓库里的规则处理，最稳妥的是在仓库里放一份.gitattributes文件，把文本文件的行尾固定下来。如果历史里已经混入了大量 CRLF，可以执行git add --renormalize .来重新规范化。注意，这个操作会改动很多文件的索引状态，执行前必须让团队知道，最好单独用一个提交来完成，避免和其他代码改动混在一起。

6. 进阶技巧：用 log 和 reflog 给每一次 Git 操作留后悔药

命令越学越多，真正能让你在意外发生时不慌的反而是两个读状态的命令：git log和git reflog。git log看的是提交历史，而git reflog看的是本地每次 HEAD 移动的操作记录。即使一个分支被删了，被 reset 了，只要操作发生在这台电脑上，reflog 里通常都还留着痕迹。

# 查看分支图和提交位置，-all 包含远程跟踪分支 git log --oneline --graph --all --decorate # 看最近 10 次本地 HEAD 操作记录 git reflog -10 # 找到被 reset 掉之前的 HEAD@{2} git reset --hard HEAD@{2}

git log --oneline --graph是快速观察分支结构的首选。--graph用字符画出提交拓扑，--decorate会在提交旁标注分支和标签名。git reflog则更像一份本地操作流水账，每条记录都带有HEAD@{n}这样的位置标记。假如你误执行了git reset --hard HEAD~1，reflog 会记录 reset 之前的提交位置，直接git reset --hard HEAD@{2}就能退回原状。

我自己的习惯是，每次觉得“操作乱了”，第一个动作不是执行撤销，而是先跑git status和git log --oneline -5。看完这两项，再打开git reflog判断要回退到哪个点。这样做的次数多了，你会发现大多数翻车其实都能在提交之前拦住。

还有一个我一直保留的习惯：提交前一定会看git diff --cached，确认将要提交的内容和提交信息完全对应。这个动作比任何命令都重要，它让我避免过无数次把临时调试代码提交上去。记住，Git 基本命令不是“背得越多越强”，而是“状态看得越清越稳”。希望这些命令和踩坑记录能帮你在下次操作前少走一段弯路。

本文还有配套的精品资源，点击获取