Git | 标签操作
2025/12/28 12:06:35
基本概念
将当前分支的提交移动到另一个基端
base上，从而重新组织提交历史与
merge不同，rebase会创建新提交来替代旧提交，使得提交历史呈现线性结构
适用场景
- 整理本地提交历史—— 在推送前用
rebase整理杂乱的分支提交，使其更清晰 - 避免不必要的合并提交—— 希望提交历史是线性结构时（如开源项目的
PR） - 同步上游代码—— 将当前分支基于上游最新代码重新应用更改（如
git pull --rebase）
原理
初始状态
初始时，
master分支与feature分支均有提交，HEAD当前分支在feature，此时执行指令：gitrebase master# feature分支上执行，将当前分支feature变基到目标分支master上
找到共同祖先
- 找到当前分支
feature和目标分支master的最近共同祖先common ancestor，即两个分支分叉处的提交
提取当前分支独有提交
- 从共同祖先开始，提取当前分支
feature之后的所有提交更改，保存为临时补丁
应用提交到目标分支
移动
feature分支的指针到master的最新提交（新基端）此时
feature的提交历史没有指针指向，暂时丢失游离（可以通过git reflog找回）将之前提取的补丁应用到
master新基端，生成新提交（内容相同，提交哈希值不同）如果遇到冲突，
Git暂停rebase过程，解决冲突后继续gitaddgitrebase --continue
对比merge（合并）与rebase（变基）
示意图
- 变基—— 在当前分支
feature执行git rebase master，将feature的提交嫁接到master上，重写历史，保持线性
- 合并—— 在当前分支
feature执行git merge master，将master的提交合并到feature上，生成合并提交，保留历史
关键区别
rebase重写历史，merge保留历史rebase让feature的提交看起来基于master的最新提交开发（线性历史）merge会保留分支的分叉和合并记录（非线性的历史）
merge会生成新提交，rebase不会merge一定会生成合并提交，即使没有冲突rebase只是重新应用提交，不会额外生成提交
rebase更适合本地整理，merge更适合公共分支- 如果在开发本地分支，并希望提交历史清晰，用
rebase - 如果在合并公共分支（如团队协作的
develop），用merge更安全
- 如果在开发本地分支，并希望提交历史清晰，用
指令介绍
变基分支git rebase
语法
git rebase [选项] <目标分支>参数 说明 -i/--interactive进入交互式变基（可修改提交） --continue解决冲突后继续变基 --abort终止变基，恢复到变基前的状态 --skip跳过当前提交（冲突无法解决时使用） --onto <新基端>将提交移动到另一个基端（复杂变基场景） -p/--preserve-merges保留合并提交（默认会丢弃） --autostash自动暂存未提交的更改（防止变基失败） 具体示例
基本变基 —— 将当前分支
feature变基到目标分支master$gitcheckout feature $gitrebase master# 初始状态A---B---C(master)\D---E(feature)# 执行 git rebase master 后A---B---C(master)\D'---E'(feature)交互式变基（修改提交）
$gitrebase -i HEAD~3# 修改最近3个提交进入交互式界面后，可以：
方法 说明 方法 说明 pick保留提交（默认） squash合并到前一个提交 reword修改提交信息 drop删除提交 edit修改提交内容 — — pick 1a2b3c Commit1reword 4d5e6f Commit2squash 7g8h9i Commit3变基过程中遇到冲突
$ git add <冲突文件> # 手动解决冲突后添加文件$ git rebase --continue # 继续变基$gitrebase --abort# 放弃变基部分提交移动到另一个分支 —— 把当前分支
topic（G和H）移动到目标分支maingitrebase --onto main feature topic# 初始状态A---B---C(main)\D---E---F(feature)\G---H(topic)# 把 topic 分支（G 和 H）移动到 main 分支的最新提交 C 上A---B---C(main)\\\G'---H'(topic)\D---E---F(feature)
变基
相关指令
git rebase—— 将当前分支的提交变基到指定分支，重新组织提交历史
场景一：基本变基
切换分支—— 从
master分支切换到feature分支$gitcheckout feature变基—— 将当前分支
feature变基到目标分支master$gitrebase master效果：
# 初始状态A---B---C(master)\D---E(feature)# 执行 git rebase master 后A---B---C(master)\D'---E'(feature)
场景二：变基时冲突
变基时报错
$gitrebase Auto-merging main.py CONFLICT(content): Merge conflictinmain.py error: could not apply2264188...addfunction_a hint: Resolve all conflicts manually, mark them as resolved with hint:"git add/rm <conflicted_files>",thenrun"git rebase --continue".hint: You can instead skip this commit: run"git rebase --skip".hint: To abort and get back to the state before"git rebase", run"git rebase --abort".Could not apply2264188...addfunction_a冲突文件：
main.py存在内容冲突冲突原因：在变基过程中，提交
2264188的修改与当前代码存在冲突查看冲突文件—— 输出未合并的路径
Unmerged paths$gitstatus Unmerged paths:(use"git add <file>..."to mark resolution)both modified: main.py手动解决冲突—— 打开
main.py，保留正确的代码，并添加到暂存区<<<<<<<HEAD 当前分支的代码（HEAD指向的版本）=======要应用的提交代码（2264188的修改）>>>>>>>2264188...addfunction_a$gitaddmain.py继续变基
$gitrebase --continue放弃变基—— 回到
rebase前的状态$gitrebase --abort跳过当前提交—— 该提交的修改将被丢弃
$gitrebase --skip
场景三：检测到存在未完成的变基
检测到存在未完成的变基操作
fatal: It seems that there is already a rebase-merge directory, and I wonderifyou areinthe middle of another rebase. If that is the case, please trygitrebase(--continue|--abort|--skip)If that is not the case, pleaserm-fr".git/rebase-merge"and run me again. I am stoppingincaseyou still have something valuable there.问题原因 ——
Git在.git/rebase-merge目录保存未完成的变基状态，可能由于：- 之前的
git rebase被意外中断（如关闭终端） - 冲突未完全解决就停止了操作
- 系统崩溃或强制退出
- 之前的
解决方案
- 继续未完成的变基：
git rebase --continue - 放弃当前变基：
git rebase --abort - 跳过当前提交：
git rebase --skip - 手动清理（仅当确认无价值内容时）：
rm -fr ".git/rebase-merge"
- 继续未完成的变基：
参考文献
更多内容可以参考以下文章：
git rebase 用法详解与工作原理 | Shall We Code?
git rebase详解（图解+最简单示例，一次就懂）-CSDN博客
图解 Git 基本命令 merge 和 rebase - Michael翔 - 博客园
图解4种git合并分支方法