Automated and minimal merge-queue ideal for a solo developer (later versions may support teams)
Go to file
2024-06-07 20:03:14 +01:00
.cargo build(forgejo): use rust action 2024-05-17 07:26:07 +01:00
.forgejo/workflows build(forgejo): use rust action 2024-05-17 07:26:07 +01:00
.git-hooks chore: convert project into a cargo workspace 2024-05-11 16:33:18 +01:00
.woodpecker chore(deps): update docker tag to v0.3.2 2024-06-04 08:15:40 +00:00
crates refactor: tests: expand test given modules 2024-06-07 20:03:14 +01:00
.git-next.toml chore(git-next): add config file 2024-04-09 11:00:29 +01:00
.gitignore chore: ignore coverage metadata (profraw files) 2024-06-04 07:22:08 +01:00
.rgignore build(woodpecker): TODO checker ignores git hook samples 2024-04-07 17:17:49 +01:00
bacon.toml build(cargo): specify clippy flags in Cargo.toml 2024-05-02 18:52:10 +01:00
Cargo.toml chore: Release 0.7.1 2024-06-06 08:07:25 +01:00 chore: Release 0.7.1 2024-06-06 08:07:25 +01:00
cliff.toml fix(docs): git-cliff template add null check 2024-05-20 09:00:43 +01:00
default.toml feat(init): define default repo config 2024-04-09 10:56:15 +01:00
Dockerfile build(docker): install git 2024-05-13 21:03:33 +01:00
Dockerfile.builder build(docker): upgrade to clang-16 2024-05-19 07:05:41 +01:00
justfile test: add more tests to forge-github crate 2024-06-06 07:57:44 +01:00
LICENSE docs(license): update copyright name 2024-04-08 20:32:10 +01:00 docs(readme): fix typos and clarifications 2024-05-31 19:23:00 +01:00
renovate.json build: renovate should avoid pointless patch PRs 2024-04-25 16:01:24 +01:00
server-default.toml tests: add more tests to config crate 2024-06-01 11:44:36 +01:00


  • Status: Alpha - dog-fooding

git-next is a combined server and command-line tool that enables trunk-based development workflows where each commit must pass CI before being included in the main branch.


  • Enforce the requirement for each commit to pass the CI pipeline before being included in the main branch
  • Provide a server component that manages the trunk-based development process
  • Ensure a consistent, high-quality codebase by preventing untested changes from being merged



Additionally for this platform, to improved compilation times:

  • clang-16
  • mold

See .cargo/config.toml for how they are configured.


You can install git-next using Cargo:

cargo install --path .

Not yet available to install from

Branch Names

git-next uses three branches, main, next and dev, although they do not need to have those names. In the documentation we will use those names, but each repo must specify the names of the branches to use for each, even if they happen to have those same names.


  • The branches to use for main, next and dev must be specified in either the .git-next.toml in the repo itself, or in the server configuration file, git-next-server.toml. See below for details.
  • CI checks should be configured to run when the next branch is pushed.
  • The dev branch must have the main branch as an ancestor.
  • The next branch must have the main branch as an ancestor.


The server is configured by the git-next-server.toml file.


