本页目录

rebase

可以对某一段线性提交历史进行编辑、删除、复制、粘贴操作，常用于合并commit和将某一段commit粘贴到另一个分支上

语法

                            
                            
                            git rebase -i  [startpoint]  [endpoint]

其中-i的意思是--interactive，即弹出交互式的界面让用户编辑完成合并操作，
[startpoint] [endpoint]则指定了一个编辑区间，如果不指定[endpoint]，则该区间的终点默认是当前分支HEAD所指向的commit(注：该区间指定的是一个前开后闭的区间)。

参考

git log 查看共有几次
git rebase -i HEAD~6 最近的6次
- pick：保留该commit（缩写:p）
- reword：保留该commit，但我需要修改该commit的注释（缩写:r）
- edit：保留该commit, 但我要停下来修改该提交(不仅仅修改注释)（缩写:e）
- squash：将该commit和前一个commit合并（缩写:s）
- fixup：将该commit和前一个commit合并，但我不要保留该提交的注释信息（缩写:f）
- exec：执行shell命令（缩写:x）
- drop：我要丢弃该commit（缩写:d）
如下图:

将上图 “pick” 按照命令修改，然后 wq 保存，进入下一步
注释修改界面:

编辑想保留的commit ,删除其他没用的 wq 退出即可

选项

--onto <newbase>: 创建新提交的起点。如果未指定 --onto 选项，则起点为 <upstream> 。可以是任何有效的提交，而不仅仅是现有的分支名称。; 作为一种特殊情况,如果A和B正好有一个合并基数,你可以用 "A…B "作为A和B的合并基数的快捷方式。您最多可以不使用A和B中的一个,在这种情况下,它默认为HEAD。
--keep-base: 将创建新提交的起点设置为 <upstream> 和 <branch> 的合并基础。运行 git rebase --keep-base <upstream> <branch> 相当于运行 git rebase --onto <upstream>...<branch> <upstream> <branch> 。; 当我们在上游分支的基础上开发一个特性时,这个选项是很有用的。当功能正在开发的时候,上游分支可能会前进,因此在上游分支的基础上继续重新归类可能不是最好的主意,而应该保持基础提交的原样。; 尽管此选项和 --fork-point <upstream> 和 <branch> 之间找到合并基础，但此选项使用合并基础作为创建新提交的 starting point ，而 --fork-point 使用合并base 来确定将被重新 set of commits 集。
<upstream>: 与之比较的上游分支,可以是任何有效的提交,而不仅仅是现有的分支名。可以是任何有效的提交,而不仅仅是现有的分支名。默认为当前分支的上游配置。
<branch>: 当前分支；默认为 HEAD 。
--continue: 在解决了合并冲突后,重新启动重定基过程。
--abort: 中止 rebase 操作并将 HEAD 重置为原始分支。如果在启动 rebase 操作时提供了 <branch> ，则 HEAD 将重置为 <branch> 。否则 HEAD 将被重置为 rebase 操作开始时的位置。
--quit: 中止 rebase 操作，但 HEAD 不会重置回原始分支。结果，索引和工作树也保持不变。如果使用 --autostash 创建了临时存储条目，它将被保存到存储列表中。
--apply: 使用应用策略进行基准调整（内部调用 git-am ）。一旦合并后端处理了应用程序所做的所有操作，此选项将来可能就不再适用。
-i /–interactive: 即弹出交互式的界面让用户编辑完成合并操作; 编制一个即将被重新归类的提交列表,让用户在重新归类前编辑该列表。让用户在重定基之前编辑该列表。这个模式也可以用来拆分提交的内容; 提交列表格式可以通过设置配置选项 rebase.instructionFormat 来改变。自定义的指令格式会自动在格式前加上长的提交哈希。
-r --rebase-merges[=(rebase-cousins|no-rebase-cousins)]: 默认情况下，rebase会简单地将合并提交从todo列表中删除，并将重新提交的提交放入单个线性分支中。使用 --rebase-merges ，rebase将通过重新创建合并提交来尝试在要重新提交的提交中保留分支结构。这些合并提交中的任何已解决的合并冲突或手动修订都必须手动解决/重新应用。; 默认情况下，或者当指定 no-rebase-cousins 时，没有 <upstream> 作为直接祖先的提交将保留其原始分支点，即git log的 --ancestry-path 排除的提交。 path选项将默认保留其原始血统。如果打开了 rebase-cousins 模式，则这些提交将改基于 <upstream> （或 <onto> ，如果指定）。; 目前只能使用 ort 合并策略重新创建合并提交；不同的合并策略只能通过显式 exec git merge -s <strategy> [...] 命令使用。