Git

初始化

git config --global user.name "填写自己的用户名" # 配置个人用户名
git config --global user.email "填写自己的邮箱号"  # 电子邮件地址
git config --global core.autocrlf false # 结束符CRLF和LF 之间转换

git status

查看当前文件的状态

git stash

将当前工作目录中尚未提交的所有更改（包括暂存区和未暂存的修改）临时存储到 stash 堆栈中

• git stash save

  git stash save -u "注释"
  # -u 表示还工作区中新增的文件
  # 不加u只会存储工作区中已经存在的文件的修改

• git stash list
• git stash push 同 save
• git stash pop 弹出
• git stash apply 读
• git stash drop 删

git add

• 把指定的文件添加到暂存区中

• git add 文件路径

• 添加所有修改、已删除的文件到暂存区中

• git add -u 文件路径

• git add --update 文件路径

• 添加所有修改、已删除、新增的文件到暂存区中，省略 文件路径 即为当前目录

• git add -A 文件路径

• git add --all 文件路径

• 查看所有修改、已删除但没有提交的文件，进入一个子命令系统

• git add -i 文件路径

• git add --interactive 文件路径

git commit

命令格式	核心含义	补充说明（适用场景 / 注意点）
-m "描述信息"	提交暂存区文件，直接通过 -m 指定提交说明（无需打开编辑器）	日常最常用
-a -m "描述信息"	提交所有已跟踪文件的修改/删除（无需先 git add），直接指定说明	1. -a = --all，等价于先执行 git add -u（仅跟踪已被版本库管理的文件）；2. 不包含新增未跟踪文件（需手动 git add 新增文件）；3. 场景：快速提交已有文件的修改/删除，无需分步 add
--amend	合并当前修改（暂存区/工作区）到上一次提交，打开编辑器可修改提交说明	1. 仅限本地未推送的提交；2. 无修改时执行，仅可修改上一次的提交说明
--amend --no-edit	合并当前修改到上一次提交，不修改原提交说明（无编辑器交互，一步完成）	场景：补改小问题（如笔误、注释），不想新建提交，也不想改原说明
-n -m/--no-verify -m "描述信息"	跳过提交前的钩子校验（pre-commit），强制提交	1. -n = --no-verify；2. 仅限临时紧急场景（如线上 bug 修复），禁止滥用（破坏代码规范）

git log

基础概念

git log 核心作用：查看本地仓库的提交历史记录，支持多维度筛选、格式化输出，是排查提交问题、追溯代码变更的核心命令。

核心用法 & 常用参数

命令	含义	补充说明
git log	默认格式显示提交记录（完整信息：提交 ID、作者、时间、提交说明）	翻页操作：空格=下翻页、b=上翻页、q=退出；按回车逐行查看
git log --pretty=oneline	单行显示每条提交（格式：完整 commit ID + 提交说明）	简化输出，便于快速浏览提交列表
git log --oneline	简写版单行显示（格式：7 位短 commit ID + 提交说明）	最常用的快速查看方式，比 --pretty=oneline 更精简
git log --pretty=short	精简显示（仅保留作者名称，省略邮箱，提交说明完整）	平衡详细度和简洁度，适合查看核心提交信息
git log <commit ID>	显示从第一次提交到指定 commit ID 的所有记录	如需显示指定 commit 之后的记录：git log <commit ID>..HEAD
git log --graph	图形化显示提交历史（用 ASCII 字符绘制分支合并关系）	配合 --oneline 使用更佳：git log --graph --oneline，直观看到分支走向
git log -p	显示每个提交的详细代码修改（diff 内容）	排查“哪次提交改了某行代码”时常用，可加文件路径：git log -p <文件路径>
git log --author="用户名"	筛选指定作者的提交记录（支持模糊匹配，如邮箱后缀）	示例：git log --author="zhangsan"、git log --author="@company.com"
git log --since="时间"	筛选指定时间之后的提交（--until 筛选之前）	时间格式：1 week ago、2026-02-01、yesterday；示例：git log --since="3 days ago"
git log --grep="关键词"	按提交说明中的关键词筛选记录	区分大小写，加 -i 忽略大小写：git log --grep="修复bug" -i
git log --reverse	反向显示提交记录（从第一次提交到最新提交）	默认是从最新到最早，--reverse 反转顺序
git log 分支A..分支B	显示分支 B 有、但分支 A 没有的提交（对比两个分支的差异提交）	排查“分支 B 比分支 A 多了哪些提交”时常用
git log -n 5	仅显示最近 5 条提交记录（n 为数字，指定条数）	快速查看最新提交，示例：git log --oneline -n 10（最近 10 条单行显示）

