Trunk-based development manager for a solo developer. https://git.kemitix.net/kemitix/git-next
Find a file
renovate 4a4da2f8c0 chore: Configure Renovate (#5)
Welcome to [Renovate](https://github.com/renovatebot/renovate)! This is an onboarding PR to help you understand and configure settings before regular Pull Requests begin.

🚦 To activate Renovate, merge this Pull Request. To disable Renovate, simply close this Pull Request unmerged.

---
### Detected Package Files

 * `Cargo.toml` (cargo)

### Configuration Summary

Based on the default config's presets, Renovate will:

  - Start dependency updates only once this onboarding PR is merged
  - Enable Renovate Dependency Dashboard creation.
  - Use semantic commit type `fix` for dependencies and `chore` for all others if semantic commits are in use.
  - Ignore `node_modules`, `bower_components`, `vendor` and various test/tests directories.
  - Group known monorepo packages together.
  - Use curated list of recommended non-monorepo package groupings.
  - Apply crowd-sourced package replacement rules.
  - Apply crowd-sourced workarounds for known problems with packages.

🔡 Do you want to change how Renovate upgrades your dependencies? Add your custom config to `renovate.json` in this branch. Renovate will update the Pull Request description the next time it runs.

---

### What to Expect

It looks like your repository dependencies are already up-to-date and no Pull Requests will be necessary right away.

---

 Got questions? Check out Renovate's [Docs](https://docs.renovatebot.com/), particularly the Getting Started section.
If you need any further assistance then you can also [request help here](https://github.com/renovatebot/renovate/discussions).

---

This PR has been generated by [Renovate Bot](https://github.com/renovatebot/renovate).

<!--renovate-config-hash:e80b4e42a3043bc12fa0640db4bac392d2bf770acf841360d7c8ceeeac2ec1a9-->

Co-authored-by: Renovate Bot <renovate@kemitix.net>
Reviewed-on: #5
Co-authored-by: renovate <renovate@noreply.kemitix.net>
Co-committed-by: renovate <renovate@noreply.kemitix.net>
2024-04-07 12:42:17 +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
src feat: Add Filesystem to wrap fs operations 2024-04-07 12:06:33 +01:00
.gitignore chore: add cc-cli support for conventional commits 2024-04-06 17:50:25 +01:00
Cargo.toml chore: Remove cc-cli from dev dependencies 2024-04-07 12:07:17 +01:00
default.toml feat(init): creates a default configuration file 2024-04-06 18:39:20 +01:00
justfile chore: add cc-cli support for conventional commits 2024-04-06 17:50:25 +01:00
LICENSE Initial commit 2024-04-06 17:31:05 +01:00
README.md docs(readme): Add note on installing git-hooks 2024-04-06 17:58:18 +01:00
renovate.json chore: Configure Renovate (#5) 2024-04-07 12:42:17 +01:00
server-default.toml feat(server): creates a default server configuration file 2024-04-06 18:42:34 +01:00

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.