Git 命令速查与实战技巧

Git 是现代软件开发的基石。无论是个人项目还是团队协作，几乎每个开发者每天都在使用 Git。然而，很多人只会 commit 和 push，遇到冲突或分支操作就手足无措。本文整理了最实用的 Git 命令与实战技巧，帮助你从"够用"走向"精通"。

1. 基础操作：每天都在用的命令

初始化与配置

# 初始化仓库
git init

# 克隆远程仓库
git clone https://github.com/user/repo.git

# 配置用户信息（全局）
git config --global user.name "Your Name"
git config --global user.email "[email protected]"

# 查看配置
git config --list

提交与查看

# 查看工作区状态
git status

# 添加文件到暂存区
git add file.txt        # 单个文件
git add .               # 当前目录所有文件
git add -p              # 交互式添加（按片段选择）

# 提交
git commit -m "feat: add login page"
git commit --amend      # 修改最近一次提交

# 查看历史
git log                 # 完整历史
git log --oneline       # 精简一行显示
git log --graph         # 图形化分支
git log -p              # 显示每次提交的 diff

2. 分支管理：Git 的核心能力

分支是 Git 最强大的特性，也是协作开发的基础。掌握分支操作，才能真正发挥 Git 的威力。

# 查看分支
git branch              # 本地分支
git branch -a           # 所有分支（含远程）

# 创建与切换
git branch feature-x    # 创建分支
git checkout feature-x  # 切换分支
git checkout -b feature-x  # 创建并切换（推荐）
git switch feature-x    # Git 2.23+ 新命令，更直观

# 合并
git merge feature-x     # 把 feature-x 合并到当前分支
git merge --no-ff feature-x  # 不使用快进合并，保留合并记录

# 删除分支
git branch -d feature-x # 安全删除（已合并的分支）
git branch -D feature-x # 强制删除

# 重命名分支
git branch -m old-name new-name

rebase：让提交历史更干净

merge 会保留完整的合并历史，而 rebase 会把当前分支的提交"搬移"到目标分支之上，形成一条直线。rebase 后的历史更清晰，但会改写提交记录，因此不要对已经推送到远程的分支使用 rebase。

# 将当前分支 rebase 到 main 之上
git rebase main

# 交互式 rebase（合并/修改/删除历史提交）
git rebase -i HEAD~5

# rebase 过程中冲突解决后
git rebase --continue
git rebase --abort

3. 撤销与回退：后悔药大全

Git 提供了多层次的撤销操作，从工作区到提交历史，几乎任何操作都可以回退。

# 撤销工作区修改（恢复到上次提交状态）
git restore file.txt

# 撤销暂存（把文件从暂存区放回工作区）
git restore --staged file.txt
# 或旧版写法：git reset HEAD file.txt

# 撤销最近一次提交（保留改动在暂存区）
git reset --soft HEAD~1

# 撤销最近一次提交（保留改动在工作区）
git reset --mixed HEAD~1

# 彻底撤销，丢弃所有改动（危险！）
git reset --hard HEAD~1

# 新建一个反向提交，撤销指定提交（适合已推送的代码）
git revert <commit-hash>

记住黄金法则：已推送的代码用 revert，本地未推送的用 reset。revert 不会改写历史，在团队协作中更安全。

4. 远程协作：团队开发必备

# 添加远程仓库
git remote add origin https://github.com/user/repo.git

# 查看远程仓库
git remote -v

# 拉取更新
git fetch origin        # 只下载，不合并
git pull origin main    # 下载并合并（fetch + merge）
git pull --rebase       # 用 rebase 方式拉取（推荐）

# 推送
git push origin main
git push -u origin main # 首次推送并建立追踪关系
git push --force        # 强制推送（慎用！）
git push --force-with-lease  # 安全强制推送

# 清理远程已删除的分支
git remote prune origin

处理合并冲突

合并冲突是团队协作中不可避免的情况。当 Git 无法自动合并时，会在文件中标记冲突区域：

<<<<<<< HEAD
当前分支的代码
=======
要合并进来的代码
>>>>>>> feature-branch