场景示例

# 1. 图形化查看最近10条提交，单行显示（最常用）
git log --graph --oneline -n 10

# 2. 查看张三最近3天的提交，仅显示提交说明
git log --author="张三" --since="3 days ago" --oneline

# 3. 查看src/utils.js文件的所有修改记录（含代码diff）
git log -p src/utils.js

git shortlog

基础概念

git shortlog 核心作用：按提交者汇总提交记录，生成简洁的提交统计报告，适合团队协作时统计成员提交量、梳理提交归属。

核心参数 & 用法

命令	含义	补充说明
git shortlog	默认按作者字母排序，显示每个作者的提交说明列表	输出格式：作者名 + 换行 + 缩进的提交说明
git shortlog -s	仅显示“提交次数 + 作者名”（省略提交说明，仅统计数量）	s = summary，摘要模式，最常用的统计方式
git shortlog -n	按提交次数从多到少排序（默认按作者字母排序）	需配合 -s 使用：git shortlog -s -n，直观看到提交量排名
git shortlog -e	显示作者的邮箱地址（默认仅显示用户名）	示例：git shortlog -s -n -e，统计时关联邮箱，避免重名混淆
git shortlog -w 80,10,20	设置输出行宽（总宽度 80，作者名宽度 10，提交说明缩进 20）	自定义排版，适合导出统计报告
git shortlog 分支A..分支B	统计分支 B 比分支 A 多的提交中，各作者的提交量	排查“某分支中谁提交了代码”

场景示例

# 1. 团队提交量排名（仅显示次数和作者，最常用）
git shortlog -s -n

# 2. 团队提交量排名（显示邮箱，避免重名）
git shortlog -s -n -e

# 3. 统计近1个月的提交量排名
git log --since="1 month ago" | git shortlog -s -n

git reflog

基础概念

核心作用：记录HEAD 指针的所有移动记录（包括 checkout、reset、rebase、commit 等操作），哪怕是被 reset/delete 的提交，也能通过 reflog 找回（git log 仅显示“可达”的提交，reflog 显示所有操作），是恢复误操作的“救命命令”。

核心特性

• 仅保存在本地，不会推送到远程；
• 默认保留 90 天（过期自动清理）；
• 每条记录格式：序号: HEAD@{序号} commit ID 操作说明（如 checkout、reset）。

核心用法 & 场景

命令	含义	补充说明
git reflog	显示 HEAD 的所有操作记录（默认按时间倒序）	核心恢复工具，能找到所有误操作前的节点
git reflog show 分支名	显示指定分支的 HEAD 操作记录（默认显示当前分支）	示例：git reflog show main，查看 main 分支的操作记录
git reflog --oneline	单行精简显示 reflog 记录	快速浏览操作历史，便于定位误操作节点

关键场景：恢复误操作的提交

# 场景：误执行 git reset --hard HEAD~3，丢失了最近3次提交
# 1. 查看reflog，找到重置前的HEAD状态（比如 HEAD@{1} 是重置前的节点）
git reflog

# 2. 恢复到该节点（两种方式，推荐方式2更安全）
# 方式1：直接reset回退到该节点（代码同步恢复）
git reset --hard HEAD@{1}

# 方式2：基于该commit ID创建新分支（避免覆盖当前分支）
git checkout -b recover-bug HEAD@{1}

四、关键注意事项

