3

Using git, I understand branching and how to use master, develop, feature branches etc. in day to development for a website after it has gone live.

But for the initial big chunk of development that takes place (12 weeks or so) in order to get the sites first release build I'm not so sure of the best branching strategy.

Is it fine in this stage to commit and push directly on master? If not, what is the preferred strategy for git during the initial development phase before the first release.

Marty Wallace
  • 34,046
  • 53
  • 137
  • 200

5 Answers5

3

Is it fine in this stage to commit and push directly on master

In theory, No: master could only contain stable usable version of your code.
Preferably what is running in production (the live version of your website)

As charles comments below, it depends what you want to do by default when cloning a repo

what is the preferred strategy for git during the initial development phase before the first release.

You can isolate that integration phase on its own branch, which is the result of the merge of one or several feature branch, in order to test all features together.

The first release will see:

  • a merge to master
  • a tag 1.0
  • a branch 1.0_hotfix done from said tag, in order to isolate hot fixes that:
    • you will merge to master
    • you will merge to other feature branches currently developed for 2.0 if you think that hotfix makes sense in that new context (some bugs aren't actually relevant in 2.0 because of some 2.0 refactoring)

Now in practice (and this is where I agree with Charles's answer), if all the features you are developing will make it to first release, you could develop everything on master, release it, put a tag 1.0.

But once the first release is done, I would still recommend isolate hot fixes in their own branch.

Again, depending on the default role you want master branch to have, you can develop directly in it.
Try only to avoid merging from master to other branch ("back merge").
If you have feature you have to back port in past release, develop them in their own branch before merging them to master and to other release branches.

As an example of a large project following that model (development on master, and branches for release), you can see the organization of gitlabhq.

enter image description here

The idea is to only commit to master feature that you are sure will make it to the next release.

Experimental features (that might or might not make it) should be isolated in their own branch (or in master, but in a cloned repo, and merged through pull requests).

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • The default branch that you want most people to work on most of the time should be the default one they get checked out on clone. This is the `HEAD` of the central repository, usually master. If you want a stable branch that trails master, this shoul be called something else _or_ you should change HEAD to point to a branch with a different name. IMHO, of course. – CB Bailey May 05 '13 at 12:47
  • @CharlesBailey before the first release, I agree. After the first release, I would rather clone a repo and have something that works, rather than getting a dev in progress with potential bugs in it. – VonC May 05 '13 at 12:53
  • If I'm cloning, it's because I wan to develop; otherwise I'd just download a stable versioned tarball. Agree to disagree? – CB Bailey May 05 '13 at 12:55
  • @CharlesBailey No, I can agree to agree ;) I my shop, I have actually repos dedicated for development only, with `master` branch used precisely for that role (dev in progress). – VonC May 05 '13 at 13:00
2

The only time you should branch (by which I mean create a separate central named shared branch) is where you have some development objective for which you don't want all of the changes which would normally go into the origin branch off which you are proposing to branch.

It sounds like all of the work you are doing is working towards your one goal - first release. There does not seem to be a good reason to have more than one branch at this stage.

CB Bailey
  • 755,051
  • 104
  • 632
  • 656
  • +1 (I didn't see your answer while I was writing mine): simpler approach (which I mention in my answer). I am used to larger project ;) – VonC May 05 '13 at 12:45
1

My recommendation is that you actually do the same practice before and after the main go-live. I think that it is not a good idea to have different practices before and after.

I believe that practice should be to never develop in master, always use branches.

Create a branch and when you've finished with the work for a while and you feel it is in a fairly stable, working state, push it to master.

Branches are very cheap, quick and lightweight, look: checkout -b newbranch I just created one!

Note that this extensive use of branches differs from older version control system where a branch frequently meant you actually wanted to diverage from the main path and go in a different direction.

The one area that I would treat differently perhaps is the 'release' branch which I do agree is a good idea. Before your first release this doesn't exist. After the go-live this will be the branch that is collecting up features/fixes/chores ready for QA and release into master for production.

You may also find https://stackoverflow.com/a/9204499/631619 useful for more git info.

Community
  • 1
  • 1
Michael Durrant
  • 93,410
  • 97
  • 333
  • 497
  • I agree, but Charle's comments to my own answer point to a different practice: what do you want to get when cloning by default a repo? If it is the latest developments, then it can make sense to see those commits done directly on `master`. That being said, +1 for quick short-lived feature branches :) – VonC May 05 '13 at 14:49
0

My favorite best practice is the one adviced by git-flow

http://nvie.com/posts/a-successful-git-branching-model/

and the corresponding tool

https://github.com/nvie/gitflow

The way I've always interpreted this, you should do initial development on the develop branch. From the development branch you do feature branches, and when you are nearing release you do a release branch. You only merge the release branch to master when you actually do a production release.

Klas Mellbourn
  • 42,571
  • 24
  • 140
  • 158
  • Funnily enough, `git-flow` can be viewed as a bit too sophisticated ;) That is why GitHub has its own workflow: http://scottchacon.com/2011/08/31/github-flow.html – VonC May 05 '13 at 14:45
  • I agree with @VonC but I'd probably go further. The "git flow" workflow is over-engineered for most situations, in my experience. It also seems to advocate only making release tags on master; but where does a 1.x hotfix get tagged if 2.0 already exists? – CB Bailey May 05 '13 at 15:10
  • @VonC The GitHub flow is certainly an interesting and relevant alternative. But it seems to me that it builds on the premise that you release every time you merge to master. In my experience that is too simplistic for most enterprise shops. – Klas Mellbourn May 05 '13 at 15:34
  • @KlasMellbourn I don't disagree with the premise you mention: this is very much tailored to GitHub habit of releasing as often as possible. – VonC May 05 '13 at 15:36
  • @CharlesBailey Bit of a two-pronged critique there. First you think it is over-engineered and then you mention that you miss a very advanced feature :) Actually I think you pose an interesting question, I don't know the "purist" answer to how you should handle that. I guess you could put the release tag on the hotfix branch, but that would create a permanent release branch beside the master. – Klas Mellbourn May 05 '13 at 15:42
  • Exactly, it's fairly complex and yet it's not complete for some common project types. I think the real issue is that a permanent linear release branch is a purely artificial construction. Once the release branch is ready, make the release tag there and the problem goes away. – CB Bailey May 05 '13 at 15:58
  • @CharlesBailey In real life, I haven't had the problem you describe. One advantage of git-flow is simply that it is properly documented. Could you point me to an alternative, well documented branching model? (GitHub flow is well documented, but not useable for me for reasons given above) – Klas Mellbourn May 05 '13 at 16:18
  • Then you probably haven't had support a product with multiple major versions in active use at the same time. There is no "one size fits all" branching model and I don't know your situation but in most cases it pays to sit down and work out your requirements and choose the simplest solution that fits your needs. Copying another process from someone else wholesale, if it meets all your requirements, is likely to end up with you following more "process" than is strictly necessary. – CB Bailey May 05 '13 at 17:01
  • @CharlesBailey no, but that doesn't mean that I haven't been in projects with fairly complex branching requirements. Assuming that you can just sit down and come up with a good strategy without looking at best practices seems optimistic to me. – Klas Mellbourn May 05 '13 at 17:07
  • Absolutely, ignoring best practices would be foolish. – CB Bailey May 05 '13 at 17:19
0

Usually, when we talk about git workflows, we assume that we are in a stable stage. By this, I mean that we are already into a few weeks of development, and adding new stuff or making changes is usual day-to-day life.

But I think that the workflow actually evolves with the age of the code.

For example, when you first create a project, you will not bother about creating branches. It does not make sense to think about git that much, when you have not even started coding. This is kind of experimental phase. Everything you write is probably trash.

After a few days of development, your project starts to take shape, and you don't want to break the stable parts of it. And you also want to collaborate with your team members. So you want to create branches for new features. But quickly merge them to master too, since the overall codebase is still small, and manageable.

Once the code is too big to be manageable, then you actually talk about git workflows to manage it. And there are many workflows mentioned all over the place.

So to answer your question, if your codebase is small, focus on making the product right now, rather than managing the code.

Sailesh
  • 25,517
  • 4
  • 34
  • 47