解决冲突的步骤：手动编辑文件 → git add 标记已解决 → git commit 完成合并。VS Code 等编辑器提供了可视化的冲突解决工具，大幅提升效率。

5. 实用技巧：提升效率的冷门命令

stash：暂存当前工作

当你正在开发某个功能，突然需要切换到其他分支处理紧急问题，但当前代码还没到可以提交的程度，stash 就是救星。

git stash               # 暂存当前改动
git stash save "message" # 暂存并添加描述
git stash list          # 查看暂存列表
git stash pop           # 恢复最近的暂存并删除
git stash apply         # 恢复但不删除
git stash drop          # 删除最近的暂存

cherry-pick：选择性应用提交

# 把某个提交应用到当前分支
git cherry-pick <commit-hash>

# 应用多个提交
git cherry-pick hash1 hash2 hash3

bisect：二分查找 Bug 引入点

当你不知道哪个提交引入了 Bug 时，bisect 可以通过二分查找快速定位。

git bisect start
git bisect bad          # 标记当前版本有 bug
git bisect good v1.0    # 标记 v1.0 是好的
# Git 会自动切换到中间版本，测试后标记 good/bad
# 重复直到找到第一个坏提交
git bisect reset        # 结束 bisect

6. 提交规范与最佳实践

好的提交信息是项目可维护性的基础。业界广泛采用 Conventional Commits 规范：

<type>(<scope>): <subject>

type:
  feat    - 新功能
  fix     - 修复 bug
  docs    - 文档变更
  style   - 格式调整（不影响代码运行）
  refactor - 重构
  perf    - 性能优化
  test    - 增加测试
  chore   - 构建过程或辅助工具变动

示例：
feat(auth): add OAuth2 login support
fix(api): handle null response from user endpoint
docs(readme): update installation instructions

此外，遵循以下原则能让你的 Git 使用更专业：每个提交只做一件事、频繁提交但保持原子性、写清楚提交信息、发布前清理临时提交、永远不要在 main 分支直接开发。

7. 标签与发布管理

标签（Tag）用于标记项目中的重要里程碑，比如版本发布。Git 支持两种标签：轻量标签和附注标签。

# 轻量标签（只是一个指向特定提交的指针）
git tag v1.0.0

# 附注标签（包含标签者、日期、信息，推荐用于发布）
git tag -a v1.0.0 -m "Release version 1.0.0"

# 查看标签
git tag
git tag -l "v1.*"   # 模糊匹配

# 查看标签详情
git show v1.0.0

# 推送标签到远程（默认不会推送标签）
git push origin v1.0.0
git push origin --tags   # 推送所有标签

# 删除标签
git tag -d v1.0.0
git push origin --delete v1.0.0

语义化版本（Semantic Versioning）是业界通用的版本号规范：主版本号.次版本号.修订号（MAJOR.MINOR.PATCH）。主版本号表示不兼容的 API 变更，次版本号表示新增功能且向后兼容，修订号表示 bug 修复。遵循这个规范，用户一眼就能看出版本升级的影响范围。

8. Git 工作流

团队协作时，选择合适的 Git 工作流非常重要。常见的工作流有以下几种：

• Git Flow：最经典的工作流，有 master/develop/feature/release/hotfix 五种分支。适合有明确发布周期的项目，但流程较重。
• GitHub Flow：更简单的工作流，只有 main 分支 + feature 分支。功能开发完后合并到 main 即可发布。适合持续部署的团队。
• GitLab Flow：在 GitHub Flow 基础上增加了环境分支（如 staging、production），适合有多个部署环境的团队。
• Trunk Based Development：所有人都在主干（trunk）开发，通过功能开关控制未完成功能。配合 CI/CD 实现高频发布。

没有最好的工作流，只有最适合的。小团队快速迭代用 GitHub Flow 就够了；大团队多版本维护可能需要 Git Flow；追求极致发布速度可以尝试 Trunk Based Development。

9. .gitignore 配置技巧

