Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Branching & Release Scheme #14
While #6 focuses on how to decide for a versioning scheme (e.g., semantic versioning), this issue focuses on the branching and release policy, hence what branches to create when, how to merge them, when to release, what can and should be automated etc.
Migrating the discussion with @sweisgerber-dev here:
I looked into GitFlow and I have to admit that I share some of the critique towards the model (see here), such as the unnecessary
Let me therefore add some new suggestions to the discussion:
Maybe an adapted version of one of the above models can fit our purpose.
Some opinionated remarks from my side:
Comments are very welcome.
Well most of the critic to git-flow in the linked article is valid, with "being too complicated" leading the way.
Yes, as long long as we can still squash when it makes sense, like e.g. eliminating multiple WIP/Backup commits when merging a feature branch to master, I agree with you. There are often scenarios where we wan't to keep separate commits.
I'm not yet decided if it should be "stable" or only be able to compile and execute in a potential buggy way.
Yes, I agree with you here, that sound like a good alternative, perhaps mix it w/ OneFLow. Let's discuss this topic further in person and leave the results here later.
@sweisgerber-dev and me discussed this for a while and I will share the results here to resolve this issue:
First off, the master branch is our current (somewhat) stable state. It successfully builds (if combined with the correct versions of other repos if needed) and does not contain half-baked features, untested bug fixes or the like. Since our projects are not suitable for continuous delivery, there is no auto-deploy or auto-publish for master.
When working on features, fixes or refactoring, we branch off master and name the branch accordingly (
Releases are based on the master branch. Depending on whether we need to have extra commits for a release, we use one of two possibilities for our repos:
@sweisgerber-dev pls have a look again to check if I missed sth, but I think this should suffice for now.