1. git log 仅显示“可达”提交：通过 reset、rebase 让提交“不可达”时，git log 看不到，但 git reflog 能找回；
2. git reflog 是本地日志：远程仓库无此记录，无法恢复远程已删除的分支/提交；
3. 翻页操作通用：git log/git shortlog 均支持 空格（下翻）、b（上翻）、q（退出）；
4. 统计团队提交：git shortlog 前建议先 git fetch --all 拉取所有远程提交，确保统计完整。

git reset

一、基础概念

git reset（重置）核心作用：修改本地仓库的 HEAD 指针指向，并可按需重置暂存区、工作区的代码状态，仅用于本地未推送到远程的提交（已推送提交禁止使用，会破坏公共历史）。

• 核心逻辑：通过不同参数，控制「HEAD 指针移动范围」「暂存区是否重置」「工作区是否重置」，是本地撤销提交/暂存操作的核心命令。

二、核心参数详解（按重置范围划分）

git reset 默认为 --mixed 模式，三个核心参数的重置范围对比如下：

参数	HEAD 指针（本地库）	暂存区	工作区	核心效果	通俗理解
--soft	✅ 移动到指定节点	❌ 不变	❌ 不变	仅移动 HEAD 指针，暂存区/工作区代码保留（回到「已提交 → 未提交」状态）	撤销提交记录，但代码还在，可直接重新 commit
--mixed（默认）	✅ 移动到指定节点	✅ 重置	❌ 不变	移动 HEAD 指针 + 重置暂存区（撤销 git add），工作区代码保留	撤销提交 + 撤销 git add，代码回到「未 add、未 commit」状态
--hard	✅ 移动到指定节点	✅ 重置	✅ 重置	移动 HEAD 指针 + 重置暂存区 + 重置工作区（代码直接回退到指定节点）	彻底回退，指定节点后的所有修改（提交/暂存/工作区）全部丢失，无法恢复

三、常用用法分类

1. 重置暂存区（撤销 git add）

用于将已 git add 到暂存区的文件撤出，保留工作区修改（最常用场景）：

# 撤销单个文件的 git add（默认 --mixed，可省略）
git reset <文件路径>
# 等价写法（显式指定 --mixed）
git reset --mixed <文件路径>
# 撤销所有文件的 git add
git reset  # 无文件路径，默认重置所有暂存区文件

2. 回退提交记录（指定 commit ID）

用于将 HEAD 指针回退到指定历史提交节点，按需控制代码保留/删除：

# --soft：仅回退提交记录，代码保留（暂存区/工作区不变）
git reset --soft <commit ID>
# --mixed（默认）：回退提交 + 重置暂存区，代码保留（工作区不变）
git reset <commit ID>  # 省略 --mixed
git reset --mixed <commit ID>
# --hard：彻底回退，代码也恢复到指定节点（慎用！）
git reset --hard <commit ID>

3. 相对引用回退（快速回退最近 N 次提交）

无需查 commit ID，用 HEAD~N 或 HEAD^^^ 快速回退：

# 回退最近 3 次提交（--hard 模式，代码也重置）
git reset --hard HEAD~3
# 等价写法（^ 数量 = 回退步数）
git reset --hard HEAD^^^
# 回退最近 1 次提交（最常用，保留代码用 --soft）
git reset --soft HEAD~1  # 等价 git reset --soft HEAD^

四、关键注意事项（避坑必记）

1. --hard 不可逆风险：git reset --hard 会直接删除工作区未提交的修改，且无法恢复，执行前务必用 git status/git stash 暂存重要修改；
2. 仅限本地使用：已推送到远程的提交，绝对禁止用 git reset（会导致本地和远程历史不一致），如需撤销已推送提交，改用 git revert；
3. 相对引用规则：HEAD~N 表示“HEAD 往前数 N 个提交”，HEAD^ 等价 HEAD~1，HEAD^^ 等价 HEAD~2，以此类推；
4. 重置后推送到远程：若重置后需推送（仅限个人分支），需强制推送 git push -f，公共分支禁止 -f。

五、常用场景示例

场景 1：撤销刚执行的 git add .（不想暂存了）

git add .  # 误把所有文件加入暂存区
git reset  # 重置所有暂存区文件，工作区修改保留

场景 2：撤销最近 1 次提交（保留代码，想重新修改后提交）

