1

My app is being deployed on various platforms, among which GNU/Linux, iOS and Android. I am contemplating the branching model of the central C++ code git repo, upon which all platform-dependent code depends.

Would it be a good idea to keep it simple by:

  • keeping master sacred == not only compilable, but also HEAD has passed QA at all times
  • releasing from feature branches by tagging commits, then merging to master
  • that's it

?

1
  • 1
    This is what we do at my work. Don't hold master sacred though, you will find that you have to make changes to developer, build, and ci scripts. Having a broken master is no fun. – Kain0_0 Jun 26 '20 at 2:20
1

It doesn't really make much of a difference, as far as git is concerned. The thing to understand about git is that branches and tags are both nothing but pointers to a commit.

When you're on master, and you commit new code, git simply moves the master pointer to the new commit. When you tag a commit, all it does is create a new pointer to that commit.

If you want to release something, some process like the following works perfectly fine:

git checkout -b release/1.1.2
# Do stuff to finalize the commit
git tag 1.1.2
# Do whatever you do to release that tag
git checkout master
git merge release/1.1.2

The benefit of this is that development can continue in master while you're finishing the release branch, and then it's simply merged back in.

This is an extremely simplified version of the git flow model, which I highly recommend.

1

You've basically just described Github Flow (not to be confused with Git Flow).

A couple key quotes clearly show the similarities:

There's only one rule: anything in the master branch is always deployable.

With GitHub, you can deploy from a branch for final testing in production before merging to master.

Once your pull request has been reviewed and the branch passes your tests, you can deploy your changes to verify them in production. If your branch causes issues, you can roll it back by deploying the existing master into production.

There's no mention of tagging, but it is coming from the perspective of a continuously delivered web app, so the Github folks might not have considered tags necessary. I would be rather astounded if simply adding tags broke anything.

One possibly area of concern is supporting multiple concurrent versions. Github Flow seems optimized around only supporting one version at a time, which may cause friction if you want to continue providing bugfixes to people using 1.x after the release of 2.0. Maybe simply adding tags will be sufficient, maybe you'll want to consider a different workflow, such as the aforementioned Git Flow.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.