Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this community
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:
master sacred == not only compilable, but also HEAD has passed QA at all timesmaster?
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.
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
masterbranch 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.
