GitRoot

  1GitRoot is a tiny yet powerfull git forge. Download one binary, launch it and you have a forge which can:
  2
  3- create git repositories
  4- manages who can access to what repositories
  5
  6Nothing more, nothing less.
  7
  8Install plugins and you will be able to:
  9
 10- create issues, roadmap, sprint, milestone...
 11- represent them in boards
 12- review/merge branches (called grafts in gitroot)
 13- represent all of them and many more in a web interface
 14
 15> All of this plugins are completly independants. Yes, you can have boards without web. How? [See raw GitRoot issues board](https://gitroot.dev/gitroot/worktree/boards/issues.md.html), try it and you will love it.
 16
 17**Wants more? Build your own plugin!**
 18
 19# Why am I doing this?
 20
 21I'm doing GitRoot because no other will let me do what I want for my project. And at the same time, you may want to make something else for yours, something that doesn't resemble my idea of a perfect project.
 22
 23Every project is unique, so why don't we have the freedom to modify our forge to suit our project?
 24
 25So I try to follow these rules when developing my forge:
 26
 27## As a developper I want:
 28
 29- a repository containing all my data: code, issues, `(pull|merge)-request`, boards
 30- all I need to promote my project: landing page, translation, ticketing, forum
 31- to change my server forge: no script migration, no loose data, no loose attribution
 32
 33> As a developper I want to have a forge crafted for my unique project.
 34
 35## As a developper I don't want:
 36
 37- to open my browser to manage my data: `(pull|merge)-request`, issues
 38- the first representation of my project is a list of files and directories
 39- my forge choose my workflow issues: what is sprint vs milestone vs epic vs user-story?
 40- to have 100 menus to configure who can do what
 41
 42> As a developper I don't want a complexe forge to do my project.
 43
 44## As an administrator I want:
 45
 46- an easy to deploy forge: no dependency, no database
 47- to configure what my users can do
 48- my users can request what they want: no need to send email/chat to create or access to a project or a feature
 49
 50> As an administrator I want a forge that's easy to install and maintain.
 51
 52## As an administrator I don't want:
 53
 54- headhashes to upgrade my forge
 55- give my data (or user data) to someone else
 56- depends on big players who can table-flip their forge at any time
 57
 58> As an administrator I don't want to depend on anyone else.
 59
 60### _If you are like me, you will love GitRoot._
 61
 62It's not ready yet, but it will be, especially if you give me a hand.
 63
 64# How it works?
 65
 66In GitRoot all is stored in git, not in database, not in hidden blob in your git tree. All is stored in plain files aside your code.
 67
 68How to be sure no one write where they must not? **Restrict by branch.** Every GitRoot repository comes with a `.gitroot/users.yml` file. This file tell to GitRoot who can write where.
 69
 70At start, only you has access to your [default branch](./docs/technicals/default_branch.md). If someone else try to push to this branch, GitRoot will refuse its modifications.
 71
 72But everyone can create a branch, when creating one and push, GitRoot will add right for this user to this branch. Like that no one else will be able to touch it.
 73
 74If you add a user, by editing `.gitroot/users.yml` or by merging a branch where a user has added itself, this user will be able to push to the [default branch](./docs/technicals/default_branch.md).
 75
 76All GitRoot features are articulated around this concept. So every people can read files and modify them, locally or in a new branch. But only owner can change them in the [default branch](./docs/technicals/default_branch.md) which represent the current state of your repository.
 77
 78As your forge is managed by a root repository this concept permit to manage all your forge: a repository is created when you add (or merge) a change of `.gitroot/repositories.yml` in your [default branch](./docs/technicals/default_branch.md) of your root repository.
 79
 80See more details in the [documentation](./docs/).
 81
 82# When will be it available?
 83
 84Today GitRoot is in **alpha** version. Play with it, but **don't use it for production today**.
 85
 86GitRoot can:
 87
 88- Create/delete repositories
 89- Accept git command through ssh
 90- Manage users (who can wright where on repo/branch level)
 91- Install plugins
 92- Activate plugin for a repository
 93- Plugin run on worktree at install
 94- Plugin run on diff every commit after install
 95- Visualize repository with http
 96
 97What I want to do before version 1.0:
 98
 99- Update GitRoot and plugins
100- Manage users (who can wright where on file level)
101- Accept git command through http
102- Manage repositories in group and sub-group
103- Stabilize plugin API
104
105# Where is the project?
106
107You are on the project. Yes this is GitRoot!
108
109Well you are on the instance of GitRoot which host the code of GitRoot. Unfortunatly this instance is reserved for GitRoot itself.
110
111If you want to try GitRoot for your project please read [the documentation](./doc/index.md).
112
113# How to contribute?
114
115In [the documentation](./doc/index.md) you will find all you need to understand how to clone and push to any GitRoot repository. As GitRoot is itself a GitRoot repository you should be able to contribute to it.
116
117On this instance we use some plugins. Notably the `grafter` plugin which manage how a portion of code can be incorporated in the default branch. So be sure to read [the contributing](./CONTRIBUTING.md) to understand how it works.
118
119And yes, as GitRoot stock all data in git, you need to know git before making contribution (code, issue, translation...). In the future I hope to be able to do `git commit` and `git push` directly from the browser, like that anybody will be able to participe.