git commit -m "错误提交"  # 提交后发现代码漏改
git reset --soft HEAD~1  # 撤销提交，代码仍在工作区/暂存区
# 修改代码后重新提交
git add . && git commit -m "修正后的提交"

场景 3：彻底放弃最近的修改，回到 3 次提交前的版本

# 确认当前修改无需保留，彻底回退
git reset --hard HEAD~3
# 验证：工作区已恢复到 3 次提交前的状态
git status  # 显示 "working tree clean"

场景 4：撤销单个文件的 git add（仅撤出指定文件）

git add src/utils.js src/api.js  # 误加了两个文件
git reset src/api.js  # 仅撤出 src/api.js，src/utils.js 仍在暂存区

---

总结

1. git reset 核心是「移动 HEAD 指针 + 重置暂存区/工作区」，分 --soft（仅撤提交）、--mixed（撤提交+撤 add）、--hard（彻底回退）；
2. 日常最常用：git reset 撤销 add、git reset --soft HEAD~1 撤销最近提交（保留代码）；
3. 避坑核心：--hard 慎用、已推送提交不用 reset、公共分支不强制推送。

git rebase

一、基础概念

git rebase（变基）核心作用：将一个分支的提交记录，“嫁接”到另一个分支的指定节点上，让提交历史保持线性、整洁，替代 git merge 避免产生分叉的合并节点。

• 核心逻辑：找到两个分支的共同祖先节点 → 把共同节点后当前分支的所有提交，重新嫁接到目标分支的最新节点上 → 嫁接后原提交的 commit ID 会改变（因为提交上下文变了）→ 最终移动 HEAD 到嫁接后的最新 commit 处。

二、核心用法分类

1. 交互式 rebase（最常用，git rebase -i）

用于修改、合并、删除本地提交（仅限未推送到远程的提交），指令后需跟“要修改的提交的父节点 ID/相对引用”（如 HEAD~3 表示最近 3 个提交，或具体 commit ID）。

git rebase -i <目标节点>  # 例：git rebase -i HEAD~3 （修改最近3个提交）
git rebase -i <共同祖先ID>  # 精准指定起始节点

执行后弹出编辑窗口，支持以下指令（缩写/全称均可）：

指令缩写	全称	含义
p	pick	保留该提交（默认）
r	reword	保留提交，但修改提交说明（仅改备注，不改代码）
e	edit	保留提交，但暂停变基流程，允许修改该提交的代码（改完需手动继续）
s	squash	将该提交合并到上一个提交中，保留该提交的备注（合并后可编辑总备注）
f	fixup	同 squash，但丢弃该提交的备注，仅保留代码修改
x	exec	对该提交执行指定的 shell 命令（如 x npm run lint）
d	drop	删除该提交（直接移除，慎用）

2. 基础变基（非交互式）

将当前分支的提交嫁接到目标分支的最新节点（日常拉取代码常用）：

git rebase <目标分支>  # 例：git rebase main （把当前分支嫁接到main最新节点）

三、变基流程中的救场命令

（解决冲突、暂停/放弃变基）

命令	用途
git rebase --continue	解决冲突后，继续执行变基流程（需先 git add . 标记冲突已解决）
git rebase --abort	放弃本次变基，恢复到变基前的状态（变基出错时首选）
git rebase --skip	跳过当前有问题的提交（非必要不使用，可能丢代码）

四、核心避坑规则（必记）

1. 绝对禁止在 master/main 等公共分支（多人协作的远程分支）执行 rebase，会修改公共提交历史，导致团队代码冲突；
2. 仅对本地未推送的提交使用 rebase（修改历史），已推送的提交如需调整，改用 git revert；
3. 变基过程中遇到冲突，需逐个解决（每次解决后 git add . + git rebase --continue），不要强行终止；
4. 嫁接后原提交的 commit ID 会改变，若已推送过该分支，需强制推送（git push -f），但仅在个人分支执行，公共分支禁止 -f。

五、常用场景示例

场景 1：整理本地提交（合并多个零散提交）

