TFS to Git - repository set up

Question

For various reasons we are looking to move from TFS source control to Git. We're hoping to keep our current workflow but struggling to understand how this translates to Git. In TFS we typically have two branches:

• Main (day to day dev in here)
• Release (production, we deploy from here)

Typically, developers will check-in changes to Main and when we're ready to do a deployment to our live environment we merge certain check-ins from Main to Release. In Git world are we effectively cherry-picking here? (which I've heard is generally not a good thing to do). Is there a better way to maintain a set up like this in Git?

Basically we want developers to be able to check-in completed work to a branch which we can run daily builds off etc. but when it actually comes to going live, for various business reasons we need to sometimes exclude check-ins made into the Main branch and save them for later.

Please can someone explain how a set up like this might work in Git?

Answer 1

If I understand you correctly, your current process means that prior to a release, the Main branch will have check-ins for Feature A, Feature B and Bug Fix C. When planning a release, you will merge the check-in for Feature A and Bug Fix C into the Release branch, leaving the changes for Feature B in the Main branch for a future release. Is that correct?

If so, you're essentially using a modified version of the Feature Branch workflow for git. In your case, because of the way TFS works, your Main branch is acting as a holding area for features until they're ready for a release and then you pick and choose which ones you want in your release. With git and the feature branch flow, you have two common options for handling this:

A) Developers branch from the "master" (essentially your release branch) and develop all features in their own branch on their local machines. These branches stay in their local machines until it's time to do a release and then are merged into master as they are desired for a release.

B) If you're using a "master" git repository, your developers still branch from master but instead of keeping the changes local until release time, your developers could push their branches to that repository on feature completion and then they would be merged in when planning a release. The only downside to this particular approach is that your developers will need to do both local and remote branch management, nothing complicated but since branches in git are pointers, when you're "closing" (deleting) a branch pointer, your devs will need to do it on their local machines and someone will need to do it on the master repository as well.

In either case, no need for cherry picking.

And if you or your developers are new to git I strongly recommend the Git for Ages 4 an Up video on youtube. It's an excellent primer for how git works and how it models branches and change sets.

Edit:

As a minor aside, you'll see lots of references to the "master" branch in git (and likewise to origin when talking about remote repositories). These are just standard conventions. If you wanted your master branch to instead be named Release, you can do that in git with no problems, you'll just need to do the mental substitutions when reading examples and documentation.

Answer 2

Really, the only thing you need to change is the names:

• Main becomes dev or development
• Release becomes master

And to be honest, the only renaming requirement is Release -> master.

You could still keep the "Main" branch named the same in Git.