How do you avoid working on the wrong branch?

Question

Being only a little careful is usually enough, but sometimes I need to double check the branch I'm working on (e.g "hm..i'm on dev branch, right?") and I check the source control path of a random file.

In search for a shorter way, I thought of naming the solution files accordingly (e.g MySolution_Dev.sln) but with different file names on each branch, I can't merge solution files.

So it's not a big deal but are there any methods or "small tricks" you use to quickly ensure you're on the correct branch?

Edit: Using Visual Studio 2010 with TFS 2008.

Answer 1

You could create an empty file in each branch, e.g THIS_IS_TRUNK.txt in trunk, and THIS_IS_DEV.txt in DEV.

Answer 2

Lots of answers here already, but none that touches on the simple solution we have where I work: for each branch, create a new VM containing a dev environment, and check out from the proper branch. You only have to do that and get it right once, and then you just switch VMs to switch branches.

Answer 3

I've been using VSCommands extension (with Visual Studio 2012, but there is a 2010 version) and it conveniently puts the branch name in the upper left corner of the screen as well as into the solution explorer.

Not affiliated with the product in any way, just a happy user.

Answer 4

There's a free Visual Studio extension called TFS Solution Info that may help with this. It shows you the current branch and workspace in a little window that you can dock/pin wherever you want.

Answer 5

A specific answer depends on the version control software that you're using, but there's usually a command that lets you easily see the branch you're working on. For example, with Subversion, use the svn info command in a directory to see the URL for that branch. If you're more interested in a particular file, you can specify that too:

caleb-dev$ svn info foo.c 
Path: foo.c
Name: foo.c
URL: https://svn.mycompany.com/repo/sample/branches/caleb-dev/foo.c
Repository Root: https://svn.mycompany.com/repo/sample
Repository UUID: d62f7aef-3ad2-6098-12a-c16647d854ab
Revision: 1042
Node Kind: file
Schedule: normal
Last Changed Author: caleb
Last Changed Rev: 1031
Last Changed Date: 2011-06-07 15:28:27 -0400 (Tue, 07 Jun 2011)
Text Last Updated: 2011-06-08 03:08:12 -0400 (Wed, 08 Jun 2011)
Checksum: 123456789098765432123456789098

From the URL, I can see that my copy of foo.c is in the caleb-dev branch.

I don't need to do that very often because my local directory has the same name as the branch. A quick look at my command line prompt is usually enough to confirm that I'm in the right directory, and therefore working in the right branch.

Answer 6

I avoid working in the wrong branch by doing almost everything in one branch (in trunk - per so called "unstable trunk" branching strategy).

The cases when I am forced to update branches are pretty rare - these are pre-and post-production bugfixes (prod candidate code is isolated in branches). Since these fixes should be in trunk too, I typically draft, test and verify them right there in trunk, then port to prod branch. Porting as a rule involves just a straightforward copy of 1 to 5 files to branch and build check.

• I am also somewhat lucky that in most of my projects management preferred to convince customers to use newer releases instead of patching old ones - this brings post-production part of updates in branches to almost negligible minimum.

Answer 7

I do a lot of my (D)VCS work from the command line. I highly reccomend having your prompt display where you are at. For instance, my prompt when in a Git repo looks like (I do this for SVN too):

[BranchName]RepoTop/path/to/current/wd >>

And if the repo is currently dirty (uncommitted changes):

[BranchName!!]RepoTop/path/to/current/wd >>

I also have the background set to red if logged into prod, things like that. I find simple visual notifications to be super effective for me.

You mentioned that you often see this most after coming back to your computer. I find a post it note, with my current focus (branch, bug #, feature) stuck to my keyboard when I leave, to be super effective in allowing me to get back to work quickly, rather than recreate whatever it was I did last.

Answer 8

I don't work in a generic dev or trunk branch.

I ALWAYS do work in feature branches. When a feature is done, I follow these steps.

1. Open Source Control Explorer.
2. Merge from dev into current feature branch.
3. Fix any conflicts and ensure everything still works.
4. Check in again. Merge feature into dev branch.
5. Open dev solution.
6. Checkin dev branch.
7. Close dev solution.
8. Let CI build and deploy.

I only have the dev branch open for a few minutes at a time and close it right away.

Answer 9

Name the working directories differently. That is, if your project is titled "MY_PROJECT," create a different working directory for each branch. If there is one branch named "dev," then you'd need a directory for trunk and a directory for dev, like this:

~/henginy/projects/MY_PROJECT-trunk
~/henginy/projects/MY_PROJECT-dev