-
Notifications
You must be signed in to change notification settings - Fork 474
Branches
Article "A successful Git branching model" was the base for choosing the current branch model, for "master" and "devel".
Also worth reading are ["GitHub Flow"] (http://scottchacon.com/2011/08/31/github-flow.html) and ["GitLab Flow"] (https://about.gitlab.com/2014/09/29/gitlab-flow/) - some of the shortcomings of "git flow" are discussed there.
The munin git repository is currently organised in 2 main repositories :
There are also some well known repositories:
- Debian This is a fork, dedicated to the debian packaging of munin.
- Fedora/EPEL This is a standalone repo, dedicated to the Fedora & EPEL packaging of munin.
- Gentoo This is a fork, dedicated to the gentoo packaging of munin.
This is the official one. It contains only official branches, and is the one you should fork from.
Note, once a commit is in this repo, it will not be removed. It might be reverted, but that will happen in an other commit. Rebases are strongly prohibited here.
So, when you need to refer to a specific commit be sure to, use the full SHA1, and take the one from this repository.
This is the branch where the main development takes place. It contains every commit that will go in the next release. When you want to patch something, make sure your pull request applies cleany to this one. The easiest way is to rebase against it just before you ask for a pull.
This is the branch containing releases. When a release is ready, it is merged to "master", and a release is tagged from here. Merging is always done with "git merge --no-ff" to keep the full merge history. Usually merges only come from the "devel" branch.
Helpful git options:
git config branch.master.mergeoptions "--no-ff"
Other branches, such a distro-specific or feature ones, will not be hosted here anymore. This enables to have a very clean official repository for people to fork from.
This is also an official repository, but it serves as a incubator for new features and deep bugfixes.
You should not fork from it : branches there are subject to deleting, rebasing and/or rewriting history. The branches are organized usually into one per feature/fix. The devel one is the integration one, and contains commits that will soon hit the main repo "devel" branch.
This repository gets usually referenced when publishing a custom built patch, usually after some chat with the munin team, and before inclusion in the main repo.