up vote 16 down vote favorite
3

We're integrating Mercurial slowly in our office and doing web-development we started using named branches.

We haven't quite found a good convention as far as naming our branches though.

We tried:

  • FeatureName (Can see this causing problem down the line)
  • DEVInitial_FeatureName (Could get confusing when developer come and go down the line)
  • {uniqueID (int)}_Feature

So far the uniqueID_featureName is winning, we are thinking of maintaining it in a small DB just for reference.

It would have: branchID(int), featureName(varchar), featureDescription(varchar), date, who etc...

This would give us branches like: 1_NewWhizBangFeature, 2_NowWithMoreFoo, ... and we would have an easy reference as to what that branch does without having to check the log.

Any better solution out there?

share|improve this question
up vote 14 down vote accepted

If you don't have an issue tracker, I recommend setting one up and then using {issue tracker name}_{ticket number}. When someone years from now files a bug and you don't know exactly how the feature was supposed to work, it'll be easy to annotate the file and get back to where the user may have requested that exact functionality.

share|improve this answer
  • Agreed we do have a bugtracker and are planning to use the bugID in the branch name for bug fixes. My question was more for totally new development, when you aren't fixing anything but adding something totally new. I suppose we could create a dumb enhancement ticket and go from there. – jfrobishow Oct 1 '10 at 2:27
  • 5
    You absolutely should be creating tickets for new features. The are work to be tracked too. +1 for requiring unique id. – AShelly Oct 1 '10 at 2:45
  • If you make sure to put all the details of new features into the tracker, someone later can verify whether its working as designed or if there is really a bug. I work on a development team that maintains a 5+ year old program. There are times where the client files a bug and when we research it we find that is working as designed and the original developer and the original requester are both gone. We have similar situations where we don't know why something is the way it is and if the features weren't in the tracker we would have no way of finding out. – Asa Ayers Oct 1 '10 at 14:17
up vote 2 down vote

I suggest to keep it simple and name branches according to the FeatureName (or feature-name) convention. Yes, this means a shared namespace, but this is rarely a problem in the real world. Once a feature is done and completely merged into the mainline the branch can be safely deleted.

The main idea of distributed version control is that it should be easy to branch, introducing additional bureaucracy, like the obligatory unique id, is only going to make this harder.

share|improve this answer
  • 1
    I agree, this is the way to go. In what world would you ever have so many branches that you can't avoid collision? – alternative Sep 30 '10 at 22:59
  • Fair enough, getting a description tied to the name I guess is more important to us... the initial commit should contain it, but I don't know of any way to extract that quickly. – jfrobishow Oct 1 '10 at 2:34
  • 1
    In a big corporate environment, letting developers make up names for features will cause headaches sooner or later. – AShelly Oct 1 '10 at 2:51
  • 1
    I see, because in "big corporate environment" developers cannot be trusted. But wait, they also make up names for variables, functions and files. We should set up a committee to control that too! (irony) – Adam Byrtek Oct 1 '10 at 11:24
up vote 2 down vote

I recommend use such form (as example):

BUG_ID
BUG#ID
TICKET_ID
TICKET#ID
feature_bla-bla-bla
release-x.xx.xx
release_x.xx.xx
build_2010-20-12
build_4565
BRANCH_x.xx.xx

Just select good prefixes (to allow filter output from hg branches), capitalization rule and delimiter between prefix and ID/names.

share|improve this answer
  • +1 we went with BUGID_{freeCamelCasedTextDescription} in the end. – jfrobishow Jul 20 '11 at 20:56

Your Answer

 

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.