We’re spending a lot of time discussing our migration from TFS to Git at work. We need this transition to go smoothly. I need this transition to go smoothly. There are a lot of doubters. Yesterday, I was talking to one of our senior DBAs about this and he said “I don’t care, I’m just waiting for it to crumble.” After I told him that I was the one driving this transition, he just sorta wandered off without saying anything else.
This is such a dramatic departure for all of our .NET developers that are used to Visual Studio being a one-stop-shop and I’m worried about backlash when we start making them use another tool (SourceTree since we use Stash).
Anyways, I wanted to go over our current TFS branching strategy and our proposed branching strategy in Git. Or, at a minimum, try to start documenting it.
Main----o---\-----------------o--o Dev Branches \----o----o----o/ There's a dev branch per team.
The current issue is that Main is used to integrate all of the teams code. As you might imagine, Main breaks. We don’t have a “golden” copy. Additionally, “branching” in TFS is more like a forking operation in Git. A branch is a unique copy of a particular project from some changeset. The major difference is that when you branch in TFS, you’re ONLY getting that one branch whereas in Git, you get the entire repository.
This is what we’re proposing in Git.
Master----o------------------ Integration\----------------- | | Fork of "Main" repo per team. | Master - - - - - - - - - - - Teams will not use this branch. Integration\---------------- Feature Branch\----o---o---o-^ Pull Request to merge into team integration branch.
At the end of the sprint, the dev lead will merge their teams integration branch into the “Main” integration branch. All of the other dev teams will need to either rebase their branches when another team commits their code to the Main integration branch or deal with resolving countless merge conflicts.
So, why not branches for these development teams? Well, we discussed this, but the assumption was that we could help keep everyone’s experience as clean as possible so they aren’t sifting through hundreds of feature branches.
What about releases? Hot fixing?
Release-X.y /------- We plan to branch and tag this. Potentially branch off of this for HFs?? Master----o------------------o Integration\-----------------^ | | Fork of "Main" repo per team. | Master - - - - - - - - - - - Integration\-----------------o Feature Branch\----o---o---o-^
Enter fork syncing. Any branch made on the repository that is forked off of will get this branch. In the event of a HF, they will make their fix in their Release-X.y branch and then submit a pull request to have this code merged into the Main release-X.y branch.
Why the hell is release management not merging all this code and resolving conflicts? We’ll, to be frank, there are a couple reasons.
- We don’t know the code base.
- The assumption that any developer should be able to resolve a conflict simply isn’t true.
- The code base is massive and touches so many technologies that no one person can know how it all works (hence #1)
The only time release management will merge code is when we merge into the Master branch or Merge code into a release branch for HFing.
The big benefit to moving from TFS to Git is the ability to enforce code reviews by taking advantage of pull requests. Additionally, we have other development teams that work on mobile apps and Java apps that are already using Git (previously GitHub, now Stash) so it’s be nice to get everyone using the same technology.
Finally, this branching strategy is still in it’s infancy and we’re still toying with it to make sure that it breaks the KISS rule and to ensure that it’s sustainable for everyone. Also, forgive me if I’m using any terms incorrectly, there’s a lot of TFS lingo beat into my head.