[lime-dev] About branching strategy: adopted nvie model

Gui Iribarren gui at altermundi.net
Wed Feb 19 14:11:55 UTC 2014


On 02/17/2014 10:11 PM, Nicolás Reynolds wrote:
> Gioacchino Mazzurco <gio at eigenlab.org> writes:
>
>> On Monday 17 February 2014 17:33:15 Gioacchino Mazzurco wrote:
>>> keeping those branch in origin and WELL UPDATED
>>
>> If I wasn't enough clear, I mean that each of us should push as soon as have
>> something committed (I usually push for each commit i do), to make easier to
>> follow what is happening to the others :)
>
> hi, we have been using gitflow[0] with good results, and it also allows
> publishing feature branches :)

Really nice Nicolas, thanks!

i've adopted it without effort, and it helped me keep things tidy

i've back-tagged the two de-facto "releases" we had last year, (IS4CWN 
demo and hackgaraiak incidental mesh) and started a simple 
release-tagging scheme
X.Y where X is major version bump, and Y is incremented with each hotfix 
branch merge.

we might change that in the future (i'd love to see a v1.0 ;) ) but i 
think it works for now.

With gio we have agreed on IRC to follow the nvie.com guidelines (either 
manually and/or using git-flow)
and after tidying up a little bit of the past mess, we're working on our 
own feature branches already succesfully
https://github.com/libre-mesh/lime-packages/branches

the convention adopted is exactly what's outlined at nvie.com (including 
branch naming)
so master is normally untouched, every commit/merge there means a 
release, and requires tested working code
and develop (or more likely, feature branches based off develop) is 
where daily commits happen.

git clone https://github.com/libre-mesh/lime-packages/
should give you the last "stable" release

and
git clone -b develop https://github.com/libre-mesh/lime-packages/
should give you a more recent, maybe broken version.

cheers!

guit



More information about the lime-dev mailing list