The main inspiration is A successful Git branching model by Vincent Driessen. The main difference is that we do not want (and cannot) manage different releases. Therefore we always have one current and supported version, stored in the master branch.
The main branches
t the core, the development model is greatly inspired by existing models out there. The central repo holds the master branch with an infinite lifetime. At each time master is deployable and must pass all tests.
We consider origin/master to be the main branch where the source code of HEAD always reflects a production-ready state. In fact, each time when changes are merged back into master, this is a new production release by definition. We tend to be very strict at this, so that theoretically, we could use a Git hook script to automatically build and roll-out our software to our production servers everytime there was a commit on master. We plan to integrate Travis CI into our workflow.
Feature branches
| Branch off from: master |
$ git checkout -b myfeature master Switched to a new branch "myfeature" |
| Must merge back into: master |
$ git checkout master Switched to branch 'master' $ git merge --no-ff myfeature Updating ea1b82a..05e9557 (Summary of changes) $ git branch -d myfeature Deleted branch myfeature (was 05e9557). $ git tag -a v1.2.3 |
| Branch naming convention: anything except master |
Next to the main branch master, our development model uses only a set of feature branches devoted to the development of distinct features. Unlike the main branch, these branches always have a limited life time.
The essence of a feature branch is that it exists as long as the feature is in development, but will eventually be merged back into master (to definitely add the new feature to the public release) or discarded (in case of a disappointing experiment). Feature branches typically exist in developer repos only, not in origin, except for those features that requires a collaboration between multiple developers.
Incorporating a finished feature
Finished features may be merged into the master branch definitely add them to the upcoming release.
The –no-ff flag causes the merge to always create a new commit object, even if the merge could be performed with a fast-forward. This avoids losing information about the historical existence of a feature branch and groups together all commits that together added the feature.
In the latter case, it is impossible to see from the Git history which of the commit objects together have implemented a feature—you would have to manually read all the log messages. Reverting a whole feature (i.e. a group of commits), is a true headache in the latter situation, whereas it is easily done if the –no-ff flag was used.
Yes, it will create a few more (empty) commit objects, but the gain is much bigger that that cost.
Also, we tag each deployable version according to Semantic Versioning.
Documentation
Update the documentation residing in the gh-pages branch. Remember to bump the version number.
$ git checkout gh-pages [edit] $ git commit -a
At the end we push the update versions to the shared repos (usually github under the AlgoLab organization)
$ git push origin; git push --tags
Issue tracker
All defects found must be added to the issue tracker. All possible improvements should be added to the issue tracker.
Bugfix commits can be applied directly to master.
Commit message
The first line of the message must be a capitalized, short (50 chars or less) summary. The first line must be separated from the remaining part by a blank line. The body of the message should be wrapped at 72 chars. The final paragraph should be a line with the list of bugs closed by the commit. I.e. Fix: 1234, 1235
Credits
Heavily inspired from http://nvie.com/posts/a-successful-git-branching-model/ and http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html
Licence
CC-SA