The server needs to be able to receive webhook notifications from your forge, (e.g. You can do this via any method that suits your environment, e.g. ngrok or a reverse proxy from a web server that itself can route traffic to the machine you are running the git-next server on.

Specify the address and port the server should listen to for incoming webhooks. This is the address and port that your reverse proxy should route traffic to.

  • addr - the IP address the server should bind to
  • port - the IP port the server should bind to


Your forges need to know where they should route webhooks to. This should be an address this is accessible to the forge. So, for, it would need to be a publicly accessible HTTPS URL. For a self-hosted forge, e.g. ForgeJo, on your own network, then it only needs to be accessible from the server your forge is running on.

  • url - the HTTPS URL for forges to send webhook to


git-next will create a bare clone of each repo that you configure it to monitor. They will all be created in the directory specified here. This data does not need to be backed up, as any missing information will be cloned when the server starts up.

  • path - directory to store local copies of monitored repos


Within the forge tree, specify each forge you want to monitor repos on.

Give your forge an alias, e.g. default, gh, github.


forge_type = "GitHub"
hostname = ""
user = "username"
token = "api-key"
  • forge_type - one of: ForgeJo or GitHub
  • hostname - the hostname for the forge.
  • user - the user to authenticate as
  • token - application token for the user. See below for the permissions required for on each forge.

Generally, the user will need to be able to push to main and to force-push to next.


For each forge, you need to specify which repos on the forge you want to monitor. They do not need to be owned by the user, but they user must have the push and force-push permissions as mentioned above for each of the repositories.


my-repo = { repo = "owner/repo", branch = "main", gitdir = "/home/pcampbell/project/my-repo" }

repo = "user/other"
branch = "master"
main = "master"
next = "ci-testing"
dev = "trunk"

Note that toml allows specifying the values on one line, or across multiple lines. Both are equivalent. What is not equivalent between my-repo and other-repo, is that one will require a configuration file within the repo itself. other-repo specifies the main, next and dev branches to be used, but my-repo doesn't.

A sample .git-next-toml file that would need to exist in my-repo's owner/repo repo, on the main branch:

main = "main"
next = "next"
dev = "dev"
  • repo - the owner and name of the repo to be monitored
  • branch - the branch to look for a .git-next.toml file if needed
  • gitdir - (optional) you can use a local copy of the repo
  • main - the branch to use as main
  • next - the branch to use as next
  • dev - the branch to use as dev

Additional notes on using gitdir:

When you specify the gitdir value, the repo cloned in that directory will be used for perform the equivalent of git fetch, git push and git push --force-with-lease.

These commands will not affect the contents of your working tree, nor will it change any local branches. Only the details about branches on the remote forge will be updated.

Currently git-next can only use a gitdir if the forge and repo is the same one specified as the origin remote. Otherwise the behaviour is untested and undefined.


Development happens on the dev branch, where each commit is expected to be able to pass the CI checks.

(Note: in the diagrams, mermaid isn't capable of showing main and next on the same commit, so we show next as empty)


    branch next

    branch dev

When the git-next server sees that the dev branch is ahead of the next branch, it will push the next branch fast-forward one commit along the dev branch.


    branch next

    branch dev

It will then wait for the CI checks to pass for the newly updated next branch. When the CI checks for the next branch pass, it will push the main branch fast-forward to the next branch. We return to the top and start again.


    branch next

    branch dev

If the CI checks should fail for the next branch, the developer should amend that commit in the history of their dev branch. They should then force-push their rebased dev branch.


    branch next

    checkout main

    branch dev


git-next will then detect that the next branch is no longer part of the dev branch ancestory, and will reset next back to main. We then return to the top, where git-next sees that dev is ahead of next.

When the dev branch is on the same commit as the main branch, then there are no pending commits and git-next will wait until it receives a webhook indicating that there has been a push to one of the branches. At which point it will start at the top again.


The dev branch should have the next branch as an ancestor.

However, when the commit on tip of the next branch has failed CI and is amended, this will not be the case. When this happens git-next will force-push the next branch back to the same commit as the main branch.

This is the only time a force-push will happen in git-next.

In short, the next branch belongs to git-next. Don't try to update it yourself. git-next will update the next it as it sees fit.

Getting Started

To use git-next for trunk-based development, follow these steps:

Initialise the repo (optional)

You need to specify which branches you are using. You can do this in the repo, or in the server configuration.

To create a default config file for the repo, run this command in the root of your repo:

git next init

This will create a .git-next.toml file. Default

By default the expected branches are main, next and dev. Each of these three branches must exist in your repo.

Initialise the server

The server uses the file git-next-server.toml for configuration. It expects to find this file the the current directory when executed.

The create the default config file, run this command:

git next server init

This will create a git-next-server.toml file. Default

Edit this file to your needs. See the Configuration section above.

Run the server

In the directory with your git-next-server.toml file, run the command:

git next server start


The following forges are supported:

  • ForgeJo (probably compatible with Gitea, but not tested)
  • GitHub

Note: ForgeJo is a hard fork of Gitea, but currently they are largely compatible. For now using a forge_type of ForgeJo with a Gitea instance will probably work okay. The only API calls we make are around registering and unregistering webhooks. So, as long as those APIs remain the same, they should be compatible.


Configure the forge in git-next-server.toml like:

forge_type = "ForgeJo"
hostname = ""
user = "bob"
token = "..."

hello = { repo = "user/hello", branch = "main", gitdir = "/opt/git/projects/user/hello.git" }             # maps to on the branch 'main'
world = { repo = "user/world", branch = "master", main = "master", next = "upcoming", "dev" = "develop" } # maps to the 'master' branch

The token is created on your ForgeJo instance at (for example) and requires the write:repository permission.


Configure the forge in git-next-server.toml like:

forge_type = "GitHub"
hostname = "" # required even for GitHub
user = "bob"
token = "..."

hello = { repo = "user/hello", branch = "main", gitdir = "/opt/git/projects/user/hello.git" }             # maps to on the branch 'main'
world = { repo = "user/world", branch = "master", main = "master", next = "upcoming", "dev" = "develop" } # maps to the 'master' branch

The token is created here and requires the repo and admin:repo_hook permissions.


Contributions to git-next are welcome! If you find a bug or have a feature request, please create an issue. If you'd like to contribute code, feel free to submit changes.

Before you start committing, run the just install-hooks command to setup the Git Hooks. (Get Just)

Crate Dependency

The following diagram shows the dependency between the crates that make up git-next:

    cli --> server
    cli --> git

    server --> config
    server --> git
    server --> forge
    server --> repo_actor

    git --> config

    forge --> config
    forge --> git
    forge --> forgejo
    forge --> github

    forgejo --> config
    forgejo --> git

    github --> config
    github --> git

    repo_actor --> config
    repo_actor --> git
    repo_actor --> forge


git-next is released under the MIT License.