前端菜鸟别慌：用Git管好你的JS代码（附避坑指南+实战技巧）

前端菜鸟别慌：用Git管好你的JS代码（附避坑指南+实战技巧）

• 前端菜鸟别慌：用Git管好你的JS代码（附避坑指南+实战技巧）
• • 引言
  • 为啥前端离不开Git
  • Git和JavaScript的日常搭子关系
  • • 初始化那点事儿
    • 分支管理是门艺术
    • 日常提交的节奏
  • 那些年我们踩过的Git坑
  • • 坑一：commit信息写成天书
    • 坑二：merge冲突时直接删别人代码
    • 坑三：把敏感信息push到公网
    • 坑四：在main分支上直接改代码
  • 分支策略怎么选才不翻车
  • • 简单实用的Feature Branch模式
    • 什么时候用Git Flow？
    • 关键不是工具，是统一
  • Commit信息写得像人话有多重要
  • • 好的commit信息长啥样
    • 用emoji让log更好看
    • 提交前检查
  • 用Git Hooks自动化JS项目流程
  • • 常用的几个钩子
    • 安装配置Husky
  • .gitignore到底该忽略啥
  • • 通用必忽略清单
    • React项目额外注意
    • Vue项目额外注意
    • Node后端项目注意
    • 已经误跟踪了怎么办
  • 多人协作时的Git生存守则
  • • 守则一：永远别在公共分支上直接push
    • 守则二：PR描述写清楚
    • 守则三：别force push公共分支
    • 守则四：定期同步主干代码
    • 守则五：Code Review是互相尊重
  • 回滚、找回、抢救：Git的急救包
  • • 场景一：刚改乱了工作区，想恢复
    • 场景二：已经commit了，但想修改
    • 场景三：想撤销某次提交，但保留修改
    • 场景四：彻底回退到某个历史版本
    • 场景五：误删了分支或commit，用reflog救命
    • 场景六：只想要某个commit的改动
  • 让Git更懂JavaScript的小技巧
  • • 配置diff工具支持JSX/TSX
    • 用git blame查"罪魁祸首"
    • 查看某行代码的历史演变
    • 暂存未完成的工作
    • 批量修改历史commit
  • 最后唠两句（假装不是总结）

前端菜鸟别慌：用Git管好你的JS代码（附避坑指南+实战技巧）

引言

说实话，我刚入行那会儿，对Git的态度就跟对待家里那个总唠叨的亲戚一样——觉得麻烦，能躲就躲。记得有次熬夜写了个自认为超炫的轮播图，第二天手一抖，把文件夹直接拖进了回收站还顺手清空了。那一刻，我坐在电脑前，感觉整个世界都安静了，只剩下风扇转动的声音在嘲笑我。

后来进了团队，情况更魔幻。队友改了我写的工具函数，没吱声，我这边一拉代码，整个项目直接红成一片。当时我就想，这哪是协作啊，简直是谍战片。直到被老大摁着头学Git，我才慢慢反应过来：这玩意儿根本不是啥"高级工具"，它就是咱前端人的记事本、后悔药、甚至是护身符。

所以今天咱不整那些虚的，就聊聊JavaScript开发里，Git到底该怎么用才能真香。不是那种"git add . git commit -m"的流水账，而是实打实的踩坑实录和救命技巧。坐稳了，开唠。

为啥前端离不开Git

很多人以为Git就是"提交-推送"那两下子，跟用网盘似的。错！这么想的话，你就亏大了。

现在前端啥情况？组件化、模块化、微前端、Monorepo……一个项目里可能同时跑着React、Vue、Node脚本，还有一堆配置文件。你改个Button组件，说不定会影响到十个页面；你升级个依赖，可能整个构建流程就崩了。没个靠谱的版本控制，这项目分分钟变成"祖传屎山"——你都不敢动，生怕一动就塌。

Git最牛逼的地方在于它是你的时光机。你随时可以回到"昨天下午三点那个还能跑的版本"，或者看看"上周是谁把那个判断条件写反了"。更重要的是，它是协作翻译官。你写你的feature分支，我写我的bugfix分支，最后通过PR（Pull Request）合到主干，中间还能互相review代码。这就好比两个人同时改一份Word文档，但不会出现"你覆盖我、我覆盖你"的血案。

