Automated and minimal merge-queue ideal for a solo developer (later versions may support teams)

Find a file

Paul Campbell 7dab1da44b fix(server): reduce complexity of StartMonitoring handler Closes kemitix/git-next#25		2024-04-11 07:15:19 +01:00
.cargo	build: Add cargo config file	2024-04-06 18:51:37 +01:00
.git-hooks	chore: add cc-cli support for conventional commits	2024-04-06 17:50:25 +01:00
.woodpecker	build(woodpecker): restore dropped cargo build	2024-04-10 07:24:38 +01:00
src	fix(server): reduce complexity of StartMonitoring handler	2024-04-11 07:15:19 +01:00
.git-next.toml	chore(git-next): add config file	2024-04-09 11:00:29 +01:00
.gitignore	chore(ignore): Don't track user files	2024-04-07 18:26:05 +01:00
.rgignore	build(woodpecker): TODO checker ignores git hook samples	2024-04-07 17:17:49 +01:00
bacon.toml	build(bacon): Add bacon.toml config	2024-04-07 16:06:10 +01:00
Cargo.toml	fix(server): Pause before checking CI status when just updated branch	2024-04-10 22:40:33 +01:00
default.toml	feat(init): define default repo config	2024-04-09 10:56:15 +01:00
Dockerfile	build(docker): don't include Cargo.lock in image	2024-04-07 17:28:54 +01:00
Dockerfile.builder	build(docker): add Dockerfile and builder	2024-04-07 16:20:04 +01:00
justfile	chore: add cc-cli support for conventional commits	2024-04-06 17:50:25 +01:00
LICENSE	docs(license): update copyright name	2024-04-08 20:32:10 +01:00
README.md	docs(readme): add build status badge	2024-04-07 19:44:06 +01:00
renovate.json	chore: Configure Renovate (#5 )	2024-04-07 12:42:17 +01:00
server-default.toml	config(server): add token field to Forge	2024-04-08 12:09:29 +01:00

README.md

git-next

Automated and minimal merge-queue ideal for a solo developer (later versions may support teams)

Currently this will mostly for myself when working on projects by myself. I'd like to reduce the overhead of PRs, but still maintain CI verification of each commit/patch set.

The main branch remains the ready-to-deploy version of the project.

I would then have a dev branch where I would do all of my work.

As a commit is added, as long as it matches a conventional commit message and isn't marked as WIP:, the next branch will advance from the current main commit to this next commit where it will be submitted to CI. This may or may not involve a PR. If it passes CI then the main branch will fast-forward to that commit (i.e. to next which should be a single step). The next commit on the dev branch will then be considered.

The application would initially integrate with only with ForegeJo via it's API to interact with the main, next and dev branches and to review the status check results for each commit or PR.

Before:
*1--*2--*3--*4--*5 main/next
                 \--*6--*7--*8--*9 dev
During CI:
*1--*2--*3--*4--*5 main
                 \--*6 next
                     \--*7--*8--*9 dev
After CI passes for *6:
*1--*2--*3--*4--*5--*6 main/next
                     \--*7--*8--*9 dev

The dev branch should never need to rebase onto main as main is only ever advancing along the dev branch as each commit passes CI.

Developing on git-next

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

Design

CLI to initialise the Repo (e.g. create config file)
Server that monitors a collection of repos via the Forge APIs

The CLI and the Server could be the same executable taking different commands to decide behaviour.

e.g.

(assuming the command is git-next)

Initialise a repo:

$ git next init

This would create a default configuration file: .git-next.toml.

Initialise a Server:

$ git next server init

This would create a configuration file git-next-server.toml for running the server. It would include details of the repos to be monitored and any credentials to be used.

Start a Server:

$ git next server start

This would start a server using the configuration file in the current directory.