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 development feature/CAMEL-5422 - new stuff to be implemented release/2.9.x release/2.10.x bugfix/CAMEL-5456 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 -- Code-House http://code-house.org 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: > http://camel.465427.n5.nabble.com/DISCUSS-force-switching-from-SVN-to-GIT-tp5715773p5715860.html > Sent from the Camel Development mailing list archive at Nabble.com.
