34

First, some background, we are in the process of moving all of our project teams over to using git and are in the process of laying down the guidelines for how the repositories should be organized so that certain branches can also be monitored for continuous integration and automatic deployment to the testing servers. Currently there are two models that are developing:

  1. Heavily influenced by the nvie.com article on successful branching with the master branch representing the most stable code, a development branch for the bleeding edge code, and an integration branch for code that is ready for QA testing.

  2. An alternate model in which the master branch represents the bleeding edge development code, an integration branch for code that is ready for QA testing, and a production branch for the stable code that is ready for deployment.

At this point, it is partly a matter of semantics in regards to what the master branch represents, but is doing active development on the master branch actually a good practice or is it not really that relevant?

4
  • 2
    I like the worfklow that Scott Chacon uses to develop GitHub: scottchacon.com/2011/08/31/github-flow.html
    – user16764
    Commented Feb 3, 2012 at 14:51
  • 1
    As described it seems to me to be more of a semantic problem than not - any organisation is going to evolve their own processes and in some respects the names need to reflect your workflow. Generically the key seems to be that somewhere you define something such that "the source code of HEAD always reflects a production-ready state". What you choose to call that is less important but both git-flow and the GitHub workflow focus on that separation and on controlling when you push to the production-ready "thingy"
    – Murph
    Commented Feb 3, 2012 at 18:16
  • @Murph - True, but since we are doing some of this from scratch I thought it would be best to more or less follow common conventions so that new developers that are hired don't have a steep learning curve due to unusual internal practices.
    – rjzii
    Commented Feb 3, 2012 at 18:39
  • Then you've answered your own question (-: To be honest even by asking the question you're way ahead of the curve...
    – Murph
    Commented Feb 3, 2012 at 22:56

2 Answers 2

Reset to default
37

The only real defining feature of the master branch is that it's the default for some operations. Also, branch names only have meaning within a specific repository. My master might point to your development, for example. Also, a master branch is not even required, so if there's any confusion about which branch it should be, my advice is usually to leave it out altogether.

However, in my opinion, the best way to think of it is as the default for pushing to. Most any online tutorials your developers read are going to assume that. So, it makes a lot of sense to have master be whatever branch is most often pushed to. Some people think of it as the pristine copy that is untouchable to developers except after the strictest of scrutiny, but using it that way removes a lot of the helpful defaults git provides. If you want that kind of pristine branch, I would put it in a completely separate repository that only some people can write to.

Edit:

This question is still getting attention after several years. In that time, the "master should be the pristine tested copy" theory has come to dominate, especially when using GitHub. So while git is still a very flexible version control system, and my original answer still has some merit if your needs are somewhat atypical, in general you should today be going with the model people expect, which is to develop in feature branches and pull request into master, merging only when it has been tested and reviewed.

4
  • 7
    +1. And because the "production ready" code is the important code, it should also live in a branch with a name highlighting this importance. "master" as the default branch name surely doesn't fulfill that request, as it is also used in every other repository for whatever intentions.
    – Bananeweizen
    Commented Jun 18, 2013 at 9:29
  • 5
    +1. This is the real-life answer. To emphasize the point: no one on your team defined the "master" branch, the git system did. For anything important, stick to branches that someone on your team has defined.
    – Travis Wilson
    Commented Mar 31, 2014 at 17:00
  • 1
    Fully agree. While I very much like the git flow model (nvie.com/posts/a-successful-git-branching-model), the only thing that disturbs me there is that master is strictly reserved for releases, which is counter-intuitive.
    – Bachi
    Commented Jan 7, 2015 at 11:56
  • @Karl Just a note that a recent update to git changes the default branch name from master to main for new repositories.. lore.kernel.org/git/… GitHub has already adopted this change. github.com/github/renaming
    – Adrian J. Moreno
    Commented Nov 19, 2020 at 18:44
14

No, it's not advisable, even in the beginning before you've gone to QA. As a best practice, the pattern for development should be consistent from start to finish. Your master branch should start out empty, you should branch your development branch off and begin adding files, merge into your integration branch, then subsequently to your master.

While no one may care during development that the master branch doesn't build, it lends itself to bad habits early on. The master should always build, and for major feature releases it also wouldn't be a bad idea to have archived branches of major builds so that stable release points can be returned to if necessary.

2
  • 3
    Isn't it better to do version tracking via tags?
    – Adonis K. Kakoulidis
    Commented Oct 20, 2013 at 21:56
  • 2
    @AdonisK.: I fail to see the relevance of your question.
    – Joel Etherton
    Commented Oct 20, 2013 at 22:19

This site is temporarily in read-only mode and not accepting new answers.

Not the answer you're looking for? Browse other questions tagged .