22个版本

0.9.0	2024年5月27日
0.8.0	2023年8月28日
0.7.0	2023年3月2日
0.6.0	2022年11月14日
0.2.0	2021年3月15日

#343 in 开发工具

184每月下载次数

MIT/Apache

1.5MB
35K SLoC

git-branchless logo

Git的无分支工作流程

(此工具集100%与分支兼容。如果您认为这很令人困惑，您可以在此处讨论新的名称.)

▼ 跳转到安装 ▼
▼ 跳转到目录 ▼

关于

git-branchless 是一系列工具，可以在多个方面增强Git功能

它 使Git更易于使用，无论是对于新手还是高级用户。例如

git undo：一个通用的撤销命令。请参阅博客文章 git undo: 我们可以做得更好。
智能日志：一个方便的可视化工具。
git restack：修复损坏的提交图。
假设合并：避免遇到合并冲突。

它 为高级用户提供了更多灵活性。例如

补丁栈工作流程：对Linux和Git项目以及许多大型科技公司使用的“补丁栈”工作流程提供了强大的支持。（这就是Git“应该”被使用的方式。）
原型设计和实验工作流程：通过“分叉”开发对原型设计和实验工作提供了强大的支持。
git sync：在不先检出的情况下，重新合并所有本地提交堆栈和分支。
git move：在清理旧分支的同时，可以移动子树而不是“枝条”，不触及工作副本等。
匿名分支：减少了实验性工作的分支开销。
内存操作：在不检出相关提交的情况下修改提交图。
git next/prev：快速在提交堆栈中的提交和分支之间跳转。
git sw -i/--interactive：交互式选择要切换到的提交。

它为大型仓库和单仓库提供了更快的操作，尤其是在大型科技公司中。例如

查看博客文章使用 git-move 的闪电般快速重新合并。
性能测试：在 torvalds/linux（1M+ 提交）和 mozilla/gecko-dev（700k+ 提交）上进行了基准测试。
内存操作：默认情况下避免触及工作副本（这可能减慢 git status 或使构建工件失效）。
稀疏索引：使用稀疏索引的自定义实现以快速执行提交和合并操作。
分段变更日志DAG：对于对提交图的高效查询，例如在 O(log n) 时间内计算合并基础，而不是 O(n)。
预先编译：使用具有良好运行时性能的预先编译语言（Rust）编写。
多线程：在适当的地方将工作分配到多个CPU核心。
据我所知，git-branchless 提供了 Git 工具和 UI 中最快的重新合并实现，原因如上所述。

请参阅用户指南和设计目标。

演示

修复

几乎可以撤销任何事情

提交。
修改过的提交。
合并和重新合并（例如，如果您错误地解决了冲突）。
检出。
创建、更新和删除分支。

为什么不是 git reflog？

git reflog 是一个查看单个引用（如 HEAD）之前位置的工具，可以用来撤销操作。但因为它只跟踪单个引用的位置，复杂的操作如变基（rebase）在逆向工程时可能会很繁琐。 git undo 在更高层次上操作：整个仓库的状态。

git reflog 本质上也不能用来撤销某些罕见操作，例如某些分支的创建、更新和删除。更多信息请参阅架构文档。

git undo 无法处理哪些内容？

git undo 需要依赖 Git 近期版本的特性才能正常工作。请参阅兼容性图表。

目前，git undo 无法撤销以下操作。您可以在问题 #10中找到处理这些情况的设计文档。

通过撤销提交并恢复其更改到工作副本来“取消提交”一个提交。
- 在标准 Git 中，可以使用 git reset HEAD^ 来实现此操作。
- 此场景最好使用自定义的 git uncommit 命令来实现。请参阅问题 #3。
撤销文件的暂存或取消暂存。这由上述问题 #10 跟踪。
撤销到冲突的中间位置，使 git status 显示类似 path/to/file (both modified) 的消息，以便您可以不同地解决该特定冲突。这由上述问题 #10 跟踪。

从根本上说，git undo 并不打算处理未跟踪文件的更改。

与其他 Git 撤销工具的比较

gitjk：需要 shell 别名。只能撤销最近的命令。只能处理一些 Git 操作（例如，不处理变基）。
git-extras/git-undo：只能撤销当前 HEAD 上的提交。
git-annex undo：只能撤销给定文件或目录的最近更改。
thefuck：只能撤销历史 shell 命令。只能处理一些 Git 操作（例如，不处理变基）。

可视化

使用 smartlog（git sl）可视化您的提交历史

为什么不使用 git log --graph 呢？

git log --graph 只会显示带有分支的提交。如果你更喜欢在没有分支的情况下工作，那么 git log --graph 就不会适用于你。

为了支持那些大量重写提交图的用户，git sl 也会指出那些被废弃并需要修复的提交（标记为 rewritten as abcd1234 的提交的后代）。这些可以通过 git restack 自动修复，或者手动处理。

操作

无需担忧编辑您的提交图

为什么不使用 git rebase --interactive 呢？

使用 git rebase --interactive 进行交互式变基是完全支持的，但它有几个缺点

git rebase --interactive 只能修复线性提交系列，不能修复树。如果你修改了一个具有多个子提交的提交，那么你必须确保适当地变基所有其他子提交。
在开始变基之前，你必须制定一个行动计划。对于某些用例，一次处理单个提交可能比一次处理整个提交系列更容易。

当你使用 git rebase --interactive 与 git-branchless 一起时，如果你废弃任何提交，将会提示你修复你的提交图。

安装

请参阅 https://github.com/arxanas/git-branchless/wiki/Installation。

简而言之：检查适合您系统的仓库中的软件包，或者运行 cargo install --locked git-branchless。一旦安装，请在您的仓库中运行 git branchless init。

状态

git-branchless 目前处于 alpha 阶段。请做好应对破坏性变化的准备，因为一些工作流程和架构可能在将来发生变化。相信它没有重大错误，但它尚未经过全面实战测试。你可以在问题跟踪器中看到已知问题。

git-branchless 遵循语义版本控制。新的 0.x.y 版本，以及达到 1.0.0 后的新主要版本，可能会以不向后兼容的方式更改磁盘格式。

要通知您新版本，请选择页面顶部的通知菜单中的“Watch”>“自定义”>“Releases”。或者使用 GitPunch 通过电子邮件发送通知。

这个领域正在开发许多有潜力的工具。请参阅相关工具以获取更多信息。

贡献

感谢您对贡献的兴趣！如果您愿意，我很乐意安排一次电话会议来帮助您加入。

对于代码贡献，请查看运行手册以了解如何设置开发工作流程，以及编码规范。您还可以阅读架构文档。

对于文档贡献，请参阅Wiki风格指南。

贡献者应遵守行为准则。

依赖关系

~77MB
~1.5M SLoC