而且啊，现在的CI/CD（持续集成/持续部署）都是跟Git绑定的。你push代码到特定分支，自动跑测试、自动构建、自动部署。Git提交信息写规范了，连版本号都能自动生成。这哪是版本控制，这是你的自动化流水线开关。

Git和JavaScript的日常搭子关系

咱前端每天打开项目，第一件事通常是git pull，看看队友又整了啥新活儿。然后开始写代码，写完了git add，git commit，git push，一套组合拳打完，代码就上云了。听起来简单，但魔鬼藏在细节里。

初始化那点事儿

新项目启动，别急着写代码，先把Git仓库建好：

# 初始化仓库，这会在项目根目录生成.git文件夹
git init

# 或者直接从远程克隆现成的
git clone https://github.com/你的项目.git

然后马上搞.gitignore文件，这玩意儿太重要了。前端项目里node_modules动辄几万文件，你不忽略掉，Git会疯，你也会疯。后面咱会专门聊这个清单怎么列。

分支管理是门艺术

写新功能？别在main或master分支上直接撸代码，那是找死。规矩是：新建feature分支，改完再合并。

# 基于当前分支创建并切换到新分支
git checkout -b feature/awesome-carousel

# 或者新版Git的命令，更直观
git switch -c feature/awesome-carousel

分支命名也有讲究。别叫test、fix、111这种让人摸不着头脑的名字。推荐用feature/功能描述、bugfix/问题描述、hotfix/紧急修复这种格式。队友一看分支名就知道你在干啥，省得来回问。

日常提交的节奏

很多人有个坏习惯：写了一天代码，晚上一次性提交，commit信息就写个"update"。这不行！Git的提交应该小而频繁，每个commit只做一件事。

比如你在做用户登录功能：

• 第一次提交：实现登录表单UI
• 第二次提交：添加表单验证逻辑
• 第三次提交：对接登录API

这样好处太多了。如果后面发现API对接有问题，你可以只回滚第三次提交，前两次的UI和验证逻辑还在。如果揉成一个commit，那就得全回滚，UI也没了。

# 查看当前修改了哪些文件
git status

# 选择性添加，别直接git add .
git add src/components/LoginForm.jsx
git add src/utils/validation.js

# 提交，信息写清楚
git commit -m "feat: 添加登录表单的基础验证逻辑

– 实现邮箱格式校验
– 添加密码长度限制（6-20位）
– 错误提示文案优化"

看到没，commit信息里我还加了详细描述。用空行隔开标题和正文，这是Git的规范。队友看git log的时候，一眼就能明白这次改动做了啥，为啥做。

那些年我们踩过的Git坑

说到踩坑，那我可太有发言权了。Git这玩意儿，用好了是神器，用不好就是埋雷。咱一条条拆开说，都是血泪换来的经验。

坑一：commit信息写成天书

“fix bug”、“update”、“111”、“test”……这种提交信息，三天后你自己都看不懂，更别说队友了。最尴尬的是，线上出问题了，你要找哪次提交引入的bug，结果对着满屏的"update"欲哭无泪。

正确姿势：用Conventional Commits规范。简单说，就是给commit加个类型前缀：

# 新功能
git commit -m "feat: 添加商品购物车组件"

# 修复bug
git commit -m "fix: 修复iOS下日期选择器无法弹出的问题"

# 文档更新
git commit -m "docs: 更新API接口文档"

# 代码重构（不改功能只优化结构）
git commit -m "refactor: 抽离表单验证逻辑到独立模块"

# 样式调整
git commit -m "style: 调整移动端导航栏间距"

# 测试相关
git commit -m "test: 添加用户登录流程的单元测试"

# 构建或工具链
git commit -m "chore: 升级webpack到5.x版本"

这规范的好处是，配合工具可以自动生成CHANGELOG，甚至自动打版本号。比如feat开头的是次要版本，fix开头的是补丁版本。CI/CD流水线里常用这个。

坑二：merge冲突时直接删别人代码

这种情况多发生在团队协作初期。你pull代码，发现有冲突，Git在文件里标了<<<<<<< HEAD这种符号。新手一看，慌了，直接删掉别人的部分，只留自己的，然后提交了。

