[lime-dev] About branching strategy

Gioacchino Mazzurco gio at eigenlab.org
Mon Feb 17 16:33:15 UTC 2014


As we talked with Guido we are taking an article [0] as inspiration as 
branching strategy, here i would comment something about it

[0] Says:
> Feature branches typically exist in developer repos only, not in origin.

I think this is not a good idea in our situation, we are a bunch of developer 
around the world and some time we don't know well on what the other are 
working, keeping those branch in origin and WELL UPDATED would help in 
understanding what is happening, to avoid work duplication and consequent hard 
to impossible to resolve merge conflict.


[0] Says:
> Finished features may be merged into the develop branch definitely add them
> to the upcoming release:
...
> $ git merge --no-ff myfeature
...
> $ git branch -d myfeature
> Deleted branch myfeature (was 05e9557).
> $ git push origin develop
>
> 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.

I think it is better do not delete the feature branch by default, and 
eventually delete just if necessary, so to keep better tracking of edit 
history and isolate easily eventual regressions, and i think the same about 
release and htofix branches, so generally i wouldn't delete branch if not 
necessary




[0] http://nvie.com/posts/a-successful-git-branching-model/



More information about the lime-dev mailing list