-
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. Another useful source for starting ZOOLU Development may be the "Fork A Repo"-Article in the Github-Help.
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, or the result of your development is not satisfying, the original feature branch can be deleted on your local machine and in your github repository.
git branch -d feature/[name]
git push origin :feature/[name]
Information: These branches are only accepted by the core team!
origin: develop
target: develop and master
naming: release/[version]
Release-branches are responsible for our release progress. Once the develop branch has reached a stable state, and contains all the features we wish to have in our next release, a new release branch is created from the develop branch. With this task the the new version number is assigned to this release, as it has to appear in the branch name.
Here is done the last work before a release, mainly consisting of small bugfixes. It's not allowed to add any new features to the release branch. Feature branches are still merged into the develop branch, which means the release branch has also the function of a feature freeze. The benefit of this approach is that other developers can contribute new features, although a release-progress is just in work.
Before merging the release branch into the master branch the changelog has to be extended with the new features and bugfixes this release consists of. The correct way to do this is described on Writing Changelog.
Checkout a new branch from the stable develop-branch.
git checkout -b release/[version] develop
After finishing and commiting the release-specific work, you have to merge the changes to the master-branch.
git checkout master
git merge --no-ff release/[version]
This historical release should also be signed by a tag.
git tag -a v[version] -m "released version [version]"
Afterwards the changes must also be merged back to the develop-branch, so that this branch also involves the small bugfixes.
git checkout develop
git merge --no-ff release/[version]
After this you can delete the release-branch and push the changes and the tag to the upstream project on github.
git branch -d release/[version]
git push upstream master
git push upstream develop
git push upstream v[version]
origin: master
target: develop and master
naming: hotfix/[issue-id]
The hotfix branches are very similar to the release branches, except the fact that they are created to solve critical bugs. That means that it also finishes in a new release, although it is a small and unplanned one. For the naming we use the issue-id of the github issuetracker, so that we can reference to the corresponding issue report.
Create a new branch from the master branch.
git checkout -b hotfix/[issue-id] master
After fixing and commiting the bug you can send us a pull request. The work on the pull request should again be done by another person following Merging a Pull Request.
If the branch has been confirmed and merged into our repository you can safely delete the hotfix branch on your local machine and in your github repository.
git branch -d hotfix/[issue-id]
git push origin :hotfix/[issue-id]
origin: develop
target: develop
naming: bugfix/[issue-id]
The bugfix branch has the same objective as the hotfix branch, but the bug to fix is not critical enough to release a new version immediately. So the bugfix branch starts from the develop branch, and merges also back into the develop branch. That means that the bugfix is published with the next ZOOLU Release.
Create a new branch from the develop branch, named after the id from the issuetracker.
git checkout -b bugfix/[issue-id] develop
After fixing and commiting the bug you can send us a pull request. Another person should work on this pull request following Merging a Pull Request.
Finally, if your changes has been confirmed and merged, you can delete the bugfix branch on your local machine and in your github repository.
git branch -d bugfix/[issue-id]
git push origin :bugfix/[issue-id]