我有一支技术全面、经验丰富的小型团队，专注高效交付中等规模外包项目，有需要外包项目的可以联系我
老实说，Git 对大部分人来说， 一开始就像一个脾气很坏的上司： 一旦你命令敲错，它就用一大段英文吓你。
但神奇的是——当你真正吃透一小撮核心命令和工作流之后：
- 提交不再手抖
- 回滚不再流汗
- 改需求、救线上、切分支都能游刃有余
下面这 15 个 Git 功能， 不是那种“看起来很高级但一年用不到一次”的冷门技巧， 而是每个在写真实项目的人，都应该熟到能闭眼敲出来的武器库。
1. Git Branching：不给自己开分支，就等着在 main 上裸奔
分支的意义其实只有一句话：
在不污染主干代码的前提下，放心搞事。
最常用的一句：
git checkout -b feature/login它会帮你：
- 从当前分支拉出一个新分支
- 让你在
feature/login上放心改代码、乱提交
现代团队里的各种工作流—— Git Flow、trunk-based、feature 分支模式，全部都是围绕“分支”在设计。
不会用分支 = 在生产环境桌子上直接改 SQL。 危险程度差不多。
2. Git Stash：有人喊“快切一下分支”的时候，你的救命抽屉
场景你一定经历过：
- 你在一个分支上改得飞起
- 这时候有人说：“你先拉一下最新代码，我刚修了个线上 bug。”
- 但你手上的改动还没写完，也不想现在就 commit
这时候，git stash 就是你的临时收纳箱：
git stash # 把当前未提交的修改暂存起来
git stash pop # 取回来，重新应用到当前工作区你可以：
git stash暂存当前改动- 切分支、拉代码、修问题
- 再切回原分支，
git stash pop把自己刚才的半成品捞回来
关键点：它不是帮你“提交”，而是帮你“先藏起来，稍后继续改”。
3. Git Rebase：把乱七八糟的历史，压成一条“假装自己一直很清醒”的直线
rebase 做的事情， 简单粗暴地说就是：
重写历史，让你的提交记录看起来干净、线性。
常见用法：
git rebase main意思是：
- 把你当前分支上的提交，
- 按顺序“搬运”到
main最新进度之后 - 让历史看起来像是你从来就是在最新代码上进行开发的
好处：
- 提交历史非常清爽、没有各种 merge commit 杂音
- review 时更容易看清每一步改了什么
但也要记住：
千万别随便 rebase 已经推到远程、大家都在用的公共分支。不然，你会变成别人心目中那个“乱改历史的人”。
4. Git Merge：不想动历史？那就老老实实合并
如果说 rebase 是一个“历史整形医生”， 那 merge 就是一种比较老派、但非常稳的方式：
git merge feature/login它会：
- 保留两个分支的原始提交记录
- 在合并点生成一个新的“合并提交”
适用场景：
- 团队协作、大家都已经基于这些提交干了很多事情
- 比起“历史整齐”，你更在意“绝对安全、不乱动大家的记录”
一句话：
- 追求干净历史 →
rebase - 追求绝对安全 →
merge
5. Git Cherry-Pick：热修复专用的“点菜模式”
cherry-pick 就像是去提交历史菜单上点菜：
“我只要那一条，不要整个分支。”
用法：
git cherry-pick <commit-hash>效果：
- 把某个特定提交（通过 commit hash 找到）
- 原封不动复制到当前分支上
最常见场景：
- 你在一个开发分支上修了一个 bug
- 线上版本也有同样问题，但你不想把整个开发分支合并上去
- 这时候，只把那条修 bug 的 commit cherry-pick 到线上分支就行
救火的时候，真的很好用。
6. Git Reflog：所有开发者迟早会磕头感谢的一台“时间机器”
命令错敲、reset 乱用、分支删多了…… 总有那么一刻，你会想：
“完了，我刚刚把好几年的人生删了。”
然后就是眼前一黑。
这时候，git reflog 出场：
git reflog它能帮你看到：
- Git 在本地记录下的所有 HEAD 变动历史
- 包括你 checkout、reset、rebase 的各种操作
你就可以：
- 找到你“误删之前”的那一个状态
- 用它的 hash 把自己救回来
非常多的人，在用 Reflog 之后都会发誓： 再也不乱说“Git 把我东西搞丢了”。
因为很多时候： 不是 Git 丢了，是你忘了怎么找。
7. Git Reset（Soft / Mixed / Hard）：撤销提交的三种力度
reset 是一把锋利的刀。 用好了，爽； 用坏了，血压飙升。
它有三种常见模式：
git reset --soft HEAD~1 # 撤回上一次提交，但保留修改，且保持在暂存区
git reset --mixed HEAD~1 # 默认模式，保留修改，不在暂存区（unstaged）
git reset --hard HEAD~1 # 直接把代码和提交都回滚，改动彻底丢弃简单理解：
- soft： “我后悔这次 commit，但代码还想留着继续改。”
- mixed（默认）： “把提交撤了，改动还在，但不帮我暂存了。”
- hard： “这一切都是梦，统统删掉，当我从没改过。”
警告一次：
--hard真的要慎用。 用之前先确保：这些改动你真的不想要了。
8. Git Amend：最后一条 commit 打错字了？不用再多一条“修正提交”丢人
新手常见画面：
- 刚提交完，发现少加了一个文件，或者 commit message 打错了
- 然后又补一条：
fix typo、update之类的没营养提交
其实，你完全可以优雅一点：
git commit --amend它会让你：
- 修改上一条提交内容（比如加上遗漏文件）
- 或者只改提交信息
效果相当于：
“把上一条 commit 重新包装一下，别再多出一条丑丑的记录。”
注意： 已经 push 到远程的 commit，再用 amend 就会改历史，出了问题你自己扛。
9. Git Blame：查 bug 时的“谁动了我的代码”雷达
git blame 的名字很“搞事”， 像是专门用来找人背锅的。
实际上，它更像一个：
“这行代码是何时、为何、由谁写下的历史注脚。”
用法：
git blame file.js你会看到：
- 每一行是谁改的
- 对应的 commit 是哪一个
- 大概是什么时间
最常见用途：
- 排查某个行为为什么这么设计
- 想找到这块逻辑的“原作者”，去问清楚背景
用它查历史，而不是用它当“甩锅工具”。 这是团队和谐的基本素养。
10. Git Tag：认真做版本管理的项目，都离不开它
Tag 的意义，是在历史上插一面小旗：
“这里是一个稳定版本，可以给别人用。”
例子：
git tag v1.0.0
git push origin v1.0.0常用于：
- 标记发布版本（
v1.0.0、v2.3.1等） - 给 CI/CD 用来触发构建和部署
- 将来需要回滚时，有清晰的落点
认真对待你的 tag， 等你有一天要做紧急回滚时， 会发现这是你给自己种下的唯一一点温柔。
11. Git Diff：别再“凭感觉提交”，看看自己到底改了什么
git diff 是那种每天都该敲几次的命令。
git diff # 当前工作区 vs 暂存区/最近提交
git diff main..feature # 两个分支之间的差异它能帮你：
- 在 commit 之前，确认自己改了哪些内容
- 做 code review 前，先对改动有个全局认识
- 查出哪些变更是“手滑带进去的”
不要盲目地 git add . 然后直接 commit。先 diff 一眼，是对自己和别人负责。
12. Git Log（带格式）：谁都讨厌又长又丑的提交列表
默认的 git log，信息是全的， 就是——很难一眼看出重点。
解决方案：加点“美颜”：
git log --oneline --graph --decorate --all效果：
- 一行一个提交（
--oneline） - 带分支图结构（
--graph） - 显示分支、tag 等信息（
--decorate） - 查看所有分支的历史（
--all）
建议直接在 .gitconfig 里整一个 alias：
[alias]
lg = log --oneline --graph --decorate --all以后只要：
git lg一整份提交历史就清清楚楚地挂在眼前。
13. Git Pull vs Git Fetch：别再以为它俩是一个东西
很多人用 Git 的时候， 所有“从远程拉代码”的动作，全靠一个：
git pull但实际上：
git fetch= 把远程更新拉下来，但不合并git pull=fetch+ 自动合并（或者 rebase）
例子：
git fetch # 先看看远程都更新了啥
git pull # 一把拉下来并合并为什么要区分？
fetch给你喘息空间： 你可以先看清楚远程改动，再决定怎么合并pull适合你确认“我就是要直接同步最新”的场景
把控制权拿回来，别全丢给 pull。
14. .gitignore：不想要的东西，就不要让 Git 看见它
如果你不写 .gitignore， 你的仓库会迅速被各种垃圾文件填满：
node_modules/.env- 各种
.log文件 - IDE 配置（
.vscode/、.idea/等）
一个最基础的 .gitignore 可能长这样：
node_modules/
.env
*.log
.DS_Store好处：
- 仓库更干净
- 拉代码更快
- 不小心把密码、密钥、配置文件传上去的概率大幅下降
记住：该被忽略的，从一开始就别让它进 Git。
15. Git Hooks：让 Git 替你当“坏人”
Hook 是 Git 提供的一套“钩子系统”：
在某些 Git 行为发生“之前 / 之后”， 自动运行你写好的脚本。
你可以在这里做很多事：
- 提交之前自动跑 lint / 测试
- 拦截不合规范的 commit message
- 提交前自动格式化代码（Prettier、ESLint 等）
它们都放在：
.git/hooks/比如一个简单的 pre-commit：
- 每次 commit 前自动跑一遍
eslint或prettier - 不符合规范就直接阻止这次提交
在专业团队里，Git Hooks 往往是保证代码质量的第一道闸门。 你不用天天当坏人， 让 Git 替你说那句：
“哥们儿，这种改法过不了。”
写在最后：真正厉害的人，不是命令记得多，而是敢动“历史”也不慌
Git 看起来让人窒息， 但你真正需要掌握的核心东西，其实就是上面的这 15 个：
- 会开分支，不在 main 上裸奔
- 会 stash，不怕临时切活儿
- 懂 rebase 和 merge 的取舍
- 会 cherry-pick 精准点提交
- 知道 reflog 能救命
- 能用 reset、amend 优雅地改历史
- 用 blame、diff、log 查清楚自己在干嘛
- 用 tag 管版本、用 .gitignore 管垃圾
- 用 hooks 自动帮自己守规矩
用 Git 的目标从来不是“命令背得多”， 而是——你知道自己每一次操作的后果。
当你不再怕它， 你才会真正开始享受那种： “我可以随便改，因为我随时能回去”的底气。全栈AI·探索：涵盖动效、React Hooks、Vue 技巧、LLM 应用、Python 脚本等专栏，案例驱动实战学习，点击二维码了解更多详情。
声明：来自JavaScript 每日一练，仅代表创作者观点。链接：https://eyangzhen.com/4600.html
