Git workflow for getting to first release

Question

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.

Answer 1

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.

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).