The git-branchless project is not the future of version control. Instead, the goal is to 1) provide a natural half-step to Jujutsu, which accomplishes most git-branchless workflows in a more principled way; and to 2) serve as a test-bed for new workflows that Jujutsu might want to adopt in the future.

The design goals of the git-branchless project are as follows:

• Support onboarding: Make it easy for new users to adopt git-branchless.
  • Prefer to allow users to adopt tools incrementally, without having to opt into a complete workflow change. Example: git undo can be used while ignoring the rest of the suite.
  • Documentation is a first-class goal, but tools should naturally prompt users to do the right thing. Example: when you abandon a commit, a warning appears to suggest that you run git restack.
• Decrease complexity: Git is overly complex. Prefer to reduce complexity rather than manage complexity.
  • Remove concepts from Git which don't work well. Example: the staging area is incidental complexity. It would be better to support partial commits via different means.
  • Unify concepts where possible. Example: Git stashes can be represented as regular Git commits, if the tooling provides enough support.
• Increase velocity: Users should be able to carry out common workflow operations quickly and enjoy fast feedback loops.
  • Commits and branches should be easier to make and throw away (hence the name "git-branchless").
  • It should be possible to experiment without losing work. Example: git undo makes commit graph operations safer to use, because they can be easily rolled back.
• Perform well: git-branchless must scale to monorepo-sized repositories, without suffering performance degradation.
  • Commands should complete in milliseconds. Operations which take longer than that (such as querying git status) need to be considered carefully before including them as part of a core workflow.