1个不稳定版本

0.2.0 2021年5月4日

#6 in #rebase


2 个crate中使用

MIT 协议

4KB
62

Build Status

自动变基

自动变基自动将所有功能分支变基到master。如果发现冲突,它会变基到不引起冲突的最后一个提交。默认情况下,具有上游的分支将被排除。您不需要切换到任何分支,唯一的限制是已检出且不干净的分支将不会被变基(尽管我可能在将来添加这个功能)。

以下是一个演示。在自动变基之前,我们有一些旧的功能分支。

让我们autorebase

它尝试将所有分支变基。成功将demoreadme变基到master。然而,其他分支存在冲突,所以它们没有被完全变基到master。相反,它们被变基到引起冲突的提交之前。

如果由于冲突而无法完全变基,则标记该提交为冲突标记,并且不会再次尝试变基,直到其提交哈希更改(例如,编辑或手动变基)。

安装

GitHub发行页面下载二进制版本,或者您可以运行

cargo install autorebase

用法

只需在您的repo中运行autorebase。这将执行以下操作

  1. 更新master,通过使用--ff-only拉取它,除非您已检出并具有待处理更改。
  2. .git/autorebase内创建一个临时工作树(目前这个树永远不会被删除,但您可以使用git worktree remove autorebase_worktree手动删除)。
  3. 获取没有上游(除了--all-branches)且没有待处理更改的分支列表。
  4. 对于每个分支
    1. 尝试将其变基到master
    2. 如果因为冲突而失败,则中断并尽可能尝试变基。有两种策略可以实现这一点(见下文)。
    3. 如果我们没有将所有内容变基到master,则将分支标记为“卡住”,以避免在未来尝试。要“解卡”,请手动变基或向分支添加更多提交。

完整用法是

autorebase
    [--slow]
    [--all-branches]
    [--onto <target_branch>]

<目标分支> 默认为 master。如果您在 develop 上开发,可能希望使用 autorebase --onto develop

处理冲突有两种策略。默认为快速;使用 --slow 选择慢速方法。慢速方法简单地尝试在 master^master^^master^^^ 等等,直到找到一个可行的或者达到合并基础。

快速方法尝试将 master 重新应用到特性分支上。它计算成功提交的次数,并假设这些提交没有冲突,下一个提交可能是引起冲突的提交。然后它中止重新应用并重新应用特性分支到那个提交之前。

慢速方法可靠但慢。快速方法快但可能在某些情况下次优,例如如果冲突只是临时引入的。

限制

  • 它可能无法重新应用不是树形的分支,即包含合并提交的分支。我还没有真正测试这一点。
  • 它通过在命令行上运行 git 而不是通过类似 libgit2 的库来完成所有操作,这可能不是很稳健。
  • 无法手动指定要重新应用的分支。我可能会在某个时候添加类似于 autorebase track my_branch 的接口。也许吧。
  • autorebase 的工作树永远不会被删除,因此会永久占用一些磁盘空间。如果您喜欢,可以手动删除它。
  • 测试有限!

依赖

~0.2–9.5MB
~54K SLoC