[tsc-devel] Changing the Git branching model

Marvin Gülker | Sun, 09 Oct 2016 17:03:52 UTC

Hi everyone,

from the outside TSC looks pretty slowly developed, and from the inside
I also have this impression more often than not. Taking a look at the
git log of “devel”, there for two months have not been many commits, and
no commits by anybody else than me. Actually there have been more
commits and by someone else than me (datahead), but they sit around in
their separate feature branch forever and with the low amount of time we
can dedicate to the development it is uncertain when this will
happen. Taking a project’s main development branch as its development
activity measure is common and serves TSC ill.

This is not a singular case; the SFML and CEGUI changes were in their
feature branches for months, before a big blob merge happened at some
point in time (or not, see the proposed but never finished filesystem
compression changes).

As of now, we are using the GitFlow model[1] to manage our branches, and
I think that it has failed its purpose for our slow environment. I know
there are people who dispute the usefulness of the GitFlow model
altogether, but I wouldn't want to go as far as that. It surely has its
uses, but I think those uses are more appearent in an environment were
many coders simultaneously work on a quickly evolving codebase. As of
now, this is not the case for the Secretchronicles project. As a result,
its formal nature with all its separate feature, hotfix, development,
and master branches, which is intended to organise large development
structures, hinders a small project like ours more than it serves it.

I would thus like to suggest to change away from it and instead do
things differently. The entire GitFlow model is rather formal and
difficult to learn, which is not really useful in our context. Instead,
I suggest a simple set of rules:

a) All normal development should happen in the main branch.
b) If you develop something large that frequently breaks compilation,
   develop in a separate feature branch that is available from the
   repository.
c) Locally, you can use any amount of branches you find useful.
d) If you are not a TSC team member and thus have no commit access,
   your changes should be in a separate branch for your Pull Request.

The “master” branch we have now only contains tagged releases. Nonsense,
we have tags for that, thus this purpose is completely eliminated. In
return to classical Git terminology “master” should be the main
development branch, and “devel” shall vanish. Current unmerged feature
branches are merged into “devel” before merging “devel” into “master”.

This suggestion is part of my desire to get others more involved. An
overly formal development model is not good for that.

Please give opinions if you either have coded on TSC or want to code on
TSC in the future as it will affect you then.

Valete,
Quintus

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

-- 
Blog: http://www.guelkerdev.de
PGP/GPG ID: F1D8799FBCC8BC4F