# 1. 查看最近3个提交的ID
git log --oneline -3
# 2. 交互式修改最近3个提交
git rebase -i HEAD~3
# 3. 在编辑窗口将多余提交的 p 改为 f/s，保存退出
# 4. 解决冲突（如有），完成变基
git add . && git rebase --continue

场景 2：拉取远程最新代码并保持历史线性

# 切换到个人分支
git checkout my-feature
# 拉取main最新代码并变基（替代 git pull）
git fetch origin main && git rebase origin/main
# 推送变基后的分支（个人分支可强制推送）
git push -f origin my-feature

---

总结

1. git rebase -i 是本地整理提交的核心指令，支持修改、合并、删除提交；
2. 变基的核心是“重新嫁接提交”，会改变原有 commit ID，仅限本地/个人分支使用；
3. 冲突处理用 git rebase --continue，放弃变基用 git rebase --abort，公共分支绝对不做 rebase。

git checkout

一、基础概念

git checkout（检出命令）是 Git 多功能核心命令，核心作用有两类：

1. 切换工作区的引用（分支、历史 commit、Tag）；
2. 恢复/撤销工作区的文件修改；
   • ⚠️ 新版 Git（2.23+）推荐
   • git switch 替代「分支切换」
   • git restore 替代「文件恢复」

二、核心用法分类（按场景）

1. 分支相关操作（最常用）

命令	含义	补充说明
git checkout <分支名称>	切换到本地已存在的指定分支	切换前建议用 git stash 暂存未提交修改，避免冲突；切换后工作区同步该分支最新代码
git checkout -b <分支名称>	创建并切换到指定分支，保留所有提交记录	等价于 git branch <分支名> + git checkout <分支名>；可基于指定节点创建：git checkout -b 新分支 目标节点（commit/分支）
git checkout --orphan <分支>	创建并切换到“孤儿分支”（无任何提交记录），仅保留当前工作区文件	用途：清空分支历史（如项目重构）、创建全新根分支；需手动 git commit 后才会生成分支记录
git checkout <远程分支名>	切换到本地不存在、但远程已有的分支（自动创建本地追踪分支）	等价于 git checkout -b 本地分支名 origin/远程分支名；需先 git fetch 拉取远程分支信息

2. 文件恢复/撤销修改

命令	含义	补充说明
git checkout <文件路径>	替换本地工作区该文件的改动，恢复到最近一次 commit/暂存区的状态	新增文件（未 git add）不受影响；已添加到暂存区的内容（git add 后）也不受影响
git checkout -- <文件路径>	显式撤销工作区文件修改（推荐写法，避免和分支名冲突）	⚠️ 危险：撤销的修改无法恢复，执行前确认不需要该改动
git checkout HEAD -- <文件路径>	强制将文件恢复到 HEAD 指向的最新提交版本（覆盖暂存区+工作区）	比无 HEAD 的写法更精准，适合暂存区也有错误修改的场景

3. 切换到历史提交/Tag（游离 HEAD）

命令	含义	补充说明
git checkout <commit ID>	切换到指定历史提交的快照，进入「游离 HEAD（detached HEAD）」状态	仅用于查看/排查旧代码，禁止在此状态提交代码（切回分支后提交会丢失）；回到正常分支：git checkout 原分支名
git checkout <Tag 名称>	切换到指定 Tag 对应的版本，同样进入游离 HEAD 状态	Tag 是版本快照，只读；如需基于 Tag 开发，需创建分支：git checkout -b 新分支 Tag名

三、关键注意事项（避坑必记）

1. 游离 HEAD 风险：切换到 commit/Tag 后处于游离状态，此时的提交不属于任何分支，切回分支前需通过 git checkout -b 新分支 保留提交，否则会丢失；
2. 文件撤销不可逆：git checkout -- 文件 会直接覆盖工作区修改，无备份，执行前建议用 git status/git diff 确认改动；
3. 分支名与文件名冲突：若存在和分支名同名的文件，git checkout 名称 会优先识别为分支，需用 git checkout -- 名称 明确指定操作文件；
4. 新版命令替代：
   • 分支切换 → 优先用 git switch <分支名>（语义更清晰）；
   • 文件恢复 → 优先用 git restore <文件路径>（拆分后更易理解）；
   • checkout 可作为兜底，但新手建议分开学 switch/restore。

