Git Worflow, branch creation.

Alexis Ménard menard at
Tue May 17 15:40:30 BST 2011


Not sure this was discussed before but I'd like to bring the topic for

Now that KDE moved to git it seems we still have old habits like
"Freezing period" on trunk (or should I say master branches of each
git repos). That sounds like weird to me when one of the main feature
of git is branch management. Unlike SVN it's easy for anyone to switch
from a branch to another one, making back-porting patches very easy,
checkouting being 10 times more easy.

I know it's a wider announcement so that people focus on bug fix
rather than feature (which is great). Now I don't understand why the
branching of let say 4.7 does not happen before on each repo (when the
freeze is decided) and we could make the policy on branches way more
clear and defined what could go on the branch and what can't go (just
using the procedure we have today). It has always been annoying the
fact that you couldn't hack features in the official trunk, people had
to use personal svn branches and now teams like plasma think about
setup integration repos. That sounds weird, you usually use these
extra branches for huge stuff you don't want to put in trunk right now
(like big refactoring, or research) not for every little features or
improvements projects want to push. To me the term "trunk" means it's
always open to features. I'm sure the Plasma need is not alone and we
will see these integration repos pop for not particular reason and
will mess up the history (with merge commit), make the checkout
complicated for people to use vanilla and make the KDE project
complicated to understand.

I looked around and all projects using git I've tried (and I'm not
saying I covered all :D) have a trunk always open to features. Ok it's
not as complicated/big as KDE but still.

Perhaps I miss a point here so if it's the case, could you please tell me?

I'm trying to see if our workflow could be improved.


More information about the kde-core-devel mailing list