camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Łukasz Dywicki <>
Subject Re: [DISCUSS] force switching from SVN to GIT
Date Fri, 20 Jul 2012 08:23:07 GMT
So far this thread was sleepy. I would like to back to it and discuss git "flow" we could use.

Currently we have release branches and trunk which is in general big feature branch. There
is no issue branches or separate feature branches for different things we would like support.
This lack of issue branches leads usage of svnmerge which allows to have substitute of feature
branches. For example when 2.8.x have some important bug fix it must be merged from 2.8.x
to 2.9.x branch and 2.10.x. In this process we must exclude things designed only for 2.8.x
to don't mess up other things.

In this particular case we don't have to track what was or was not merged to camel-2.9.x or
camel-2.10.x from trunk because all things we do have separate branches. Every feature should
have corresponding JIRA, just like issues. With git (flow) we can have:
master - master branch which contains production versions, it's place where tags are created
develop - (current trunk) main feature branch contains all stable features which was under
feature/CAMEL-5422 - new stuff to be implemented

If something should go to 2.9.x branch then we simply rebase (or merge) things to develop
and then to 2.9. If we would like start branch for 2.11 we simply pick develop and create
branch from it. The only thing not described in "A successful Git branching model" is working
with multiple release branches, but I believe we can handle that. Main change with git I expect
to see is much more branches and much less merges. ;) The less you merge, the better.

Kind regards,
Lukasz Dywicki

Wiadomość napisana przez aedwards w dniu 11 lip 2012, o godz. 16:11:

> +1 for git support, have recently switched on all our internal projects,
> really like Git.
> --
> View this message in context:
> Sent from the Camel Development mailing list archive at

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message