git.git workflow is a logical superset of gitflow with shorter branch names. All the basic practices are the same. Unsurprisingly, perhaps :-)
The key difference is the use of long lived stable branches rather than per-release stable branches that wither & die off. I would guess it’s a little easier to understand coming from current cloudstack practice. This setup does require a little bit more git-fu to recover from mistakes, and periodic rewind/rebase of integration branches (git has a ‘proposal’ branch if I remember correctly that is `git reset` every now and then). Like most git man-pages it assumes you understand git pretty well :-). Of course only one person needs to do that. I guess that may also be a good fit for cloudstack which is already used to the release manager announcing these kinds of coordinated shifts and doing branch maintenance. cheers, Leo On Aug 8, 2014, at 9:46 AM, Daan Hoogland <daan.hoogl...@gmail.com> wrote: > I had missed this one. It contains obligatory release management > knowledge for every keyboard toucher that is allowed to use git: > https://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html > > I think if we all read this and then study a bit we don't need to > discuss or branching model. It will become clear that we are in fact > doing almost fine and need only small changes.
