HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
arxanas
git-branchless
Rust2021–2025
arxanas / git-branchless

git-branchless

High-velocity, monorepo-scale workflow for Git

26Distinct people
65Mentions
0Explicit recommenders
4.1KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

High-velocity, monorepo-scale workflow for Git

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

  • jj-vcs/jj · linked in 6 of the same discussions

Mentioned in the same Hacker News threads. That is not proof they are substitutes.

This week on Hacker News

Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 8:27:21 AM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year65 dated mentions

Observed mentions: 2021-03-29 17:08:51 UTC to 2025-12-20 07:55:29 UTC.

05101520252021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 23 mentions; 2 submissions, 21 comments20212022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 20 mentions; 2 submissions, 18 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 9 mentions; 1 submissions, 8 comments20232024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 6 mentions; 0 submissions, 6 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 7 mentions; 1 submissions, 6 comments2025

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC23221
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC20218
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC918
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC606
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC716

From the project README

An excerpt from the repository, fetched Nov 13, 2026.

Read the project’s introduction
Branchless workflow for Git (This suite of tools is 100% compatible with branches. For more discussion, see this thread.) ▼ Jump to installation ▼ ▼ Jump to table of contents ▼ About git-branchless is a suite of tools which enhances Git in several ways: It makes Git easier to use, both for novices and for power users. Examples: git undo: a general-purpose undo command. See the blog post git undo: We can do better. The smartlog: a convenient visualization tool. git restack: to repair broken commit graphs. Speculative merges: to avoid being caught off-guard by merge conflicts. It adds more flexibility for power users. Examples: Patch-stack workflows: strong support for "patch-stack" workflows as used by the Linux and Git projects, as well as at many large tech companies. (This is how Git was "meant" to be used.) Prototyping and experimenting workflows: strong support for prototyping and experimental work via "divergent" development. git sync: to rebase all local commit stacks and branches without having to check them out first. git move: The ability to move subtrees rather than "sticks" while cleaning up old branches, not touching the working copy, etc. Anonymous branching: reduces the overhead of branching for experimental work. In-memory operations: to modify the commit graph without having to check out the commits in question. git next/prev: to quickly jump between commits and branches in a commit stack. git sw -i/--interactive: to interactively select a commit to switch to. It provides faster operations for large repositories and monorepos, particularly at large tech companies. Examples: See the blog post Lightning-fast rebases with git-move. Performance tested: benchmarked on torvalds/linux (1M+ commits) and mozilla/gecko-dev (700k+ commits). Operates in-memory: avoids touching the working copy by default (which can slow down git status or invalidate build artifacts). Sparse indexes: uses a custom implementation of sparse indexes for fast commit and merge operations. Segmented changelog DAG: for efficient queries on the commit graph, such as merge-base calculation in O(log n) instead of O(n). Ahead-of-time compiled: written in an ahead-of-time compiled language with good runtime performance (Rust). Multithreading: distributes work across multiple CPU cores where appropriate. To my knowledge, git-branchless provides the fastest implementation of rebase among Git tools and UIs, for the above reasons. See also the User guide and Design goals. Table of contents About Demos Repair Visualize Manipulate Installation Status Related tools Contributing Demos Repair Undo almost anything: Commits. Amended commits. Merges and rebases (e.g. if you resolved a conflict wrongly). Checkouts. Branch creations, updates, and deletions. Why not git reflog? git reflog is a tool to view the previous position of a single reference (like HEAD), which can be used to undo operations. But since it only tracks the position of a single reference, complicated operations like rebases can be tedious to reverse-engineer. git undo operates at a higher level of abstraction: the entire state of your repository. git reflog also fundamentally can't be used to undo some rare operations, such as certain branch creations, updates, and deletions. See the architecture document for more details. What doesn't git undo handle? git undo relies on features in recent versions of Git to work properly. See the compatibility chart. Currently, git undo can't undo the following. You can find the design document to handle some of these cases in issue #10. "Uncommitting" a commit by undoing the commit and restoring its changes to the working copy. In stock Git, this can be accomplished with git reset HEAD^. This scenario would be better implemented with a custom git uncommit command instead. See issue #3. Undoing the staging or unstaging of files. This is tracked by issue #10 above. Undoing back into the middle of a conflict, such that git status shows a message like path/to/file (both modified), so that you can resolve that specific conflict differently. This is tracked by issue #10 above. Fundamentally, git undo is not intended to handle changes to untracked files. Comparison to other Git undo tools gitjk: Requires a shell alias. Only undoes most recent command. Only handles some Git operations (e.g. doesn't handle rebases). git-extras/git-undo: Only undoes commits at current HEAD. git-annex undo: Only undoes the most recent change to a given file or directory. thefuck: Only undoes historical shell commands. Only handles some Git operations (e.g. doesn't handle rebases). Visualize Visualize your commit history with the smartlog (git sl): Why not git log --graph? git log --graph only shows commits which have branches attached with them. If you prefer to work without branches, then git log --graph won't work for you. To support users who rewrite their commit graph extensively, git sl also points out commits which have been abandoned and need to be repaired (descendants of commits marked with rewritten as abcd1234). They can be automatically fixed up with git restack, or manually handled. Manipulate Edit your commit graph without fear: Why not git rebase --interactive? Interactive rebasing with git rebase --interactive is fully supported, but it has a couple of shortcomings: git rebase --interactive can only repair linear series of commits, not trees. If you modify a commit with multiple children, then you have to be sure to rebase all of the other children commits appropriately. You have to commit to a plan of action before starting the rebase. For some use-cases, it can be easier to operate on individual commits at a time, rather than an entire series of commits all at once. When you use git rebase --interactive with git-branchless, you will be prompted to repair your commit graph if you abandon any commits. Inst
Read the full README on GitHub

What Hacker News says

9 sources
Yes, but due to its simplicity + extensibility + widespread adoption, I wouldn’t be surprised if we’re still using Git 100+ years from now. The current trend (most popular and IMO likely to succeed) is to make tools (“layers”) which work on top of Git, like more intuitive UI/patterns (https://github.com/jesseduffield/lazygit, https://github.com/arxanas/git-branchless) and smart merge resolvers (https://github.com/Symbolk/IntelliMerge, https://docs.plasticscm.com/semanticmerge/how-to-configure/s...). Git it so flexible, even things that it handles terribly by default, it handles fine with layers: e.g., large binary files via git-lfs (https://git-lfs.com) and merge conflicts in non-textual files by custom merge resolvers like Unity’s (https://flashg.github.io/GitMerge-for-Unity/). Perhaps in the future, almost everyone will keep using Git a
Read the rest
t the core, but have so many layers to make it more intuitive and provide better merges, that what they’re using barely resembles Git at all. This flexibility and the fact that nearly everything is designed for Git and integrates with Git, are why I doubt it’s ever going away. Some alternatives for thought: - pijul (https://pijul.org), a completely different VCS which allegedly has better merges/rebases. In beta, but I rarely hear about it nowadays and have heard more bad than good. I don’t think we can implement this alternate rebases in Git, but maybe we don’t need to; even after reading the website, I don’t understand why pijul’s merges are better, and in particular I can’t think of a concrete example nor does pijul provide one. - Unison (https://www.unison-lang.org). This isn’t a VCS, but a language with a radical approach to code representation: instead of code being text stored in files, code is ASTs referenced by hash and stored in essentially a database. Among other advantages, the main one is that you can rename symbols and they will automatically propagate to dependencies, because the symbols are referenced by their hash instead of their name. I believe this automatic renaming will be common in the future, whether it’s implemented by a layer on top of Git or alternate code representation like Unison (to be clear, Unison’s codebases are designed to work with Git, and the Unison project itself is stored in Git repos). - SVN, the other widespread VCS. Google or ask ChatGPT “Git vs SVN” and you’ll get answers like this (https://www.linode.com/docs/guides/svn-vs-git/, https://stackoverflow.com/a/875). Basically, SVN is easier to understand and handles large files better, Git is decentralized and more popular. But what about the differences which can’t be resolved by layers, like lazygit for intuition and git-lfs for large files? It seems to me like even companies with centralized private repositories use Git, meaning Git will probably win in the long term, but I don’t work at those companies so I don’t really know. - Mercurial and Fossil, the other widespread VCSs. It seems these are more similar to Git and the main differences are in the low-level implementation (https://stackoverflow.com/a/892688, https://fossil-scm.org/home/doc/trunk/www/fossil-v-git.wiki#....). It actually seems like most people prefer Mercurial and Fossil over Git and would use them if they had the same popularity, or at least if they had Git’s popularity and Git had Mercury or Fossil’s. But again, these VCSs are so similar that with layers, you can probably create a Git experience which has their advantages and almost copies their UI.
In Ask HN: Can we do better than Git for version control?
Some of the recent tool started to come out to fix Git unfriendly UX. Meta's Sapling (1) is definitely one of them. But there is also `jj` (2) and `git-branchless` (3). These tools target a smaller set of workflow where there is 1 main branch inside a big repo and everything else are short-lived branch/topic that could be treated as ephemeral stack of patches, constantly being uproot / rebase on top of the main branch to derive final result. If that's the workflow you use daily, then you should give these tools a try. (1): https://github.com/facebook/sapling (2): https://github.com/martinvonz/jj/ (3): https://github.com/arxanas/git-branchless
In Meta developer tools: Working at scale
> Is this for a case where a bunch of people branch from master@HEAD (lets call this A), then you need to modify A, so you then need to rebase each branch that branched from A individually? Mainly it's for when you branch from A multiple times, and then modify A. This can happen if you have some base work that you build multiple features on top of. I routinely do this as part of rapid prototyping, as described here: https://github.com/arxanas/git-branchless/wiki/Workflow:-div... `git undo` shows a list of operations it'll execute, which you have to confirm before accepting. Of course, it's ultimately a matter of trust in the tools you use.
In Branchless Workflow for Git
> The author's "features from the future" feel to me like they just haven't gotten a good feel for the model. The author is apparently behind[1] a sucessful alternative UI to Git. It seems safe to assume that they are way beyond merely getting a feel for the Git model. The Bad-UX denialism has really gone too far when authors like that are dismissed over the old You Just Have To Understand The Model talking point. [1] https://github.com/arxanas/git-branchless/
In Where are my Git UI features from the future?
On the contrary: I myself have implemented these better operations, and they work great. They also exist in some other VCSes, such as Mercurial and Jujutsu. You can see the `git-branchless` column in the table for comparison with the other clients. - git reword: https://github.com/arxanas/git-branchless/wiki/Command:-git-... - git move will perform the magic "see all downstream conflicts", but unfortunately will only show you the number of conflicting files, at present: https://github.com/arxanas/git-branchless/wiki/Command:-git-... - You cannot undo arbitrary operations with the reflog (nor with `git reset`). See https://github.com/arxanas/git-branchless/wiki/Architecture#.... Besides those points, my `git undo` can even undo some working copy changes: https://github.com/arxanas/git-branchless/wiki/Command:-git-...
In Where are my Git UI features from the future?

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.