Branches & git workflow

George Kiagiadakis kiagiadakis.george at gmail.com
Tue Jan 31 14:34:35 UTC 2012


Hi,

I just created the 'kde-telepathy-0.3' branches in all the relevant
repos. In many of them I based the branch on commits done after the
0.3.0 tag, to include some fixes. I also changed the 'i18n stable
branch' setting on projects.kde.org, so hopefully translations of the
stable branch will now be separated from translations of master.

I would like now to discuss a bit the git workflow regarding stable
branches. There are two ways of getting patches in the branch:
back-porting and forward-porting.

In backporting, what you do is:
* work in master and commit fixes there
* cherry-pick these commits in the stable branch

In forward-porting, what you do is:
* work in the stable branch for fixes, or a feature branch based on
master if you are developing a new feature
* when you need to commit a fix, commit it (or merge it, if it's a
whole branch) in the stable branch
* after that, merge the stable branch into master

The latter procedure has advantages over the first one:
* You are always sure that bug fixes exist in both branches, there is
no chance of forgetting something
* You are always sure that the stable branch works properly because
you test the fix in stable and not in master
* Commits are never duplicated in two branches
* git describe actually prints a version number that makes sense

Of course it also has the disadvantage that merges may conflict due to
big changes in master, in which case they must be done with care, but
it's usually not a big deal.

In the KDE SC we have seen many times regressions in stable releases
due to incomplete or insufficiently tested backports. Let's not do the
same mistake.

So, I would like to ask all of you to adopt the forward-porting
workflow. Comments?

Regards,
George


More information about the KDE-Telepathy mailing list