四、常用场景示例

场景 1：基于远程分支创建本地分支

git fetch origin  # 拉取远程所有分支信息
git checkout dev  # 自动创建本地dev分支并追踪origin/dev

场景 2：撤销工作区单个文件的错误修改

git checkout -- src/utils.js  # 撤销src/utils.js的所有未提交修改

场景 3：基于历史提交创建新分支（保留游离状态的改动）

git checkout a1b2c3d  # 切换到历史提交（游离状态）
git checkout -b fix-bug-a1b2  # 基于该提交创建新分支，脱离游离状态

场景 4：创建孤儿分支（清空历史）

git checkout --orphan new-main  # 创建无历史的孤儿分支
git rm -rf .  # 删除原有文件（可选，如需完全清空）
touch README.md && git add . && git commit -m "初始化新分支"  # 首次提交，生成分支记录

---

总结

1. git checkout 核心是「切换引用」和「恢复文件」，新版推荐用 switch（分支）+ restore（文件）拆分；
2. 分支操作重点记 -b（新建切换）、--orphan（无历史分支）；
3. 文件操作慎用 -- 写法，避免不可逆丢失修改；
4. 游离 HEAD 只看不改，如需开发需先创建分支。

git revert

1. 基础概念

git revert（反向提交）核心作用：创建一个新的提交，抵消指定 commit 的所有代码修改，仅撤销代码改动，不删除任何历史提交记录，是已推送提交的“安全撤销方式”。

• 核心逻辑：与 git reset 完全不同 → reset 是“抹除历史、重置 HEAD 指针”，revert 是“新增提交、抵消改动”；revert 后原提交仍保留在历史中，仅新增一条“撤销提交”，对协作团队无影响。

2. 核心参数详解

命令格式	含义	补充说明
git revert <commit ID>（默认 -e）	抵消指定 commit 的改动，弹出编辑窗口让你修改新提交的备注（-e = --edit）	默认行为，推荐保留备注（清晰说明“撤销了哪个提交”）
git revert --no-edit <commit ID>	抵消指定 commit 的改动，不弹出编辑窗口，使用默认备注（“Revert xxx”）	批量撤销时常用，节省时间
git revert -n / --no-commit <commit ID>	抵消指定 commit 的改动，但不自动创建新提交，仅将改动同步到暂存区+工作区	用途：1. 批量撤销多个 commit 后合并为一个新提交；2. 撤销后需手动调整代码再提交
git revert HEAD	快速撤销最近一次提交（已推送/未推送均可）	最常用场景，无需查 commit ID
git revert <commit1>..<commit2>	批量撤销从 commit1 到 commit2 的所有提交（左开右闭，需按顺序）	例：git revert A..D 撤销 B、C、D 三个提交；需解决多次冲突（如有）

3. 冲突处理（必记）

revert 过程中若出现代码冲突（比如被撤销的 commit 代码已被后续提交修改），处理流程：

# 1. 解决文件中的冲突（标记为 <<<<<<< HEAD 的部分）
# 2. 标记冲突已解决
git add .
# 3. 继续执行 revert 流程
git revert --continue
# （可选）放弃本次 revert
git revert --abort

4. 避坑规则

• 仅撤销“代码改动”：revert 只抵消指定 commit 的代码修改，不会删除该 commit 的历史记录；
• 已推送提交首选：所有推送到公共分支的提交，如需撤销，必须用 revert（禁止用 reset/rebase 修改历史）；
• 重复 revert：若 revert 后想恢复被撤销的 commit，需再次 revert 该“撤销提交”（而非直接 reset）。

5. 常用场景示例

场景 1：撤销已推送的最近一次提交（安全）

git revert HEAD --no-edit  # 撤销最近一次提交，不编辑备注
git push  # 推送新的撤销提交，团队同步

场景 2：批量撤销多个提交并合并为一个

