GitHub workflow changes... revised

Bloke · 2016-09-16 10:33:59

[This post is a follow-on from the first attempt at a revised workflow, but that thread can be ignored: it is preserved for historical purposes only]

From this moment forward we’ll be adopting a variant of the GitFlow Workflow for Textpattern development. The differences are that we’ll work on a dedicated branch — essentially a maintenance branch — for each point release instead of working directly on master.

From 4.6.1 onwards, master will be only for releases. It will never be touched in the interim, so will house the stable versions of Textpattern, tagged appropriately.

There is (or will be shortly) a maint-4.6.1 branch for patching the current 4.6 release. This will be released to master when we’ve ironed out a few more bugs. We’ll then make a maint-4.6.2 branch to catch any further hotfixes, and so forth. If we end up not needing that branch because 4.7.0 comes along in the meantime, it will be deleted.

There is a dev branch which is for the next major version of Textpattern. As of this writing, that’s 4.7.0. Any features that are not direct bug fixes for the current release go here.

This workflow has some important guidelines to follow:

Hotfixes on the maintenance branches go towards the next point release (4.6.1, 4.6.2, etc).
Any changes that get pushed to the maintenance branches must be merged to dev as soon as they are finished. This keeps future development in sync with bug fixes to the current release. Do not just apply the same fix to both branches or it creates merging difficulties. Apply it to one, then merge to the other.
When a maintenance branch is considered feature-complete it is merged to the master branch and tagged. The maintenance branch is then deleted and a new one made for the next point release.
When dev is considered feature-complete, it is merged to master and tagged. This can either be done directly to master (possibly tagged as a beta or RC) or onto an interim release-x.y.z branch first, which is then merged to both master and dev, then deleted. For betas, it’s probably not necessary to do this interim step, but for final releases, it allows a release to be ‘polished’ — language files updated, checksums fixed, svn flag toggled, etc — in a dedicated ‘staging’ area before pushing the entire bundle to master and dev.

tl;dr:

master is for stable releases only.
maint-x.y.z branches are temporary work areas for maintenance / bug fixes to the last release tagged on master.
dev is for development of the next major version.

Any issues, please pipe up.

gaekwad · 2016-09-16 16:33:00

Bravo.

etc · 2016-09-17 12:48:47

Euh.. I’ll wait for someone’s commit, to learn by example. :-)

Bloke · 2016-09-17 22:28:01

etc wrote #301586:

Euh.. I’ll wait for someone’s commit, to learn by example. :-)

There you go. One maintenance branch for our 4.6.1 dev work, which will exist until we decide to release (and tag) it to master. Then it can be deleted and we can start a fresh maint-4.6.2 branch.

It’s been forked from master so doesn’t have any 4.7 code in it. For future reference, in command line parlance, these are the steps when creating the first maintenance branch after a release.

git checkout master [ensure we are on master]
git checkout -b maint-4.6.1 [create new branch]
# Make changes/perform bugfix and add them.
# If coming from a full release, the first change should be to reset the SVN flag to true.
git commit
git push -u origin maint-4.6.1 [push and track branch to central repo]
git checkout dev [because we want all maintenance changes in dev too, right]
git merge maint-4.6.1 [merge changes we just made into dev]

Job done.

From this point, anyone else who does git pull will pull the new branch down as normal, but it probably won’t be set to track the branch by default. Depends on the client you’re using. So when you do git checkout maint-4.6.1 you’ll be able to work on the branch as normal but it’ll (probably) complain when you try to git push.

If it whines, it’ll also tell you what command to type or option to pick in order to track it. Depending on the version of git you have, it will be a slightly different process. For command line use, it may involve the -u switch (git v1.8+) or the --set-upstream-to switch for earlier versions. For GUIs I have no idea: I’m a keyboard guy.

When tracking has been set up once, you can then just checkout the branch any time you want to do work on the next maintenance version. As long as we all remember to always merge those changes into dev afterwards, we should be able to avoid messy merges later when we come to release 4.7.0. Fingers crossed.

Textpattern CMS

Textpattern CMS support forum

#1 2016-09-16 10:33:59

GitHub workflow changes... revised

#2 2016-09-16 16:33:00

Re: GitHub workflow changes... revised

#3 2016-09-17 12:48:47

Re: GitHub workflow changes... revised

#4 2016-09-17 22:28:01

Re: GitHub workflow changes... revised

etc wrote #301586:

Board footer