Git Branching Strategies That I've Used

I've used two different branching strategies for Git at previous jobs. Each had their own advantages and disadvantages.

Job #1 - Testable Master Branch, Single Development Branch, Tags for Releases

My memory is a little fuzzy on this workflow, but I think that a previous employer's workflow went something like this:

1. Use a central development branch for all development
2. Push ready-to-test increments to master
3. Tag each release

At this job, I worked with the company's QA team and developers on my team to create a Git workflow that would work for everyone. We used an iterative development process where QA would typically test after the development increment. This required a workflow that did the following:

• Have separate branches for in-development and ready-to-test changes
• Allow QA to quickly access ready-to-test code
• Have a history of releases
• Allow access to code via automated tooling

I'm not sure how it happened, but we had some long meetings on it and decided to have developers work off of the development branch. It worked quite well. QA was able to easily identify, access, and test ready-to-test features, and developers could work from development and merge into master for increments and hot fixes

This Git workflow was used for development of a white-label application. I built a custom website that would, among many other things, commit new variants of the white-label app to source control. It helped to have master contain a potentially releasable code base. If there was a branch for each release, the website would need to be manually updated to use each release branch, and someone would have to merge variant additions back into master/development. Using tags for releases was a great decision because my site could pull from master and I didn't have to worry about what version was being built at any given time.

All users of the application used the latest in-production version of the application. Because of this, there wasn't much of a need to go back to old versions of the code base. I don't see the approach working very well for teams that support multiple versions of the same application, but the workflow was great for what we needed it for.

Job #2 - Development on Master Branch, Branch on Release

At a different job, my team was among the last in the company to use Git for source control. As a result, my project inherited a Git workflow that the rest of the company had already implemented, and this ended up being the mirror image of the previous workflow:

1. Use master for development
2. Branch for each release

This probably worked well for the other projects because they released infrequently. But my project could see multiple releases in a week, so this approach quickly lead to the server having many branches that you would not need to restore.

On the other hand, having branches for each release allowed me to quickly see the version of the code base in-use in release by a user. Not all users ran the same version, so being able to see/hotfix old versions was essential. If we had used tags for releases, it would have been far more difficult to switch between them and work on hotfix releases.

At this job, development and testing went on concurrently, so working off of master made sense there. It might not work well for places utilizing a development -> test cycle because the version that testers get could have bugs or workflow changes introduced by in-development features.

Using Git With TFS

Background (In a hurry? Skip this part.)

Did you know that Android Studio, as of this writing, does not have Team Foundation Server integration? This has a wide variety of consequences:

• Every project file is read-only, and you need to unlock each manually
• You cannot checkin files from Android Studio
• New files are not automatically added to source control
• Files that need to be excluded from source control might get checked-in

One way to avoid these problems is to use a different source control for Android Studio projects until it supports TFS. But you may be required to use TFS for any number of different reasons. For example, I work for a company that uses TFS for source control and work items.

There's a way to use Git (which Android Studio fully supports) with TFS repositories.

Use Git-TF

Git-TF allows you to use Git to manipulate TFS repositories. This is great for situations where you're not working from an IDE with TFS integration but still need to use TFS.

There are two ways of installing Git-TF: manually and with Chocolatey. Both are easy, but be careful about using the Chocolatey install because it requires JRE 7 (and not 8) and overwrites some system settings that you may need.

You'll want to follow Git-TF's "Individual developer with a new repository" instructions because you will want to work with a new Git repository on your local machine.

Recommendation: Checkin .gitignore to TFS

TFS does not use .gitignore files, but I think that they should still be checked into TFS. Multiple members of your team may want to use Git-TF for a project, and including .gitignore makes it easy for them to jump-in without having to add their own .gitignore.

Be Careful About Directories

If you currently use Git and TFS, using Git-TF should be easy. But there's a catch that I've encountered: Git-TF does not work well when used within a directory mapped to TFS.

If the TFS repository root is mapped to C:\TFS, and your Git repository is in C:\TFS\AndroidStudioProject, you will encounter errors when trying to checkin or shelve changes. These errors are workspace-related and (as far as I know) can only be resolved by unmapping the directory or creating your Git repository in a different directory (such as C:\GitProjects).