# 撤销 A、B 两个提交，不自动创建 commit
git revert -n A
git revert -n B
# 手动调整代码（如有），合并为一个新提交
git add .
git commit -m "撤销 A、B 两个提交的错误改动"
git push

---

git merge

1. 基础概念

git merge（合并）核心作用：将指定分支的提交记录合并到当前所在分支，是多分支协作的核心命令。

• 核心逻辑：找到两个分支的共同祖先节点，对比当前分支和目标分支的最新节点差异，生成一个“合并提交”（除非是 Fast-forward 合并），保留所有分支的历史记录。

2. 核心用法

命令格式	含义	补充说明
git merge <目标分支名>	将指定分支的代码合并到当前分支（如在 main 分支执行 git merge dev）	合并前建议先拉取远程最新代码：git pull --rebase
git merge --no-ff <目标分支名>	强制生成合并提交（禁用 Fast-forward 合并），保留分支合并记录	团队协作推荐使用，可清晰看到“哪次合并来自哪个分支”
git merge --abort	合并过程中出现冲突，放弃本次合并，恢复到合并前的状态	冲突无法解决时使用，避免代码混乱
git merge --continue	解决冲突后，继续完成合并流程	需先 git add . 标记冲突已解决

3. 合并类型（关键区别）

合并类型	触发条件	效果
Fast-forward（快进）	目标分支是当前分支的直接后继（无分叉），共同祖先后当前分支无新提交	不生成合并提交，直接将当前分支 HEAD 指向目标分支最新节点，历史线性
普通合并（No-ff）	两个分支有分叉（共同祖先后双方都有新提交），或显式指定 --no-ff	生成一个新的“合并 commit”，历史会出现分叉，保留分支合并轨迹

4. 冲突处理（合并核心难点）

合并冲突是多分支协作的常见场景，处理流程：

# 1. 执行合并，触发冲突
git merge dev
# 2. 查看冲突文件（git status 会标记为 both modified）
git status
# 3. 打开冲突文件，解决 <<<<<<< HEAD 到 >>>>>>> dev 之间的代码冲突
# 4. 标记冲突已解决
git add .
# 5. 完成合并（自动生成合并提交）
git merge --continue
# （可选）放弃合并
git merge --abort

5. 避坑规则

• 合并前清理工作区：确保当前分支工作区无未提交修改（用 git stash 暂存），避免合并冲突叠加；
• 优先拉取最新代码：合并前执行 git pull --rebase 拉取远程最新，减少冲突概率；
• 公共分支合并规范：合并功能分支到 main/dev 前，建议先在功能分支 rebase 目标分支（减少合并提交）。

6. 常用场景示例

场景 1：常规合并（功能分支合并到 main）

git checkout main  # 切换到主分支
git pull --rebase  # 拉取远程最新
git merge --no-ff feature/login  # 合并登录功能分支，强制生成合并提交
git push  # 推送合并结果

场景 2：合并冲突处理示例

git merge dev  # 触发冲突
# 解决 src/app.js 冲突后
git add src/app.js
git merge --continue  # 完成合并

---

reset vs revert vs merge

命令	核心目的	是否修改历史	已推送可用？	适用场景
git reset	本地回退/撤销提交	✅ 抹除历史	❌ 绝对禁止	本地未推送的错误提交
git revert	撤销指定提交的代码改动	❌ 新增提交	✅ 最安全	已推送的错误提交、公共分支
git merge	合并分支代码	❌ 新增提交	✅ 正常使用	多分支协作、功能合并

---

总结

1. git revert 是已推送提交的“安全撤销工具”，核心是“新增提交抵消改动”，不删历史；
2. git merge 是分支合并核心，推荐用 --no-ff 保留合并记录，冲突需逐文件解决；
3. 三者核心区别：reset 改本地历史、revert 安全撤销代码、merge 合并分支，已推送场景优先用 revert/merge。

git cherry-pick

• 把已经提交的记录合并到当前分支。
• git cherry-pick commit ID
• pick 两个节点 1 和 3
• git cherry-pick commit ID1 commit ID3
• pick （节点 1，节点 3] 不包含节点 1
• git cherry-pick commit ID1 .. commit ID3
• pick [节点 1，节点 3] 包含节点 1
• git cherry-pick commit ID1 ^.. commit ID3

