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.

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?

share|improve this question
    
I like the worfklow that Scott Chacon uses to develop GitHub: scottchacon.com/2011/08/31/github-flow.html –  user16764 Feb 3 '12 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 Feb 3 '12 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 Feb 3 '12 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 Feb 3 '12 at 22:56

3 Answers 3

up vote 7 down vote accepted

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.

share|improve this answer
    
Isn't it better to do version tracking via tags? –  Adonis K. Oct 20 '13 at 21:56
    
@AdonisK.: I fail to see the relevance of your question. –  Joel Etherton Oct 20 '13 at 22:19

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.

share|improve this answer
    
+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 Jun 18 '13 at 9:29
    
+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 Mar 31 at 17:00

I haven't been using Git for very long, but everything I've read so far says "no, not really". This article talks about a recommendation for setting up Git branching; in his model, the master branch is only used for release versions, while a separate development branch is used for everyday commits.

share|improve this answer
1  
That's actually the same article I linked to in the question. :) So far everyone I've talked to has said the same thing with the only exception being when you are doing early development and haven't started QA testing yet. –  rjzii Feb 3 '12 at 14:27
    
Ah poo. That's what I get for not reading carefully :( –  Andrew Arnold Feb 3 '12 at 14:31
1  
That's the branching model that we have adopted in the currently small, but expanding, development team here and it's working very well for us. –  Julian Feb 3 '12 at 15:37

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.