.gitignore 文件告诉 Git 哪些文件不需要纳入版本控制。正确配置 .gitignore 可以避免把敏感信息、构建产物、依赖包等提交到仓库。

# 依赖目录
node_modules/
vendor/

# 构建产物
dist/
build/
*.log

# 环境变量和配置（含敏感信息）
.env
.env.local
.env.*.local
config.local.js

# IDE 和编辑器
.vscode/
.idea/
*.swp
*.swo
*~

# 操作系统文件
.DS_Store
Thumbs.db

# 测试覆盖率
coverage/
.nyc_output/

# 临时文件
*.tmp
*.temp
.cache/

几个实用技巧：用 git check-ignore -v filename 可以查看是哪条规则忽略了某个文件；全局 .gitignore（~/.gitignore_global）可以配置通用的忽略规则，避免每个项目都重复写；已经被追踪的文件，添加到 .gitignore 后不会自动停止追踪，需要 git rm --cached filename 手动移除。

10. 常用 Git 工作流命令组合

下面是一些日常高频使用的命令组合，都是实战中总结出来的"一招鲜"：

# 1. 快速修复上一次提交（还没推送的情况下）
git add .
git commit --amend --no-edit

# 2. 暂存当前未完成的工作，去修复紧急 bug
git stash save "wip: feature-x"
git checkout main
git checkout -b hotfix-xxx
# ... 修复完 ...
git checkout feature-x
git stash pop

# 3. 把某个分支上的某次提交应用到当前分支
git cherry-pick 

# 4. 查看某个文件的修改历史
git log -p -- filename

# 5. 查看某行代码是谁写的
git blame filename

# 6. 撤销某次合并
git revert -m 1 

# 7. 清理本地已合并的分支
git branch --merged | grep -v '\*\|main\|master' | xargs git branch -d

# 8. 找回丢失的提交（reset 错了也不怕）
git reflog
git checkout    # 或者 git reset --hard 

特别是 git reflog，堪称 Git 的时光机。几乎所有"我把代码搞没了"的惨剧，都可以通过 reflog 找回来。只要提交过的代码，Git 至少会保留 30 天。所以遇到 Git 操作失误，别慌，先看看 reflog。

11. 钩子（Hooks）：自动化工作流

Git 钩子是在特定事件发生时自动执行的脚本，可以用来自动化代码检查、测试、部署等工作流。

# 客户端钩子（位于 .git/hooks/）
pre-commit          # 提交前执行，常用于代码格式检查、lint
pre-push            # 推送前执行，常用于运行测试
commit-msg          # 检查提交信息格式
prepare-commit-msg  # 准备提交信息时执行

# 服务端钩子
pre-receive         # 接收推送前执行
post-receive        # 接收推送后执行（常用于自动部署）
update              # 每个分支更新时执行

最常用的是 pre-commit 钩子——提交代码前自动运行代码格式化、ESLint 检查、单元测试，不通过就不让提交。配合 husky 和 lint-staged 等工具，可以很方便地搭建前端项目的提交检查流程。这保证了仓库里的代码风格统一、没有低级错误。

12. 多人协作的 Git 规范

团队协作时，统一的 Git 规范能减少很多沟通成本和冲突。以下是一些被广泛采用的规范：

• 分支命名规范：feature/xxx 功能分支，bugfix/xxx 修复分支，hotfix/xxx 紧急修复，release/xxx 发布分支
• 提交前自检：提交前自己 review 一下 diff，确认没有把调试代码、注释掉的代码提交上去
• 小步提交：每次提交只做一件事，方便 review 和回滚
• 写好提交信息：遵循 Conventional Commits 规范，别人一眼就知道每次提交干了什么
• 不要提交大文件：二进制大文件放网盘或 CDN，不要塞进 Git 仓库，否则仓库会越来越大

遵循这些规范，团队的 Git 历史会变得清晰有序，新人接手也能快速理解项目的发展脉络。代码审查（Code Review）也会变得更顺畅——每次提交逻辑清晰，reviewer 不用在一堆无关改动中找重点。