结果呢？队友的代码没了，功能崩了，你们俩还得吵架。其实冲突标记长这样：

<<<<<<< HEAD
// 你当前的代码
const apiUrl = 'https://api.old.com';
=======
// 别人改的代码
const apiUrl = 'https://api.new.com';
>>>>>>> feature/new–api–endpoint

正确姿势：仔细看两边的代码，理解别人为啥这么改。如果确定要保留某一边，可以用Git命令：

# 保留当前分支的版本
git checkout –ours src/config/api.js

# 保留合并进来的版本
git checkout –theirs src/config/api.js

# 或者手动编辑文件，删掉冲突标记后
git add src/config/api.js
git commit -m "merge: 解决api地址配置冲突，采用新域名"

实在拿不准，停下来，去问写那段代码的人。别瞎猜，这是团队协作的基本礼貌。

坑三：把敏感信息push到公网

这是最要命的。你把数据库密码、API密钥、阿里云OSS的secret，直接写代码里，然后push到GitHub。哪怕后面删了，提交记录里还在，黑客一翻commit history就能找到。

我就见过一个案例，某创业公司的AWS密钥泄露在GitHub上，第二天账户就被刷了上万美金，全是挖矿实例。

正确姿势：用.env文件和环境变量。前端项目里：

// .env 文件（这个要加入.gitignore！！！）
REACT_APP_API_KEY=your_secret_key_here
REACT_APP_API_URL=https://api.example.com

// 代码里这样用
const apiKey = process.env.REACT_APP_API_KEY;

如果不小心已经push了敏感信息，别只删文件，要用git filter-branch或BFG Repo-Cleaner清理历史记录。然后立即更换密钥，因为GitHub有爬虫专门扫这些。

# 用BFG清理（需要java环境）
java -jar bfg.jar –replace-text passwords.txt my-repo.git

# 或者git原生命令（慎用，会重写历史）
git filter-branch –force –index-filter \\
'git rm –cached –ignore-unmatch 配置文件.js' \\
–prune-empty –tag-name-filter cat — –all

坑四：在main分支上直接改代码

这个习惯不改，迟早出事。main分支应该是永远可部署的稳定版本。你直接在上面改，万一改崩了，整个团队都跑不起来。

正确姿势：强制用分支工作流。哪怕改个标点符号，也给我新建分支：

# 从main切出来
git checkout main
git pull origin main
git checkout -b fix/typo-in-readme

# 改完提交
git add README.md
git commit -m "docs: 修复README中的拼写错误"

# push到远程
git push origin fix/typo-in-readme

# 然后去GitHub/GitLab提PR，让队友review后再合并

分支策略怎么选才不翻车

网上讲Git Flow、GitHub Flow、GitLab Flow的文章一大堆，看得人头大。其实对大多数前端项目，特别是中小型团队，真没必要搞那么复杂。

简单实用的Feature Branch模式

这是最适合前端团队的策略，简单粗暴：

# 功能开发完整流程
git checkout main
git pull origin main
git checkout -b feature/user-profile-page

# 写代码……写代码……写代码

git add .
git commit -m "feat: 完成用户个人中心页面基础功能"
git push origin feature/user-profile-page

# 然后去GitHub提PR，设置reviewer，等approve后合并

什么时候用Git Flow？

如果你的项目需要严格区分开发版、预发版、生产版，比如有develop分支做集成测试，release分支做上线准备，那可以用Git Flow。但说实话，现在有了CI/CD和容器化，很多团队已经简化掉了。

关键不是工具，是统一

最怕的是团队里有人用Git Flow，有人用GitHub Flow，还有人直接在main上push。那场面，想想都酸爽。所以团队一开始就要定规矩，写在CONTRIBUTING.md里，新人入职先读这个。

Commit信息写得像人话有多重要

前面提到了Conventional Commits，这里再展开说说怎么写得像人话，而不是机器生成的。

好的commit信息长啥样

# 差的例子
git commit -m "fix bug"

# 好的例子
git commit -m "fix(auth): 修复token过期后未自动跳转登录页的问题

