#git-rebase #branch #rebase #git #commit #onto #features

bin+lib autorebase

自动将功能分支合并到主分支

8 个版本

0.6.0 2023年11月24日
0.4.3 2021年6月20日
0.3.0 2021年5月4日
0.2.1 2021年5月4日

#2 in #onto

每月 21 次下载

MIT 许可证

42KB
745

Build Status

Autorebase

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

这里是一个演示。在 autorebase 之前,我们有多个旧的功能分支。

让我们 autorebase

这尝试合并了所有分支。 demoreadme 成功合并到 master。然而,其他分支有冲突,因此它们没有完全合并到 master。相反,它们合并到冲突发生之前的提交。

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

安装

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

cargo install autorebase

用法

只需在您的仓库中运行 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>]

<target_branch> 默认为 master。如果您在 develop 上进行开发,可能希望使用 autorebase --onto develop

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

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

慢速方法可靠但较慢。快速方法快速但可能在某些情况下不是最佳选择,例如,如果冲突只是暂时引入的。

局限性

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

依赖关系

~4–16MB
~161K SLoC