Git

三个区域

一切命令都围绕三个区域转：工作区（你正在编辑的文件）、暂存区 / 索引（git add 后的快照）、仓库（git commit 后的历史）。git commit 不带参数时只提交暂存区的内容，工作区里改了但没 add 的东西不会被带进去。

git add . 到底加了什么

这是最容易误解的一条。差别在于给了路径参数还是没给，以及有没有带 - 标志。

关键在最后两行的注释：-A 和 -u 不带路径参数时作用于整个工作区，官方文档明确写了「旧版本 Git 曾把它们限制在当前目录及其子目录」，但新版本不再如此。所以 cd 到子目录再 git add -A 和在根目录执行是等价的。

而 git add . 永远只看当前目录——在子目录里执行它，加不到父目录的改动。这是最常见的「我明明改了却没被加进去」。

还有个更细的点：给目录作路径参数时，Git 会把该目录的索引项整体更新为与工作树一致，因此目录下的删除也会被记录。

不想整个提交就挑着加

git add -p 逐块（hunk）询问，选 y 收下、n 跳过、s 拆得更细、e 直接改。这一条能避免「修一个 bug 顺手提交了半成品格式化」的常见麻烦。

另外 git add 只把执行那一刻的内容写进索引，之后再改还得再 add 一次。

回退的三种粒度

bash# 只把某个文件移出暂存区，内容不变
git restore --staged file.c

# 丢弃工作区的修改，回到最近一次提交的状态
git restore file.c

# 移动 HEAD，分三个级别
git reset --soft HEAD~1   # 改动留在暂存区
git reset --mixed HEAD~1  # 改动退回工作区（默认）
git reset --hard HEAD~1   # 改动全部丢弃，慎用

--hard 丢的是工作区里未提交的改动，没有确认提示。绝大多数情况下 --soft 或 --mixed 就够了。

被 --hard 误伤过还有救：git reflog 记录了 HEAD 的移动轨迹，找到那个哈希后 git reset --hard <哈希> 就能回到当时的状态。

换行符与忽略

跨平台协作必须配 core.autocrlf：Windows 上设 true，Linux/macOS 上设 input 或 false，否则同一份文件在两边提交会满屏都是整文件改动。仓库里可以放 .gitattributes 覆盖这个设置，它优先级更高。

bashgit config --global core.autocrlf input
printf 'node_modules/\n.env\n' >> .gitignore

git add 默认不添加被忽略的文件。 明确指定某个被忽略的文件名会让 git add 直接失败并列出它；给目录时则静默跳过。要强行添加得用 git add -f。

另一个坑：文件已经被跟踪之后，往 .gitignore 里加规则对它无效——忽略规则只对未跟踪的文件生效。这种要先 git rm --cached <文件> 取消跟踪，再提交一次。

rebase 与 merge

merge 保留真实历史，多出一个合并提交；rebase 把你的提交摘下来重放到目标分支顶端，历史是一条直线，但会改写提交哈希。

已推送的公共分支不要 rebase，别人已经拉走了你原来的哈希。要改写自己的历史用 git rebase -i 压成一条；只挑某几个提交搬过去用 git cherry-pick <哈希>。