问题描述：
用户保持页面打开超过2小时后，token失效但页面仍显示已登录状态，
点击任何需要鉴权的操作都会报错，体验很差。

解决方案：
– 在axios拦截器中添加401状态码监听
– 检测到401后清除本地存储的token并跳转登录页
– 添加提示文案'登录已过期，请重新登录'

关联issue: #142"

看到没？好的commit信息包含：

• 类型和范围：fix(auth)表示这是认证模块的修复
• 简短标题：一句话说清做了什么
• 详细描述：说明问题背景、解决方案、具体改动
• 关联信息：issue编号、需求文档链接等

用emoji让log更好看

有些团队喜欢在commit前加emoji，视觉上更容易区分：

# ✨ 新功能
git commit -m ":sparkles: feat: 添加暗黑模式切换"

# 🐛 修复bug
git commit -m ":bug: fix: 修复移动端触摸滑动卡顿"

# 📝 文档
git commit -m ":memo: docs: 更新组件库使用说明"

# ♻️ 重构
git commit -m ":recycle: refactor: 优化虚拟列表渲染性能"

# ✅ 测试
git commit -m ":white_check_mark: test: 添加支付流程e2e测试"

配合工具比如gitmoji-cli，还能交互式选择emoji，挺有意思的。

提交前检查

别等push了才发现commit信息写错了。可以用Git Hooks在提交前检查格式，后面会详细讲。

用Git Hooks自动化JS项目流程

Git Hooks是Git的钩子脚本，在特定事件发生时自动执行。对前端项目来说，这是保证代码质量的第一道防线。

常用的几个钩子

pre-commit：提交前自动跑。最适合做代码检查。

# 项目根目录创建 .husky/pre-commit 文件（需要安装husky）
#!/bin/sh
. "$(dirname "$0")/_/husky.sh"

# 只检查暂存区的文件，提速
npx lint-staged

配合lint-staged配置（package.json里）：

{
"lint-staged": {
"*.{js,jsx,ts,tsx}": [
"eslint –fix",
"prettier –write",
"git add"
],
"*.{css,scss,less}": [
"stylelint –fix",
"git add"
]
}
}

这样每次提交前，ESLint会自动检查你改过的文件，有错误就拦住不让提交。别嫌烦，这能帮你拦住80%的低级错误。

pre-push：推送前自动跑。适合跑测试。

# .husky/pre-push
#!/bin/sh
. "$(dirname "$0")/_/husky.sh"

# 跑单元测试
npm run test:unit

# 或者只跑相关测试（更快）
npm run test:unit — –findRelatedTests $(git diff –name-only HEAD | grep -E '\\.(js|jsx|ts|tsx)$')

测试挂了？push失败。强制你修好了再推，避免把坏代码带到远程。

post-merge：合并后自动跑。适合安装依赖。

# .husky/post-merge
#!/bin/sh
. "$(dirname "$0")/_/husky.sh"

# 检查package.json是否有变化，有就自动npm install
changed_files="$(git diff-tree -r –name-only –no-commit-id ORIG_HEAD HEAD)"

if echo "$changed_files" | grep –quiet "^package\\.json$"; then
echo "📦 package.json changed, running npm install…"
npm install
fi

队友升级了依赖，你pull代码后自动就装好了，不用手动npm install，贴心吧？

commit-msg：检查提交信息格式。

# .husky/commit-msg
#!/bin/sh
. "$(dirname "$0")/_/husky.sh"

# 用commitlint检查格式
npx –no-install commitlint –edit "$1"

配合commitlint.config.js：

module.exports = {
extends: ['@commitlint/config-conventional'],
rules: {
'type-enum': [2, 'always', ['feat', 'fix', 'docs', 'style', 'refactor', 'test', 'chore']],
'subject-full-stop': [0, 'never'],
'subject-case': [0, 'never']
}
};

提交信息不规范？直接打回重写。团队规范就是这么强制落地的。

安装配置Husky

现在都用husky v7+版本，配置更简单：

# 安装
npm install husky lint-staged @commitlint/config-conventional @commitlint/cli –save-dev

# 初始化husky
npx husky install

# 添加钩子
npx husky add .husky/pre-commit "npx lint-staged"
npx husky add .husky/commit-msg 'npx –no-install commitlint –edit "$1"'