git tag

操作标签的命令。

• 打印所有的标签

• git tag

• 添加轻量标签，指向提交对象的引用，可以指定之前的提交记录

• git tag 标签名称 commit ID

• 添加带有描述信息的附注标签，可以指定之前的提交记录

• git tag -a 标签名称 -m 标签描述信息 commit ID

• 切换到指定的标签

• git checkout 标签名称

• 查看标签的信息

• git show 标签名称

• 删除指定的标签

• git tag -d 标签名称

git mv

• 重命名文件或者文件夹。
• 重命名指定的文件或者文件夹
• git mv 源文件/文件夹 目标文件/文件夹

git rm

• 删除文件或者文件夹。

• 移除跟踪指定的文件，并从本地仓库的文件夹中删除

• git rm 文件路径

• 移除跟踪指定的文件夹，并从本地仓库的文件夹中删除

• git rm -r 文件夹路径

• 移除跟踪指定的文件，在本地仓库的文件夹中保留该文件

• git rm --cached

git remote

• 操作远程库。

• 列出已经存在的远程仓库

• git remote

• 列出远程仓库的详细信息，在别名后面列出 URL 地址

• git remote -v

• git remote --verbose

• 添加远程仓库

• git remote add 远程仓库的别名 远程仓库的URL地址

• 修改远程仓库的别名

• git remote rename 原远程仓库的别名 新的别名

• 删除指定名称的远程仓库

• git remote remove 远程仓库的别名

• 修改远程仓库的 URL 地址

• git remote set-url 远程仓库的别名 新的远程仓库URL地址

git pull

从远程仓库获取最新版本并合并到本地。

• 首先会执行 git fetch，然后执行 git merge，把获取的分支的 HEAD 合并到当前分支。

• 从远程仓库获取最新版本。

• git pull

• git pull --rebase 远程仓库的别名 分支名称

• 从远程仓库获取最新版本并变基到当前分支。

git push

把本地仓库的提交推送到远程仓库。

• 把本地仓库的分支推送到远程仓库的指定分支

• git push 远程仓库的别名 本地分支名:远程分支名

• 将指定的标签提交到远程仓库

• git push 远程仓库的别名 标签名称

• 将本地所有的标签全部提交到远程仓库

• git push 远程仓库的别名 –tags

• 删除指定的远程仓库的分支

• git push 远程仓库的别名 :远程分支名

• git push 远程仓库的别名 --delete 远程分支名

git clone

• 只拉取最近的一个 revision git clone --depth=1

• 拉取指定分支 git clone -b dev

• 只克隆一个裸仓库 git clone --bare **.git

git branch

• 操作 Git 的分支命令。

• 列出本地的所有分支，当前所在分支以 "*" 标出

• git branch

• 列出本地的所有分支并显示最后一次提交，当前所在分支以 "*" 标出

• git branch -v

• 创建新分支，新的分支基于上一次提交建立

• git branch 分支名

• 修改分支名称

• 如果不指定原分支名称则为当前所在分支

• git branch -m 原分支名称 新的分支名称

• 强制修改分支名称

• git branch -M 原分支名称 新的分支名称

• 删除指定的本地分支

• git branch -d 分支名称

• 强制删除指定的本地分支

• git branch -D 分支名称

git fetch

• 从远程仓库获取最新的版本到本地的 tmp 分支上。

• 将远程仓库所有分支的最新版本全部取回到本地

• git fetch 远程仓库的别名

• 将远程仓库指定分支的最新版本取回到本地

• git fetch 远程主机名 分支名

git diff

• 比较版本之间的差异。

• 比较当前文件和暂存区中文件的差异，显示没有暂存起来的更改

• git diff

• 比较暂存区中的文件和上次提交时的差异

• git diff --cached

• git diff --staged

• 比较当前文件和上次提交时的差异

• git diff HEAD

• 查看从指定的版本之后改动的内容

• git diff commit ID

• 比较两个分支之间的差异

• git diff 分支名称 分支名称