Gitflow http://nvie.com/posts/a-successful-git-branching-model/
Gitlab flow http://doc.gitlab.com/ee/workflow/gitlab_flow.html
http://blog.endpoint.com/2014/05/git-workflows-that-work.html
| { | |
| "name": "flare", | |
| "children": [ | |
| {"name": "2011UiAS-2HnD", "children": [{"name": "scbankstown", "value": 1}, {"name": "scbelmont", "value": 1}, {"name": "scchadstone", "value": 1}, {"name": "scchermside", "value": 1}, {"name": "sceatonfair", "value": 1}, {"name": "scepping", "value": 1}, {"name": "scerina", "value": 1}, {"name": "scfremantle", "value": 1}, {"name": "scharbourtown", "value": 1}, {"name": "sckotara", "value": 1}, {"name": "scmacarthursq", "value": 1}, {"name": "scmillpark", "value": 1}, {"name": "scnthlakes", "value": 1}, {"name": "scspringfield", "value": 1}, {"name": "scwatergardens", "value": 1}, {"name": "scwollongong", "value": 1}]}, | |
| {"name": "433", "children": [{"name": "scjoondalup", "value": 1}]}, | |
| {"name": "711UA-2HnD", "children": [{"name": "sccarlton", "value": 1}, {"name": "scfountain", "value": 1}, {"name": "schighpoint", "value": 1}, {"name": "scknox", "value": 1}, {"name": "scparramatta", "value": 1}, {"name": "scqv", "value": 1}, {"name": "scrundle", "value": 1}, {"name": |
| #!/bin/sh | |
| # Pull down all gists unless there are local changes not checked in. | |
| # For a discussion of using "git diff --exit-code", see http://stackoverflow.com/a/5139672/4263262 | |
| GISTDIR=$HOME/tmp/gists | |
| for gist in $GISTDIR/*.gist | |
| do | |
| ( | |
| cd $gist |
I come from RCS, where revision numbers are easy to insert into files with RCS keyword strings such as $Revision: $, $Id: $ and $Header: $.
There are various posts around of different ways of using revision numbers in Git, e.g. http://stackoverflow.com/questions/4120001/what-is-the-git-equivalent-for-revision-number
When using tags to record release revision numbers, we can use git describe to obtain reasonable-looking revision numbers, e.g. 1.2.1-2-g17880f1, where 1.2.1 is the most recent tag on the current branch, 2 is the number of commits made since the tag, and 17880f1 is the (short) SHA of the current commit (prefixed with g for "git"). These numbers have the benefit of monotonically increasing in the -<number-of-commits>- part, and presumably you would use some sort of meaningful release revision numbers in tags, so they should be fairly easy to understandy by non-technical people (ignoring the -g<SHA> at the end).