So we are slowly but surely moving our development from SVN to Git (about time). Our team is quite familiar with Git but the SVN repo is quite massive and with it comes a lot of other teams and releases which adds complexity to our Git methodologies. I have tried searching for similar scenarios but all SO posts are rather old and I want to make sure we are not implementing somethign "old" rather than the most up to date practises available.
At the moment (still on SVN), we are working on three releases at once. One is just about to be released, lets call it version 1.9, one is the update for that version (1.1) and we already have work going on for version 2.0. This works OK in SVN as each team have their own development branch which we merge to Trunk and from there we merge onwards to release_1.0. This ultimately means that ALL version 1.1 and version 2.0 development will get merged to Trunk for now. When version 1.0 is released we will branch version_1.0 -> version_1.1 and simply merge the specific commits wanted for 1.1 from Trunk -> version_1.1. Furthermore, eventually after the 1.1 release is out, we will create version_2.0 branch straight of Trunk and so it continues. This is no problem in SVN, though this won't fly in Git.
I am looking for what would be the best practise for implementing something similar but "Gitified" in Git. My current "best plan" is the following (ahead of the proposed development branches are obviously feature branches or "per team" branches" branched of the specific development branch. For simplicity I don't mention these here):
- Keep three separate development branches (from our SVN model these would be kind of three Trunks), one for each release. Each of these have their corresponding release branches (and potential testing, staging branches in between)
- When we create something for release 1.0 we merge it to development1.0 afterwhich it is "backmerged" -> development1.1 -> development2.0
- If we create something that is "1.1 only" or "2.0 only" we merge straight into that specific development branch.
This way we hopefully avoid cherry picking as much as possible. Though, I am not sure if this is the BEST way possible. An alternative we consider is to skip the 1.1 branch and simply cherry pick 1.1 content from 2.0 ONCE we eventually create the 1.1 branch AFTER 1.0 release. This would reduce the branching work but of course introduce cherry picking which I am not too familiar with myself but I realise could introduce more conflicts than the proposed method.
Can anyone with experience in using a model like this comment on what could be improved? Is this an OK solution or are there any obvious improvements? All comments are of course appreciated, even if you don't directly have experience of such a situation.
Thank you!
UPDATE: There has been some confusion as to why I say "This won't fly in git". I am more comfortable with Git myself, as compared to SVN, so it might well be a misinterpretation of the "SVN ways" on my part. Either way, the way we "merge" in SVN right now is (using Tortoise SVN) we open the "Show log" menu from where we see all commits in a particular branch. From there we pick (I guess this may be SVN cherry picking??) the commits that we want to merge upstream to, for example, Trunk. I suppose we are actually cherry picking currently? And not truely merging.
I'd be curious to hear more about why you think that your current methodology "... won't fly" in Git. What you've described there does not sound incompatible to me.
In case you haven't come across it yet, I recommend taking a look at Gitflow. This method for managing release in Git is pretty close / exactly what you have pitched. Reading that over might give you reassurance about how Git will work for you.
If your old subversion repo is just trunks and branches and merges, I think this will map very easily into Git.
Making the transition to Git will be more about adjusting individual developers' workflow to the new central paradigm of Git. For me, this is that it is a distributed VCS where commits are just a big graph and where your copy of the repo and my copy of the repo will have a lot of nodes and edges in common, but you or I may have some nodes that we haven't shared yet and at some point we have to reconcile and merge our graphs (typically this is done in the form of having a 'central' repo that we all think of as the canonical repo). Also, unlike svn, branches are (mostly) just a name for a node in the graph.