Git 是什么
Git 是一个分布式版本控制系统。它用提交记录项目在不同时刻的完整快照，让开发者能够比较变化、创建分支、合并协作，并在误操作后找回历史。所谓“分布式”，是指一次完整克隆通常包含仓库历史和分支信息；即使暂时没有网络，也能提交、切换分支和查看历史。
Git 本身负责版本历史，GitHub、GitLab、Gitee 等平台则提供远程托管、权限管理、代码评审和 CI/CD。会使用 Git 不等于只能依赖某个托管平台。
如果想进一步理解这些命令背后的存储机制，可以阅读《深入理解 .git 目录：Git 如何存储提交、分支与暂存区》。
Git 的四个区域
理解命令前，先记住文件会在四个区域之间流动：
1
2
3
4
5
6
7
8
9
10
| 工作区（Working Tree）
│ git add
↓
暂存区（Index / Staging Area）
│ git commit
↓
本地仓库（Local Repository）
│ git push
↓
远程仓库（Remote Repository）
|
- 工作区：实际编辑的文件；
- 暂存区：下一次提交准备包含的快照；
- 本地仓库：保存在
.git 中的对象、引用和历史； - 远程仓库：用于交换提交的另一个仓库，
origin 只是常见的远程名称。
git diff 默认比较工作区与暂存区，git diff --staged 比较暂存区与 HEAD，git status 则概括各区域之间的差异。
提交、分支与 HEAD
Git 的核心对象包括 Blob（文件内容）、Tree（目录快照）、Commit（一次提交）和 Tag（标签）。提交保存指向 Tree 和父提交的关系，并由内容计算对象 ID。
分支本质上是一个可移动引用，指向某次提交；HEAD 通常指向当前分支。创建分支不会复制一份代码，只是新增一个引用。提交后，当前分支向新提交移动。
文件的三种状态
- 未跟踪（Untracked）：Git 尚未纳入版本管理；
- 已修改（Modified）：已跟踪文件在工作区发生变化；
- 已暂存（Staged）：变化已经进入暂存区，等待提交。
下文按日常工作顺序整理命令。涉及 reset --hard、clean -fd、强制推送等会丢失数据的操作，执行前务必先用状态或预览命令确认范围。
一、基础操作
1.1 git init — 初始化仓库
1
2
3
4
5
| # 在当前目录初始化
git init
# 初始化到指定目录
git init my-project
|
1.2 git clone — 克隆远程仓库
1
2
3
4
5
6
7
8
9
10
11
| # 克隆到当前目录下的同名文件夹
git clone https://github.com/user/repo.git
# 克隆到指定目录名
git clone https://github.com/user/repo.git my-folder
# 克隆指定分支
git clone -b main https://github.com/user/repo.git
# 浅克隆（只取最近一次提交，大仓库速度快）
git clone --depth=1 https://github.com/user/repo.git
|
1.3 git add — 添加到暂存区
1
2
3
4
5
6
7
8
9
10
11
12
13
14
| # 添加指定文件
git add README.md
# 添加多个文件
git add file1.md file2.md
# 添加当前目录下所有变更
git add .
# 添加所有变更（包括已删除的文件）
git add -A
# 交互式添加（按块选择要暂存的内容）
git add -p
|
1.4 git commit — 提交
1
2
3
4
5
6
7
8
9
10
11
12
13
14
| # 不带参数会打开编辑器让你写提交信息
git commit
# -m 直接指定提交信息（message）
git commit -m "feat: 添加用户登录功能"
# -a 提交所有已跟踪文件的修改（跳过 git add）
git commit -a -m "fix: 修复空指针异常"
# --amend 修改上一次提交（未推送到远程时使用）
git commit --amend -m "feat: 添加用户登录和注册功能"
# --allow-empty 空提交（用于触发 CI 或占位）
git commit --allow-empty -m "chore: 触发部署"
|
提交信息建议遵循 Conventional Commits 约定（见第九节）：用 feat / fix / docs 等前缀，便于 git log 阅读与自动生成 changelog。
--amend 会用新提交替换上一次提交（改写历史），和 rebase 同理：已推送的提交不要 amend ，否则别人的仓库会和你对不上；它只适合修正还没推送的本地提交。
1.5 git status — 查看状态
1
2
3
4
5
6
7
8
| # 查看工作区和暂存区状态
git status
# 简短输出（一行一个文件）
git status -s
# 显示被忽略的文件
git status --ignored
|
状态标记说明：
| 标记 | 含义 |
|---|
?? | 未跟踪的新文件 |
A | 新添加到暂存区 |
M | 已修改 |
D | 已删除 |
R | 已重命名 |
!! | 被忽略的文件 |
左侧为暂存区状态，右侧为工作区状态。例如 MM 表示暂存区和工作区都有修改。
1.6 git log — 查看提交历史
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
| # 查看完整提交历史
git log
# 单行显示
git log --oneline
# 显示最近 5 条
git log --oneline -5
# 图形化显示分支合并历史
git log --oneline --graph --all
# 显示每次提交的文件变更统计
git log --stat
# 显示指定文件的提交历史
git log -- path/to/file
# 按作者筛选
git log --author="张三"
# 按时间筛选
git log --since="2026-01-01" --until="2026-03-31"
# 按提交信息搜索
git log --grep="修复"
|
1.7 git rm / git mv — 删除与移动文件
1
2
3
4
5
6
7
8
| # 从工作区和暂存区删除已跟踪文件
git rm old-file.md
# 只停止跟踪，保留工作区文件（常用于误提交的配置文件）
git rm --cached appsettings.local.json
# 移动或重命名文件，并暂存这次变化
git mv old-name.md new-name.md
|
Git 不会永久存储“重命名”这一动作，而是在比较内容时根据相似度识别重命名。
二、分支管理
2.1 git branch — 分支操作
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
| # 查看所有本地分支
git branch
# 查看所有分支（含远程）
git branch -a
# 创建新分支（不切换）
git branch feature/login
# 删除已合并的分支
git branch -d feature/login
# 强制删除分支（无论是否合并）
git branch -D feature/login
# 重命名当前分支
git branch -m new-branch-name
# 重命名指定分支
git branch -m old-name new-name
|
2.2 git checkout / switch — 切换分支
1
2
3
4
5
6
7
8
9
10
11
12
13
| # 切换到已有分支
git checkout main
# 创建并切换到新分支
git checkout -b feature/login
# 切换到上一个分支
git checkout -
# Git 2.23+ 推荐用 switch 替代
git switch main
git switch -c feature/login # 创建并切换
git switch - # 切换到上一个分支
|
2.3 git merge — 合并分支
1
2
3
4
5
6
7
8
9
10
11
| # 将 feature 分支合并到当前分支
git merge feature/login
# 合并时不使用快进（保留分支历史）
git merge --no-ff feature/login
# 只取另一个分支中指定文件的版本（这不是 merge）
git restore --source=feature/login -- path/to/file
# 取消正在进行的合并
git merge --abort
|
merge 把指定分支的提交并入当前分支，结果有两种：
- 快进合并（fast-forward） :当前分支是另一分支的直接祖先（中间没有新提交）时，Git 只把指针前移，不产生新提交，历史保持直线。
- 三方合并 :两条分支各有新提交时，Git 生成一个合并提交（有两个父提交）把两条线汇合，历史是非线性的。
--no-ff 强制生成合并提交，即使能快进——目的是保留"这里曾有一条特性分支"的拓扑结构，便于事后追溯。
2.4 git rebase — 变基
rebase 是"换底"：把当前分支的提交一个个摘下来，重新应用到目标分支的最新提交之上。效果是把当前分支的起点挪到目标分支顶端，得到一条线性历史。
1
2
3
4
5
6
7
8
9
10
11
| # 将当前分支变基到 main
git rebase main
# 交互式变基（修改最近 3 次提交）
git rebase -i HEAD~3
# 取消正在进行的变基
git rebase --abort
# 变基遇到冲突解决后继续
git rebase --continue
|
同样是把 feature 合进 main，merge 和 rebase 在图上长这样（假设 feature 有 A、B、C 三个提交，main 在此期间也前进了）：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
| 修改前：
A---B---C feature
/
D---E---F---G main
git merge（在 main 上执行 git merge feature）：
A---B---C feature
/ \
D---E---F---G---M main ← M 是合并提交（父：C 和 G）
git rebase（在 feature 上执行 git rebase main）：
A'--B'--C' feature ← 提交被重写，接在 G 之后
/
D---E---F---G main
|
关键区别：
- merge 保留两条分支各自的历史，生成合并提交，拓扑是非线性的；
- rebase 重写当前分支的提交（产生新的提交 ID），让它们线性地接在目标分支之后，看起来像从未分叉。
黄金法则：已经推送到远程、可能被他人拉取的提交，不要 rebase ——rebase 会改写历史，导致别人的仓库和你对不上。安全用法是只 rebase 还在自己本地的提交，例如在 feature 分支上 git rebase main 把 main 的最新改动垫到自己提交之下，再合并回 main，主线就是干净的线性历史。
三、远程协作
3.1 git remote — 远程仓库管理
1
2
3
4
5
6
7
8
9
10
11
12
13
14
| # 查看远程仓库名
git remote
# 查看远程仓库详细信息（URL）
git remote -v
# 添加远程仓库
git remote add origin https://github.com/user/repo.git
# 修改远程仓库地址
git remote set-url origin https://github.com/user/new-repo.git
# 删除远程仓库
git remote remove origin
|
3.2 git fetch — 获取远程更新
1
2
3
4
5
6
7
8
9
10
11
| # 获取所有远程分支的更新（不合并）
git fetch origin
# 获取指定分支
git fetch origin main
# 获取所有远程仓库的更新
git fetch --all
# 清理远程已经删除的跟踪分支
git fetch --prune
|
3.3 git pull — 拉取并合并
1
2
3
4
5
6
7
8
9
10
11
| # 拉取当前分支的远程更新（使用默认远程和分支）
git pull
# 拉取指定远程分支的更新并合并
git pull origin main
# 使用 rebase 方式拉取（避免产生合并提交）
git pull --rebase origin main
# 拉取所有远程分支
git pull --all
|
fetch vs pull :fetch 只把远程的提交下载到本地，不动你的工作区和当前分支，是只读、安全的；pull = fetch + 合并（默认用 merge，加 --rebase 则用 rebase），会直接更新当前分支。想先看看远程有什么再决定怎么处理，用 git fetch 再手动 merge/rebase；确定要直接更新当前分支，用 git pull。
3.4 git push — 推送到远程
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
| # 推送到当前分支的跟踪远程（使用默认配置）
git push
# 推送当前分支到指定远程分支
git push origin main
# 首次推送并建立跟踪关系
git push -u origin feature/login
# 推送所有本地分支
git push --all origin
# 推送标签
git push origin v1.0.0
# 推送所有标签
git push --tags
# 删除远程分支
git push origin --delete feature/login
# 安全强制推送：远端已被他人更新时拒绝覆盖
git push --force-with-lease
|
重写已经推送的历史前，应先与协作者确认。优先使用 --force-with-lease，不要直接使用 --force。
四、撤销与回退
4.1 git reset — 回退提交
1
2
3
4
5
6
7
8
9
10
11
12
| # 回退到上一个提交（默认 --mixed 模式）
git reset HEAD~1
# 软回退：保留修改在暂存区（撤销 commit，不撤销 add）
git reset --soft HEAD~1
git reset --mixed HEAD~1
# 硬回退：丢弃所有修改（谨慎使用）
git reset --hard HEAD~1
# 回退到指定提交
git reset --soft abc1234
|
三种模式都把 HEAD 往回移，区别在"剩下的改动放哪"：
| 模式 | 工作区 | 暂存区 | 用途 |
|---|
--soft | 保留 | 保留（改动都还在暂存区） | 只撤销 commit，改动和 add 都留着，改完信息重新提交 |
--mixed（默认） | 保留 | 清空（改动退回工作区，需重新 add） | 撤销 commit 且撤销 add，重新挑选要提交的内容 |
--hard | 丢弃 | 丢弃 | 彻底放弃这些改动（不可逆，谨慎） |
HEAD~1 表示上一个提交，HEAD~3 表示往上三个提交。
4.2 git revert — 撤销提交（生成新提交）
1
2
3
4
5
6
7
8
9
| # 撤销指定提交（会生成一个新的撤销提交）
git revert abc1234
# 撤销最近一次提交
git revert HEAD
# 撤销多个提交（不自动提交，最后一起提交）
git revert --no-commit HEAD~3..HEAD
git commit -m "revert: 撤销最近三次提交"
|
reset vs revert：reset 是"回退历史"，适合未推送的提交；revert 是"新增一个撤销提交"，适合已推送的提交，不影响他人。
4.3 git checkout — 恢复文件
1
2
3
4
5
6
7
8
9
10
11
| # 恢复工作区指定文件（丢弃未暂存的修改）
git checkout -- file.md
# Git 2.23+ 推荐用 restore 替代
git restore file.md
# 从暂存区恢复文件到工作区
git restore --staged file.md
# 恢复某个文件到指定提交的版本
git restore --source=abc1234 file.md
|
4.4 git stash — 暂存工作区
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
| # 暂存当前修改
git stash
# 暂存时附加说明
git stash save "开发到一半的功能"
# 暂存时包含未跟踪的文件
git stash -u
# 查看暂存列表
git stash list
# 恢复最近一次暂存
git stash pop
# 恢复指定暂存（不删除记录）
git stash apply stash@{1}
# 删除指定暂存
git stash drop stash@{0}
# 清空所有暂存
git stash clear
|
git stash push -m "说明" 是目前更明确的写法；默认不会包含未跟踪文件，需要使用 -u。
五、标签与发布
5.1 git tag — 标签管理
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
| # 查看所有标签
git tag
# 创建轻量标签
git tag v1.0.0
# 创建附注标签（推荐，包含作者、日期、说明）
git tag -a v1.0.0 -m "正式版本 1.0.0"
# 给指定提交打标签
git tag -a v0.9.0 abc1234 -m "补打标签"
# 查看标签详情
git show v1.0.0
# 删除本地标签
git tag -d v1.0.0
# 删除远程标签
git push origin --delete v1.0.0
|
六、查看与搜索
6.1 git show — 查看对象与提交
1
2
3
4
5
6
7
8
9
10
11
| # 查看最新提交及差异
git show
# 查看指定提交
git show abc1234
# 查看某次提交中的文件内容
git show abc1234:path/to/file.md
# 查看标签指向的对象
git show v1.0.0
|
6.2 git diff — 查看差异
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
| # 查看工作区与暂存区的差异
git diff
# 查看暂存区与最新提交的差异
git diff --staged
# 查看两个提交之间的差异
git diff abc1234 def5678
# 查看指定文件的差异
git diff -- path/to/file
# 只显示变更的文件名
git diff --name-only
# 显示差异统计（增删行数）
git diff --stat
|
6.3 git blame — 查看文件每行的修改者
1
2
3
4
5
6
7
8
| # 查看文件每行的最后修改者和提交
git blame README.md
# 指定行范围（第 10 到 30 行）
git blame -L 10,30 README.md
# 只显示邮箱
git blame -e README.md
|
6.4 git grep — 在仓库中搜索
1
2
3
4
5
6
7
8
9
10
11
| # 在所有已跟踪文件中搜索关键词
git grep "TODO"
# 显示行号
git grep -n "TODO"
# 只显示文件名
git grep -l "TODO"
# 在指定提交中搜索
git grep "TODO" abc1234
|
七、实用技巧
7.1 git cherry-pick — 摘取提交
1
2
3
4
5
6
7
8
| # 将指定提交应用到当前分支
git cherry-pick abc1234
# 摘取多个提交
git cherry-pick abc1234 def5678
# 摘取提交但不自动提交（方便修改后再提交）
git cherry-pick -n abc1234
|
7.2 git bisect — 二分查找问题提交
1
2
3
4
5
6
7
8
9
10
11
12
13
14
| # 开始二分查找
git bisect start
# 标记当前提交有问题
git bisect bad
# 标记某个正常的提交
git bisect good v1.0.0
# Git 会自动切换到中间提交，测试后标记
git bisect good # 或 git bisect bad
# 找到问题提交后结束查找
git bisect reset
|
7.3 git reflog — 查看所有操作记录
1
2
3
4
5
6
7
8
| # 查看所有操作记录（包括已删除的提交和分支切换）
git reflog
# 查看指定分支的操作记录
git reflog show feature/login
# 恢复误删的提交
git checkout abc1234
|
reflog 记录了 HEAD 的每一次移动，是误操作的救命稻草。
7.4 git worktree — 多分支同时工作
1
2
3
4
5
6
7
8
| # 创建工作树（在同一仓库下同时工作在多个分支）
git worktree add ../hotfix-branch hotfix/urgent
# 查看所有工作树
git worktree list
# 删除工作树
git worktree remove ../hotfix-branch
|
7.5 常用配置
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
| # 设置用户名和邮箱
git config --global user.name "张三"
git config --global user.email "zhangsan@example.com"
# 设置默认分支名为 main
git config --global init.defaultBranch main
# 设置默认编辑器
git config --global core.editor "code --wait"
# 设置别名
git config --global alias.st status
git config --global alias.co checkout
git config --global alias.br branch
git config --global alias.ci commit
git config --global alias.lg "log --oneline --graph --all"
# 查看所有配置
git config --list
# 存储凭据（避免每次输入密码）
git config --global credential.helper manager
|
八、仓库迁移与高级操作
8.1 git bundle — 离线迁移与备份仓库历史
git bundle 把 Git 对象与引用打包成单个文件，适合隔离网络之间传输仓库，也可以制作可验证的历史备份。Bundle 可以被 clone 和 fetch 读取，但不能像普通远程仓库那样直接 push 写入。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
| # 创建包含所有可达引用的完整 Bundle
git bundle create repo-backup.bundle --all
# 检查 Bundle 格式和前置提交是否满足
git bundle verify repo-backup.bundle
# 查看 Bundle 包含哪些分支或标签
git bundle list-heads repo-backup.bundle
# 从 Bundle 克隆仓库
git clone repo-backup.bundle restored-repo
# 从 Bundle 获取 main 分支到当前仓库
git fetch repo-backup.bundle main:refs/remotes/bundle/main
# 创建 main 分支在 v1.0.0 之后的增量 Bundle
git bundle create update.bundle v1.0.0..main
|
完整 Bundle 只包含引用可达的提交和 Git 对象，不包含工作区未提交修改、暂存区、每仓库配置、Hooks 等本地状态。增量 Bundle 依赖接收方已经具有范围左侧的前置提交，接收前应执行 git bundle verify。
8.2 git submodule — 管理子模块
1
2
3
4
5
6
7
8
9
10
11
12
13
14
| # 添加另一个仓库作为子模块
git submodule add https://github.com/user/theme.git themes/theme
# 克隆后初始化并检出子模块
git submodule update --init --recursive
# 克隆时直接递归获取子模块
git clone --recurse-submodules https://github.com/user/repo.git
# 按 .gitmodules 中配置的远程分支更新
git submodule update --remote --recursive
# 查看子模块状态
git submodule status --recursive
|
父仓库记录的是子模块提交 ID，不是子模块文件内容。更新后需要分别提交子模块自身的变化和父仓库中的指针变化。
8.3 git sparse-checkout — 只检出部分目录
1
2
3
4
5
6
7
8
9
10
11
| # 启用 Cone 模式，适合按目录选择
git sparse-checkout init --cone
# 只检出两个目录
git sparse-checkout set src docs
# 再增加一个目录
git sparse-checkout add tools
# 关闭稀疏检出，恢复完整工作区
git sparse-checkout disable
|
稀疏检出主要减少工作区文件数量；若还希望减少首次下载的数据量，可在克隆时结合部分克隆参数，例如 git clone --filter=blob:none --sparse <url>。
8.4 git archive — 导出不含 Git 历史的源码包
1
2
3
4
5
6
| # 将当前 HEAD 导出为 zip
git archive --format=zip --output=source.zip HEAD
# 导出指定标签，并给文件添加顶层目录
git archive --format=tar.gz --prefix=myapp-1.0.0/ \
--output=myapp-1.0.0.tar.gz v1.0.0
|
archive 适合发布源码快照；需要保留提交历史或离线迁移时，应使用 bundle。
8.5 git clean — 清理未跟踪文件
1
2
3
4
5
6
7
8
9
10
11
| # 预览将要删除的未跟踪文件，建议先执行
git clean -n
# 删除未跟踪文件
git clean -f
# 同时删除未跟踪目录
git clean -fd
# 连被 .gitignore 忽略的文件也删除（高风险）
git clean -fdx
|
git clean 删除的文件通常不能通过 Git 恢复。先用 -n 预览，并避免在目标范围不清楚时使用 -x。
8.6 git maintenance / fsck — 维护与完整性检查
1
2
3
4
5
6
7
8
9
10
11
| # 立即运行仓库维护任务
git maintenance run
# 为当前仓库启用后台定期维护
git maintenance start
# 检查对象数据库的连通性和有效性
git fsck --full
# 查看松散对象与磁盘占用
git count-objects -vH
|
Git 通常会自动执行必要维护。除非正在诊断仓库体积或性能问题，否则不必频繁手动运行激进的清理命令。
九、提交信息规范
推荐使用 Conventional Commits（约定式提交）：用统一前缀让 git log 更易读，并为自动生成 changelog、计算语义化版本号提供依据。完整结构如下（header、body、footer 之间用空行分隔）：
1
2
3
4
5
| <type>(<scope>)!: <description>
<body>
<footer(s)>
|
- type（必填）：本次提交的性质，见下表；
- scope（可选）：影响范围，如
auth、api；使用时须放在圆括号中，省略时连同括号一起省略； - !（可选）：紧跟 type 或 scope，表示破坏性变更（breaking change）；
- description（必填）：简短描述；推荐使用祈使句，末尾不加句号；
- body（可选）：解释为什么这么改；推荐每行不超过约 72 字符；
- footer（可选，可有多个）：
BREAKING CHANGE: 说明、Closes #123 关联 issue、Refs: 引用等。
常用 type：
| 类型 | 说明 |
|---|
feat | 新功能 |
fix | 修复 Bug |
docs | 文档变更 |
style | 代码格式（不影响逻辑） |
refactor | 重构（不是新功能也不是修复） |
perf | 性能优化 |
test | 增加或修改测试 |
chore | 构建工具或辅助工具变更 |
ci | CI/CD 配置变更 |
单行示例：
1
2
3
4
| git commit -m "feat(auth): 添加 OAuth2 第三方登录"
git commit -m "fix(api): 修复分页查询越界问题"
git commit -m "docs: 更新 API 接口文档"
git commit -m "revert: 撤销 abc1234 的登录改动"
|
带破坏性变更与正文、脚注的完整示例（多个 -m 各成一段，分别对应 header / body / footer）：
1
2
3
4
5
| git commit \
-m "feat(auth)!: 移除已废弃的旧版登录接口" \
-m "旧接口自 v2.0 起弃用，本次彻底删除，调用方需改用 OAuth2。" \
-m "BREAKING CHANGE: 删除 POST /login/legacy，迁移见 #42" \
-m "Closes #40"
|
Conventional Commits 明确规定了 feat、fix 和破坏性变更的语义化版本影响：fix 对应 PATCH，feat 对应 MINOR，带 ! 或 BREAKING CHANGE: 的提交对应 MAJOR。表中的其他类型以及常见的 build（构建系统或外部依赖）、revert（撤销提交，本文 4.2 已使用）属于工具生态和团队实践中的惯例，可以自行扩展，但应在仓库内保持一致。
规范一旦推送就难改：提交信息在 commit 时写下，但真正的约束在推送之后——一旦进入远程共享历史，再改就要动 --amend / rebase，进而触发 1.4 的 amend 禁忌、2.4 的 rebase 黄金法则和 3.4 的 --force-with-lease。写的时候就写好，比推送后补救便宜得多。规范化的 type 还能让工具链自动派生价值：commitizen 引导填写、commitlint 校验、release-please / standard-version 按类型生成 changelog 与版本号。
参考资料