On 3 March 2013 01:40, Mateusz Loskot <[email protected]> wrote: > > It's not a problem to rename the git-flow's branches > * 'master' is the current development line, corresponds to git-flow's > 'develop' > * 'release' is the current stable (deployable, production-ready) > branch, corresponds to git-flow's 'master'
After reading Pro Git book and Git manual, followed by kernel Git workflow I stand corrected about the principle behind the master branch: master tracks the commits that should go into the next release; In most scenarios based on releases, it is production-read deployable state of work. The actual development happens in topic branches. The 'develop' (or 'next') are integration branches. Things can potentially get broken in the integration branch, but mustn't in the 'master' branch. I aim to to follow this well-known, well-tested and common approach. > If we decide to rename the original git-flow branches, then it will > look this way: > * master - dark blue line, current development work > * release - light blue line, reserved for release tags only > * release/v.X.Y.Z - orange line, release integration branch This naming is not possible as once we add 'release' branch, Git won't allow to add the one with subtoken, 'release/X.Y.Z' I'm also researching solutions for restoring SOCI releases back to 1.0.1 in Git, so git clone will deliver *everything* since the beginning of time. This has been lost, and historic releases are only cached as downloads at SF.net. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb _______________________________________________ soci-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/soci-users