把这些配置提交到仓库，整个团队都能享受自动化检查，代码质量稳稳的。

.gitignore到底该忽略啥

.gitignore文件是前端项目的隐私清单，告诉Git哪些文件别跟踪。但不同项目该忽略的东西不一样，咱得分类说清楚。

通用必忽略清单

# 依赖目录（这个必须第一个写！）
node_modules/
npm-debug.log*
yarn-debug.log*
yarn-error.log*
pnpm-debug.log*

# 构建输出
dist/
build/
out/
.next/
.nuxt/
.vuepress/dist

# 环境变量（含敏感信息）
.env
.env.local
.env.*.local

# 编辑器配置
.idea/
.vscode/*
!.vscode/extensions.json
!.vscode/settings.json
*.suo
*.ntvs*
*.njsproj
*.sln
*.sw?

# OS生成的文件
.DS_Store
Thumbs.db

# 测试覆盖率报告
coverage/
.nyc_output/

# 日志文件
logs/
*.log

# 缓存
.cache/
.temp/
*.tsbuildinfo
.eslintcache
.stylelintcache

React项目额外注意

# React特有
/build
# 本地环境文件（React会自动读取.env.local）
.env.local
.env.development.local
.env.test.local
.env.production.local

# service worker
/src/serviceWorker.js.map

Vue项目额外注意

# Vue CLI
/dist
# 本地环境
.env.local
.env.*.local

# Vuepress
.vuepress/dist

# Vite
*.local

Node后端项目注意

# 上传的文件目录（如果存在）
uploads/
public/uploads/

# 数据库文件（如果是sqlite）
*.sqlite
*.sqlite3

# 运行时数据
pids/
*.pid
*.seed
*.pid.lock

# 生成的证书
*.pem
*.cert
*.key

已经误跟踪了怎么办

如果你发现node_modules已经提交到仓库了，光加.gitignore没用，得把已经跟踪的移除：

# 停止跟踪，但保留本地文件
git rm -r –cached node_modules

# 提交这个改动
git commit -m "chore: 移除误跟踪的node_modules"

# push到远程
git push origin main

然后.gitignore才会真正生效。

多人协作时的Git生存守则

团队协作是Git的主战场，也是矛盾高发区。记住这几条，能帮你少吵架、少背锅。

守则一：永远别在公共分支上直接push

main、develop这种大家共用的分支，必须通过PR合并，别直接push。这是为了防止：

• 你push了个半成品，别人pull下来跑不起来
• 你覆盖了别人的重要提交
• 你引入了没经过review的bug

# 错误示范
git checkout main
git add .
git commit -m "紧急修复"
git push origin main # 千万别这样！

# 正确示范
git checkout -b hotfix/critical-bug
git add .
git commit -m "fix: 修复支付回调验证失败"
git push origin hotfix/critical-bug
# 然后去GitHub提PR，找个人review，再合并

守则二：PR描述写清楚

提PR不是点一下按钮就完事了。好的PR描述应该包含：

## 改动内容
– 添加了用户注册时的手机号验证码功能
– 封装了通用验证码组件，支持倒计时和重发

## 为什么改动
需求文档：https://wiki.company.com/requirements/reg-with-phone
原邮箱注册转化率低，产品希望增加手机号注册提升转化

## 怎么测试
1. 进入注册页面，选择手机号注册
2. 输入手机号，点击获取验证码
3. 检查是否能正常收到短信（测试环境用模拟验证码123456）
4. 输入错误验证码应提示"验证码错误"
5. 等待60秒后应能重新获取

## 截图
（这里贴UI效果图）

## 关联issue
Fixes #234

队友一看就明白，review效率也高。别写"如题"、"改了bug"这种敷衍的。

守则三：别force push公共分支

git push –force是核武器，只在feature分支上对自己用，绝对别对main、develop这种公共分支用。你会覆盖别人的提交，导致队友代码丢失。

如果非要用force push（比如整理commit历史），用–force-with-lease，它会检查远程是否有新提交，有的话会拒绝，防止误伤：

# 相对安全的强制推送
git push –force-with-lease origin feature/my-branch

守则四：定期同步主干代码

你的feature分支开了三天，期间main分支已经合并了五个PR。这时候你直接合进去，冲突概率很大。

养成习惯，每天开始工作前先同步：

git checkout main
git pull origin main
git checkout feature/your-branch
git rebase main # 或者 git merge main，看团队习惯

# 解决可能的冲突后，继续开发

用rebase的好处是commit历史更线性，看着清爽；用merge会保留分支结构，但历史图会比较乱。团队统一一种方式就行。

守则五：Code Review是互相尊重

review别人的代码，别只会挑刺。好的review应该：

• 指出问题，并说明为什么（“这里用==会有类型转换风险，建议用===”）
• 发现好的实践，也点赞（“这个错误处理写得挺优雅的，学习了”）
• 有疑问就问，别假设（“这里为啥用setTimeout？是有特殊考虑吗？”）

被review的时候，别玻璃心。代码被指出问题，不代表你人不行，反而是防止你背锅。感谢每一个认真review你的队友。

回滚、找回、抢救：Git的急救包

人非圣贤，孰能无过。关键是错了之后怎么抢救。Git提供了强大的"时光倒流"能力，但得知道怎么用。

场景一：刚改乱了工作区，想恢复

你改了一堆文件，突然发现思路错了，想全部回退到上次提交的状态：

# 查看当前修改（确认一下）
git status

# 危险！这会丢弃所有未提交的修改，慎用
git checkout — .

# 或者只恢复某个文件
git checkout — src/components/WrongFile.jsx

# 新版Git推荐用restore，语义更清晰
git restore .
git restore src/components/WrongFile.jsx

场景二：已经commit了，但想修改

刚提交完，发现有个console.log忘了删：

# 修改文件，删掉console.log
git add src/components/FixedFile.jsx

# –amend 修改最后一次提交，不生成新commit
git commit –amend -m "feat: 添加用户详情页"

# 如果只是想修改文件，不想改commit信息
git commit –amend –no-edit

注意：如果已经push到远程了，amend后需要force push，只在个人分支上这么干。

场景三：想撤销某次提交，但保留修改

你发现某个commit引入了bug，但里面的代码还想留着改改再用：

# 查看log，找到要撤销的commit hash
git log –oneline -10

# 假设要撤销abc1234这次提交
git revert abc1234 –no-commit

# 这会生成新的修改，反向应用abc1234的改动
# 你可以修改这些改动，然后重新提交
git add .
git commit -m "revert: 撤销用户搜索功能的错误实现，待重构"

revert是安全的撤销，会生成新commit，不会改写历史。

场景四：彻底回退到某个历史版本

你想放弃最近三次提交，直接回到某个稳定版本：

# 查看log
git log –oneline

# 软回退：保留修改到暂存区，你可以重新提交
git reset –soft HEAD~3

# 混合回退：保留修改到工作区，你需要重新add
git reset –mixed HEAD~3

# 硬回退：彻底丢弃这三次提交的修改，危险！
git reset –hard abc1234

–hard是核武器，执行前建议先git stash或者备份分支。

场景五：误删了分支或commit，用reflog救命

这是最牛的功能，Git会记录你所有的操作历史，即使reset –hard了也能找回来：

# 查看操作历史（像时光机一样）
git reflog

# 输出类似：
# abc1234 HEAD@{0}: reset: moving to HEAD~3
# def5678 HEAD@{1}: commit: feat: 添加支付功能
# 9ab9012 HEAD@{2}: commit: fix: 修复购物车计算错误

# 发现def5678是你要找回的commit
git checkout -b recovery-branch def5678

# 或者直接用reset恢复
git reset –hard def5678

reflog默认保留30天，所以只要发现得及时，基本都能救回来。

场景六：只想要某个commit的改动

队友在某个分支上写了个超棒的工具函数，你想"偷"到自己分支，但不想合并整个分支：

# 查看那个commit的hash，比如是f8d3a21
git cherry-pick f8d3a21

# 如果有冲突，解决后
git add .
git cherry-pick –continue

# 如果想放弃这次cherry-pick
git cherry-pick –abort

这就像是精准复制某次提交，很实用的技巧。

让Git更懂JavaScript的小技巧

Git默认对代码差异的展示比较通用，但针对JS项目，我们可以让它更智能。

配置diff工具支持JSX/TSX

默认的diff对JSX支持不好，可以配置更友好的展示：

# 配置Git使用更智能的diff算法
git config –global diff.algorithm histogram

# 对特定文件类型使用特殊diff
echo "*.jsx diff=jsx" >> .gitattributes
echo "*.tsx diff=tsx" >> .gitattributes

或者用第三方diff工具，比如delta，支持语法高亮：

# 安装delta（用brew或cargo）
brew install git-delta

# 配置Git使用delta
git config –global core.pager delta
git config –global interactive.diffFilter 'delta –color-only'
git config –global delta.syntax-theme Dracula
git config –global delta.line-numbers true

这样git diff看JSX代码时，有语法高亮，变更行也标得清楚，review体验大幅提升。

用git blame查"罪魁祸首"

看到一坨烂代码，想知道谁写的？别在群里吼，用git blame：

# 查看某文件的每一行是谁写的
git blame src/utils/messyCode.js

# 只看某几行（比如100-120行）
git blame -L 100,120 src/utils/messyCode.js

# 忽略空白字符的改动（格式化导致的无关变更）
git blame -w src/utils/messyCode.js

输出会显示每行最后的修改者、时间和commit。但注意，blame是查最后修改的人，不是原始作者。如果某人只是格式化了下代码，会显示他的名字。配合-w参数可以一定程度上避免这个问题。

查看某行代码的历史演变

想知道某个函数是怎么一步步变成现在这样的：

# 查看某文件的变更历史，带详细diff
git log -p src/components/Evolution.jsx

# 只查看涉及某函数的提交（用-S搜索）
git log -S "function oldFunctionName" src/components/Evolution.jsx

# 图形化查看（如果装了tig等工具）
tig src/components/Evolution.jsx

暂存未完成的工作

写到一半，突然要切分支修紧急bug？别急着commit半成品，用stash：

# 把当前修改存起来，工作区变干净
git stash push -m "用户头像上传功能写到一半"

# 修完bug回来，恢复
git stash pop

# 如果stash多了，查看列表
git stash list

# 恢复指定的stash
git stash apply stash@{1}

批量修改历史commit

如果你发现连续三个commit都忘了加issue编号，或者作者信息写错了，可以用交互式rebase：

# 修改最近4次提交
git rebase -i HEAD~4

# 会打开编辑器，显示：
# pick abc1234 feat: 添加登录页
# pick def5678 fix: 修复样式
# pick 9ab9012 feat: 添加注册页
# pick 1cd2345 fix: 修复验证

# 把需要修改的commit前面的pick改成edit或reword
# edit：停下来让你修改
# reword：只改commit信息

# 保存退出后，按提示操作
# 改完用 git rebase –continue 继续

注意：已经push到远程的commit，别用rebase修改，会改写历史导致队友混乱。只用于本地整理commit。

最后唠两句（假装不是总结）

写到这儿，我突然想起刚学Git那会儿，觉得这些命令又臭又长，哪有Ctrl+Z来得痛快。直到被现实毒打了几轮——丢过代码、背过锅、凌晨三点还在解冲突——才真正理解Git的价值。

Git这玩意儿，说白了就是个保险+记账+协作的工具。它不能保证你代码写得牛，但能保证你写得再烂也有退路，保证你和队友不会互相踩脚，保证项目历史清清楚楚谁也别想赖账。

别等项目炸了才想起学Git，那时候往往已经晚了。现在就试试那些你觉得"太麻烦"的命令：建个分支玩一玩，故意制造个冲突解一解，用reflog找回被reset的commit。玩熟了，下次团建的时候，说不定你就是那个帮全组recover代码的英雄，奶茶随便点的那种。

还有啊，Git虽然强大，但也不是万能的。它管的是代码版本，管不了你代码里的逻辑错误，也管不住你把API密钥写死在代码里的手。好代码还是得靠脑子写，Git只是帮你保管好这些脑子里的产物。

行了，今天就唠到这儿。去试试吧，记得把.gitignore先写好，别又给我把node_modules传上来了，看着头大。