About branching strategy - lime-dev

17 Feb 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/