你的Git真的只用对了吗？
很多开发者用了几年Git，基本操作就是 add、commit、push、pull。遇到冲突就慌，代码丢了就哭。
今天分享5个Git的高级技巧，每个都是我从踩坑里总结出来的实战经验。学会之后，日常开发效率至少提升一倍。
技巧一：用 git log –graph 看清提交历史
默认情况下，git log 只是一行行平铺的提交记录。分支合并多的项目，根本看不出谁干了啥。
加上 --graph 参数，你会看到一棵清晰的提交树：
git log --graph --oneline --all
输出长这样：
* 3a2b1c9 (HEAD -> main) Merge branch 'feature/login'
|\
| * d4e5f6a 实现登录页UI
* | b7c8d9e 修复路由配置
|/
* e1f2a3b 初始化项目
进阶用法：加 -30 只看最近30条，加 --since="2 weeks ago" 只看两周内的提交。
git log --graph --oneline --all -30 --since="2 weeks ago"
这个命令是我每周回顾项目进度的标配。
技巧二：git stash 救急，比 commit 优雅多了
场景：你正在修一个bug，写到一半突然接到通知要紧急处理线上问题。
新手做法：先把当前修改 commit 一个"临时保存"，处理完再 revert。
高手做法：用 git stash：
# 保存当前工作区（包括未追踪的文件）
git stash push -u -m "修复登录bug进行到一半"
# 切换到紧急任务
git checkout main
git pull
# ... 处理线上问题 ...
# 回来继续干活
git stash pop
-u 参数会把新建但未跟踪的文件也存起来，-m 给这次保存起个名字，方便以后找回。
实用技巧：如果有多个 stash，用 git stash list 查看，用 git stash apply stash@{1} 恢复指定的那一次。
技巧三：git blame 揪出写烂代码的那个人
说实话，这个功能有点"不友好"，但非常好用。
当你看到一段逻辑混乱、变量命名奇葩的代码，想知道是谁写的、什么时候写的、为什么这么写：
git blame src/utils/formatDate.js
输出每一行前面的提交哈希和作者信息：
^a1b2c3d (张三 2025-11-02 14:23:00 +0800 1) // 初始化
b4c5d6e7 (李四 2026-01-15 09:45:12 +0800 2) export function formatDate(date) {
c7d8e9f0 (王五 2026-03-20 16:10:33 +0800 3) // TODO: 重构这段
进阶用法：
git blame -L 10,30 file.js—— 只看第10到30行git blame -C file.js—— 追踪代码是否被移动过（比如从其他文件拷过来的）git blame --porcelain file.js—— 输出机器可读格式，可以配合脚本批量分析
技巧四：交互式变基（rebase -i），整理提交历史
假设你提交了10次，每次都是"fix"、“wip”、“fix again"这种垃圾提交名。现在要提 PR，需要把历史清理干净。
用交互式变基：
git rebase -i HEAD~10
编辑器会打开一个列表，类似这样：
pick a1b2c3d 修复登录接口
pick d4e5f6a wip
pick e7f8a9b 继续修bug
pick f0a1b2c fix again
把不需要的行，把 pick 改成 drop 或删除；把相邻的几个小提交合并成一个，把第二个及以后的 pick 改成 squash。
改完后保存退出，Git 会自动重组历史。你可以给合并后的提交起一个好名字。
注意：只对还没有推送到远端的提交做 rebase。已经推送到 shared branch 的提交不要动，否则别人的历史会乱。
技巧五：git diff 三个隐藏参数，排查问题快十倍
git diff 是最常用的命令之一，但大多数人只知道 git diff 看当前改动。
这三个参数让你的 diff 功力提升一个档次：
1. --staged：看暂存区的差异
git diff --staged
很多人执行 git add 后就忘了自己加了什么。用这个命令可以确认暂存区的改动，避免 commit 错误的内容。
2. -W：只看函数级别的差异
git diff -W file.js
当一个大文件改了上百行，但核心变动只集中在几个函数里。-W 参数只显示有改动的函数范围，上下文大幅缩减，一眼就能定位关键变更。
3. --color-words：行内高亮差异
git diff --color-words file.py
普通 diff 是按行显示的，一行改了三个词你得来回对照。这个参数在同一行内用颜色标出增删的部分，适合快速对比小改动。
把这些技巧串起来：一个真实工作流
上面的五个技巧不是孤立的，它们可以组合成一个完整的日常开发流程：
- 开始工作前：
git log --graph -10看一下最近都在搞什么 - 工作中被打断：
git stash push -u -m "中断原因"优雅地保存现场 - Review 自己的代码：
git diff --staged确认暂存区没问题 - 提交后整理历史：
git rebase -i HEAD~N把零散提交合并成有意义的几个 - 回头看某段代码：
git blame了解上下文
这套流程走下来，你的 Git 操作会从"会用"升级到"用得专业”。
写在最后
Git 的命令确实多，但真正影响效率的核心就这几个。不需要背下来所有参数，挑一两个先用起来就行。
你平时最头疼的 Git 场景是什么？欢迎在评论区聊聊。