Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

If your following the standard DVCS methodology of having a production branch and a development branch, I'm really interested in what do you do with the default (mercurial) or master (git) branch?

  • Do you delete it (not recommended by several guides)?
  • Do you use it as production?
  • Do you use it as development?
  • Or do you leave it empty and have separate dev and production branches?

Note: I'm really interested in Mercurial specifically, but any other DVCS or just general rules would be ok

share|improve this question

5 Answers 5

as answered here in different ways, and in some other ServerFault question, you want to follow Mercurial guidelines here:

3 . The default branch

This is where development of new features occurs. [...]

(!) It is strongly recommended to do your primary development on the so-called 'default' branch, because it is the branch used by default in various commands such as clone.

The rest of article explains pretty well how to manage development Vs release branching.

share|improve this answer

I asked myself the same question recently.

In our project, we maintain one branch for each major version of the application. I assume that these are the same as the "production branches" you are talking about. We call them "maintenance branches", here.

My first thought was to completely get rid of the default branch of mercurial, and have one branch for each major version. This would lead to this structure :

        branch   tag

    o     v2     2.2
  o |     v3
  | o     v2     2.1
  |/
  o       v2     2.0
  |
  | o     v1     1.1
  o |     v2
  | o     v1
  |/
  o       v1     1.0
  |
  o       v1

It works, but there is a downside to this approach : if you clone a repo like this, a simple hg update will do nothing, since the default branch doesn't exist anymore. Personnaly, I expect to be in the latest development state, after performing an hg update.

In the end, we chose this structure :

          branch             tag

    o     maintenance-V2     2.2
  o |     default
  | o     maintenance-V2     2.1
  |/
  o       default            2.0
  |
  | o     maintenance-V1     1.1
  o |     default
  | o     maintenance-V1
  |/
  o       default            1.0
  |
  o       default

The default branch is the development branch, and the other are version maintenance ones. Performing an hg update brings you to the latest default changeset, which is in this example the next V3.

share|improve this answer

My understanding is that your default branch is usually 'dev', and you create a new branch for each release (or tag, then branch when you need to bugfix). 'Prod' is just your most recent release. This is how we're planning on using Mercurial, although we're still pre-release.

Conceptually this make sense to me: a release is just a certain snapshot in time of your development process.

Edit: for a different take, see A successful Git branching model.

share|improve this answer
    
That's a ton of branches. I always thought you just tag and when you need to bugfix you checkout the tag, make changes, pull all the new updates, and merge. But anyway, interesting to see how you do it –  TheLQ Apr 15 '11 at 0:27
    
I didn't write that very clearly. I was thinking more of branching for a major release, which you need to constantly patch. For example if you currently support v6.x and v7.x and are working on v8.x you'd have three live branches: 6, 7 and default. For point releases I agree that you'd tag and branch as needed. –  Ben Hughes Apr 15 '11 at 0:35

The practice used by git core and the kernel has been documented in the gitworkflows manpage. Another, more recent workflow is the git flow workflow. Both recommend using master as the "production" branch.

share|improve this answer

Do you delete it (not recommended by several guides)?

No.

Do you use it as production?

No. Once a state of the code is deem production-ready, git tag is used to mark it.

Do you use it as development?

Yes. The standard Git development way is for each developer to create a branch (locally) and do dev work specific to a single task. So, mimicking those that have given Git presentations...

"Create a branch. Work work work. Commit. Work work work. Commit. Merge. Push."

Once that issue has been finished, it is merged into the master branch and then pushed onto the master branch in the accessible repo. Essentially - when viewing the workflow at the repo level - having all the dev work performed in the default/master branch.

share|improve this answer
    
Thats one way I've seen with a few Git repos. Of course then in Github they have a monster branch list –  TheLQ Apr 15 '11 at 1:12

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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