Appearance
Git 管理
导航目录
规范篇
基础篇
回退与撤销篇
进阶篇
- 查看当前分支从哪个分支 checkout 出来
- rebase 和 merge 的区别
- cherry-pick 摘取指定提交
- tag 标签管理
- stash 暂存进阶
- 交互式 rebase（commit 整理）
- submodule 子模块管理
分支策略篇
Git 分支命名规范
核心概念
规范化的分支命名有助于团队协作与代码管理，让每条分支的用途一目了然。约定俗成的命名通常以「用途前缀 / 描述」组成。
| 分支 | 用途 | 说明 |
|---|---|---|
master / main | 稳定生产版本 | 永远保持可发布、可上线状态 |
develop (dev) | 集成开发版本 | 正在测试但未上线的集成分支 |
feature/xxx (feat) | 功能开发 | 一个功能一条分支，完成后合回 develop |
hotfix/xxx (fix) | 紧急修复 | 从 master 拉出，修复线上紧急 Bug |
release/xxx | 预发布 | 发版前的测试与回归分支 |
命名建议
分支名使用小写字母 + 中划线，携带需求编号更易追溯，例如 feature/1024-user-login、hotfix/2048-pay-crash。
Git commit 规范
核心概念
规范的 commit message 有助于团队理解变更历史与目的，也便于自动生成 CHANGELOG。主流采用 Angular / Conventional Commits 规范：type(scope): subject。
| type | 含义 |
|---|---|
feat | 新增功能 feature |
fix | 修复 bug |
docs | 仅文档改动，如 README |
style | 格式调整（空格/分号/缩进），不改逻辑 |
refactor | 重构，非新增功能也非修 bug |
perf | 性能 / 体验优化 |
test | 增删测试用例 |
chore | 构建流程、依赖、工具等杂项 |
revert | 回滚某次提交 |
bash
# 示例
git commit -m "feat(login): 支持手机号验证码登录"
git commit -m "fix(cart): 修复优惠券叠加计算错误"提交粒度
一次 commit 只做一件事，避免"大杂烩"提交。信息用祈使句、动词开头，简洁描述"做了什么"而非"怎么做"。
Git 基本命令
核心概念
Git 基本命令覆盖日常开发的全流程：从工作区改动 → 暂存区 → 本地仓库 → 远程仓库，理解这四个区域的流转是掌握 Git 的关键。
四个区域：工作区（Working Directory）→ git add → 暂存区（Stage/Index）→ git commit → 本地仓库（Repository）→ git push → 远程仓库（Remote）。
基础操作
bash
git add <文件> # 添加指定文件到暂存区
git add . # 添加所有改动到暂存区
git status -s # 简洁查看文件状态
git commit -m "注释" # 提交暂存区（需先 add）
git commit -am "注释" # 跳过 add，直接提交已跟踪文件的改动
git commit --amend # 修改最近一次提交（信息或内容）远程操作
bash
git push # 推送到已关联的远程分支
git pull # 拉取远程并合并到本地
git push origin dev # 推送本地 dev 分支到远程
git push origin --delete dev # 删除远程 dev 分支
git remote -v # 查看远程仓库地址
git clone <url> # 克隆远程仓库分支操作
bash
git branch # 查看本地分支
git branch -a # 查看本地 + 远程所有分支
git branch feature/xxx # 创建新分支
git checkout feature/xxx # 切换分支
git checkout -b feat/xxx # 创建并切换（一步到位）
git switch feat/xxx # 新语法：切换分支
git switch -c feat/xxx # 新语法：创建并切换
git branch -D dev # 强制删除本地分支
git fetch # 拉取远程更新（不自动合并）查看操作
bash
git log -p -10 # 查看最近 10 条提交（含 diff）
git log --oneline --graph # 以图形化单行方式查看提交历史
git diff # 查看工作区未暂存的修改
git diff --cached # 查看已暂存但未提交的修改
git diff HEAD # 查看工作区 + 暂存区的所有修改
git blame <文件> # 查看文件每行的最后修改者撤销操作
bash
git reset HEAD src/xx # 取消暂存（保留改动）
git checkout src/xx # 丢弃工作区某文件的修改
git restore src/xx # 新语法：丢弃工作区修改
git merge hotfix # 合并 hotfix 分支到当前分支
git reset --hard <id> # 回退到指定版本（丢弃之后的改动）
git reset --hard HEAD~3 # 回退最近 3 次提交暂存操作
bash
git stash # 暂存当前改动（拉别人代码前用）
git stash pop # 恢复最近一次暂存并从栈中移除
git stash list # 查看暂存列表忽略文件
bash
git rm -r --cached components.d.ts # 停止跟踪已提交的文件（配合 .gitignore）常见误区
git reset --hard 会丢弃工作区改动，执行前务必确认；--cached 只是停止跟踪，不会删除本地实体文件。
Git 版本回退
核心概念
当需要回退到之前的版本时，使用 git reset。即使回退后又反悔，也能通过 git reflog 找回——Git 会记录你的每一步 HEAD 变动。
回退步骤
bash
git log # 1. 查看提交历史，找到目标 commit id
git reset --hard <id> # 2. 回退到指定版本（废弃该版本之后的提交）
git push origin --force # 3. 强推，让远程与本地一致反悔找回
bash
git reflog # 4. 查看所有 HEAD 操作历史（含被"删除"的提交）
git reset --hard <id> # 5. 找到目标操作 id，再次 reset 即可恢复强推风险
git push --force 会覆盖远程历史，多人协作分支禁止强推（会冲掉他人提交）。如需保护，可用更安全的 git push --force-with-lease。
Git commit 后如何撤销
核心概念
撤销 commit 的关键在于 --soft 与 --hard 的区别：前者保留改动，后者连改动一起丢弃。HEAD^ 表示上一次提交。
| 命令 | 效果 |
|---|---|
git reset --soft HEAD^ | 撤销 commit，保留改动在暂存区 |
git reset --mixed HEAD^ | 撤销 commit 和 add，保留改动在工作区（默认） |
git reset --hard HEAD^ | 撤销 commit、add，丢弃所有改动 |
bash
# 仅撤销 commit，代码还在（常用于重新组织提交）
git reset --soft HEAD^
# 彻底撤销并丢弃改动（慎用）
git reset --hard HEAD^只想改提交信息
若只是最近一次的 commit message 写错了，无需 reset，直接：git commit --amend。
Git 冲突后取消 merge
核心概念
当 merge 过程中产生冲突且暂时不想解决时，可以中止本次合并，回到合并前的干净状态。
bash
git merge --abort # 中止合并，恢复到 merge 前的状态提示
--abort 仅在合并尚未完成（存在冲突未提交）时可用。若已提交合并结果，需用下方 nav-7 的方式撤销。
取消已完成的合并记录
核心概念
若合并已经提交，可通过 revert（保留历史，生成反向提交）或 reset（抹掉历史）来撤销。团队协作推荐 revert。
方式一：git revert（推荐，不改历史）
bash
git log # 找到合并提交的 commit id
git revert -m 1 <mergeCommitId> # 撤销 merge，-m 1 指定保留主分支线方式二：git reset（抹掉历史，仅限本地未推送）
bash
git log # 找到合并前的 commit id
git reset --hard <beforeMergeId> # 回退到合并前revert 与 reset 的选择
已推送到远程的合并优先用 revert（安全、可追溯）；reset 会改写历史，仅适用于本地或独占分支。
查看当前分支从哪个分支 checkout 出来
核心概念
Git 不会显式记录分支的"父分支"，但可通过 reflog 中的 checkout 记录反推分支的来源。
bash
git reflog show --date=local | grep <分支名称>输出示例：
checkout: moving from master to 16069，表示16069分支是从mastercheckout 出来的。
rebase 和 merge 的区别
核心概念
merge 与 rebase 都能整合分支，核心差异在于是否保留分叉历史：merge 保留真实的分叉与合并节点，rebase 则把提交"搬"到目标分支末尾，得到一条线性历史。
| 维度 | merge | rebase |
|---|---|---|
| 提交历史 | 保留分叉，产生一个 merge commit | 线性、整洁，无额外 merge commit |
| commit id | 不变 | 会被重写（生成新 id） |
| 冲突处理 | 解决一次，产生合并提交 | 可能逐个提交解决冲突 |
| 适用场景 | 公共分支合并、保留完整脉络 | 整理个人分支、同步主干后再合入 |
bash
git checkout feature
git rebase master # 把 feature 的提交搬到 master 最新提交之后黄金法则
不要对已推送到公共仓库的提交做 rebase，否则会重写他人已拉取的历史，造成协作混乱。
cherry-pick 摘取指定提交
核心概念
cherry-pick 可以把某个分支上的一个或多个指定提交"摘取"到当前分支，常用于将 hotfix 精准同步到多个分支，而不合并整条分支。
bash
git cherry-pick <commitId> # 摘取单个提交到当前分支
git cherry-pick <id1> <id2> # 摘取多个提交
git cherry-pick <startId>..<endId> # 摘取一段区间（不含 start）
git cherry-pick --abort # 冲突时放弃
git cherry-pick --continue # 解决冲突后继续典型场景
线上紧急修复在 hotfix 分支完成后，用 cherry-pick 把该修复提交同步到 develop、release 等分支。
tag 标签管理
核心概念
tag 用于给某个提交打上版本标记（如 v1.0.0），常配合发布流程使用。分为轻量标签与带注释标签（附带说明、作者、日期）。
bash
git tag # 查看所有标签
git tag v1.0.0 # 轻量标签
git tag -a v1.0.0 -m "首个正式版" # 带注释标签
git tag -a v1.0.0 <commitId> # 给历史提交补打标签
git push origin v1.0.0 # 推送单个标签到远程
git push origin --tags # 推送所有标签
git tag -d v1.0.0 # 删除本地标签
git push origin --delete v1.0.0 # 删除远程标签stash 暂存进阶
核心概念
stash 把当前未提交的改动临时存入一个栈中，让工作区变干净（如临时切分支修 Bug），之后再恢复。
bash
git stash # 暂存当前改动
git stash save "描述" # 带描述地暂存
git stash list # 查看暂存栈
git stash pop # 恢复最近一次并从栈移除
git stash apply stash@{1} # 恢复指定暂存但保留在栈中
git stash drop stash@{0} # 删除指定暂存
git stash clear # 清空所有暂存场景
正在 feature 分支开发到一半，突然要切到 master 修紧急 Bug——git stash 存起来，修完再 git stash pop 继续。
交互式 rebase（commit 整理）
核心概念
git rebase -i 允许在合并/推送前重新整理提交历史：合并多个零碎提交、修改提交信息、调整顺序、删除提交，让历史更清晰。
bash
git rebase -i HEAD~3 # 整理最近 3 次提交进入编辑界面后，每行开头的指令可改为：
| 指令 | 作用 |
|---|---|
pick | 保留该提交（默认） |
reword | 保留提交，但修改提交信息 |
edit | 保留提交，暂停以便修改内容 |
squash | 与上一个提交合并，保留两者信息 |
fixup | 与上一个提交合并，丢弃本次信息 |
drop | 删除该提交 |
bash
# 编辑完成后若有冲突
git rebase --continue # 解决冲突后继续
git rebase --abort # 放弃整个 rebase典型场景
开发时习惯性频繁提交（"临时保存""修复拼写"），合入主干前用 squash/fixup 把它们压成一个有意义的提交。
submodule 子模块管理
核心概念
submodule 允许在一个仓库中嵌入另一个独立的 Git 仓库（如共享的组件库、SDK），主仓库只记录子模块的某个提交指针，两者版本独立管理。
bash
# 添加子模块
git submodule add <仓库url> <路径>
# 克隆含子模块的项目（一次性拉全）
git clone --recurse-submodules <url>
# 已克隆但子模块为空时，初始化并拉取
git submodule update --init --recursive
# 更新所有子模块到远程最新
git submodule update --remote
# 查看子模块状态
git submodule status注意
主仓库记录的是子模块的特定提交，修改子模块后需分别在子模块和主仓库各提交一次；克隆项目容易漏拉子模块，记得加 --recurse-submodules。
GitFlow 工作流
核心概念
GitFlow 是最经典的分支管理模型，围绕 5 类分支组织团队协作，职责分明、流程清晰，适合有明确发布周期的项目。
| 分支 | 生命周期 | 说明 |
|---|---|---|
master | 长期 | 只存放发布的稳定版本，每次合入打 tag |
develop | 长期 | 集成所有已完成功能的开发主干 |
feature/* | 临时 | 从 develop 拉出开发新功能，完成后合回 develop |
release/* | 临时 | 从 develop 拉出做发布前测试，完成后合入 master 和 develop |
hotfix/* | 临时 | 从 master 拉出修复线上问题，完成后合入 master 和 develop |
text
feature/* ──► develop ──► release/* ──► master
▲ ▲ │
└──────────┴───────────────────┘ (release/hotfix 合回 develop)
master ──► hotfix/* ──► master + develop (线上紧急修复)轻量替代
小团队 / 持续部署项目可采用更轻量的 GitHub Flow（只有 master + 短生命周期 feature 分支，PR 合入即部署）。
分支方案图 & 常用命令速查表
分支方案 A
功能说明：包含 master、develop、feature 等分支的经典方案。
分支方案 B
功能说明：另一种适用于不同团队工作流程的分支策略。
常用命令速查表
| 场景 | 命令 |
|---|---|
| 创建并切换分支 | git checkout -b feat/xxx |
| 撤销工作区改动 | git checkout <文件> / git restore <文件> |
| 取消暂存 | git reset HEAD <文件> |
| 仅撤销 commit（留代码） | git reset --soft HEAD^ |
| 版本回退 | git reset --hard <id> |
| 找回丢失的提交 | git reflog |
| 中止冲突合并 | git merge --abort |
| 撤销已提交的合并 | git revert -m 1 <mergeId> |
| 摘取指定提交 | git cherry-pick <id> |
| 整理提交历史 | git rebase -i HEAD~n |
| 临时暂存改动 | git stash / git stash pop |
| 打版本标签 | git tag -a v1.0.0 -m "..." |
| 修改最近提交 | git commit --amend |
高危命令提醒
reset --hard、push --force、clean -fd 均具破坏性，执行前确认后果；公共分支的历史改写操作（force push / rebase）务必先与团队沟通。