-
Notifications
You must be signed in to change notification settings - Fork 1
Branching model
Our Branching Model is inspired by this blog post of Vincent Driessen. On this page each branch respectively branch category is described.
These branches will never be deleted, which means they are existent all the time.
The master branch always contains a version suitable for production use. Everytime this branch changes a new release is published.
This branch contains the latest development stages. So it also contains the just finished but not yet released features, waiting for their appearance in the next release. Usually the product built from this branch is usable, but it may contain many undiscovered bugs. If the develop branch feels stable enough, a new release progress is started.
This section describes the branches which are only existent as long as they are needed. After they have reached an satisfying state, they will be merged into another branch and deleted afterwards. Merges are always called with the --no-ff flag, to prevent git from doing a fast forward, and make the merges visible in the history as a separate commit.
Each branch category will be described with the origin branch it starts from, the target branch it merges into, the naming convention they must follow, a short description and a few sample git commands.
origin: develop
target: develop
naming: feature/[name]
In this kind of branches new features are implemented. They are only existent for the time of development and only in the repository of the developer actually developing it.
Checkout a new branch from the current develop branch.
git checkout -b feature/[name] develop
After finishing the feature you can send us a pull request. The procedure for merging the pull request should be performed by another person, and the line of action is described here: Merging a Pull Request
If the pull request has been accepted and merged, the original feature branch can be deleted.
git branch -d feature/[name]