Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this community
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?
Note: I'm really interested in Mercurial specifically, but any other DVCS or just general rules would be ok
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.
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.
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.
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.
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.
