【git系列】git rebase含义用法选项示例详解

【git系列】git rebase含义用法选项示例详解

源自专栏《Gradle ScalaTest markdown idea Git中文实用教程目录?》

概要

在另一个基准点上重新应用提交

语法

git rebase [-i | --interactive] [<选项>] [--exec <cmd>]
	[--onto <newbase> | --keep-base] [<upstream> [<branch>]]
	
git rebase [-i | --interactive] [<选项>] [--exec <cmd>] [--onto <newbase>]
	--root [<branch>]
	
git rebase (--continue | --skip | --abort | --quit | --edit-todo | --show-current-patch)

描述

如果指定了 <branch>，git rebase 将在执行任何其他操作之前执行自动的 git switch <branch>。否则，它保持在当前分支上。

如果未指定 <upstream>，将使用在 branch.<name>.remote 和 branch.<name>.merge 选项中配置的上游（详细信息请参见 git-config[1]），并假定 --fork-point 选项。如果您当前不在任何分支上，或者当前分支没有配置上游，重新应用将中止。

当前分支中的所有提交所做的但不在 <upstream> 中的更改将保存到临时区域。这与 git log <upstream>..HEAD 显示的提交集相同；或者如果 --fork-point 处于活动状态（请参阅下面关于 --fork-point 的描述），则与 git log 'fork_point'..HEAD 相同；或者如果指定了 --root 选项，则与 git log HEAD 相同。

如果提供了 --onto 选项，则当前分支将重置为 <upstream> 或 <newbase>。这与 git reset --hard <upstream>（或 <newbase>）的效果完全相同。ORIG_HEAD 被设置为指向重置之前的分支尖端。

注意：

• 如果在重新应用过程中使用其他写入伪引用（例如 git reset）的命令，ORIG_HEAD 不能保证在重新应用结束时仍指向之前的分支尖端。但可以使用当前分支的 reflog（即 @{1}，请参见 gitrevisions[7]）访问之前的分支尖端。
• 先前保存在临时区域的提交将按顺序逐个重新应用到当前分支上。请注意，如果 HEAD 中的任何提交引入与 HEAD… 中的提交相同的文本更改，则将被省略（即，已在上游以不同的提交消息或时间戳接受的补丁将被跳过）。
• 可能会发生合并失败，导致这个过程无法完全自动化。您将不得不解决任何此类合并失败，并运行 git rebase --continue。另一个选项是使用 git rebase --skip 绕过导致合并失败的提交。要检出原始 <branch> 并删除 .git/rebase-apply 工作文件，请使用命令 git rebase --abort。

示例

假设存在以下历史记录，并且当前分支是 “topic”：

      A---B---C topic
     /
D---E---F---G master

在这种情况下，运行以下任一命令：

git rebase master
git rebase master topic

将得到：

              A'--B'--C' topic
             /
D---E---F---G master

注意：
后一种形式只是 git checkout topic 后跟 git rebase master 的简写。重新应用完成后，topic 将保持选中的分支。

如果上游分支已经包含您做过的更改（例如，因为您提交了一个应用于上游的补丁），则该提交将被跳过，并会发出警告（如果使用了合并后端）。例如，在以下历史上运行 git rebase master（其中 A’ 和 A 引入相同的