git workflow

From F-Droid
Revision as of 23:17, 8 August 2015 by Pserwylo (Talk | contribs) (Release management)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Release management

Release branches

Wiki article about master/stable-* branches.

A --- B --- C
            |
            + master

At commit C, we decide that it is stable and ready for the release process to begin for the upcoming version 0.1:

A --- B --- C
            |
            + master, stable-0.1

In the mean time, developers can continue on merging features into the master branch while the 0.1 version gets tested in preperation for a proper release:

A --- B --- C --- D --- E --- F
            |                 |
            + stable-0.1      + master

After releasing 0.1-alpha, somebody reports a bug in it (which is not in the previous version).

To fix the bug, they branch from stable-0.1 and call their branch hotfix/issue-1001 and add a few commits which fix the bug:

              Fix_a --- Fix_b --- Fix_c
             /                      |
A --- B --- C --- D --- E --- F     + hotfix/issue-1001
            |                 |
            + stable-0.1      + master

One completed, they submit a PR against the stable-0.1 branch.

Once this is accepted, gitlab will create a merge commit (D) and we end up with a history that looks like so:

                Fix_a --- Fix_b --- Fix_c
               /                         \
              /---------------------------M_1 ("merge hotfix/issue-1001 into stable-0.1")
             /                            |
A --- B --- C --- D --- E --- F           + stable-0.1
                              |
                              + master

This can happen several times, depending on how many bugs are identified that require fixing in the stable-0.1 branch during the testing period.

At some point, the 0.1 release is marked as ready, built and released, and any changes need to be folded back into the master branch:

                Fix_a --- Fix_b --- Fix_c
               /                         \
              /---------------------------M_1 ("merge hotfix/issue-1001 into stable-0.1")
             /                             \
A --- B --- C --- D --- E --- F ----------- M_2
                                             |
                                             + master

Alternatively, at the point that the changes in the hotfix/issue-101 branch were merged into stable-0.1, they could have also been merged into the master branch. This way, people who are actively building new features for the "sometime-in-the-future-0.2 release" are still able to develop without the bug that was identified during the testing period of the 0.1 release.

Hotfixes during releases

When I started thinking about this, I saw four seemingly reasonable ways in which to get hotfixes into a release branch, and then subsequently into master. These scenarios all presume there is a master branch (which has commits not in stable-*), stable-* (which has commits relating to release metadata, version numbering, etc), and hotfix (contains a fix that needs to be included in the stable-* branch, and one day will also need to end up in master).

  • Merge hotfix into stable-*, then wait for stable-* to be eventually merged into master to include the hotfix commits in master.
  • Merge hotfix into master, then cherry-pick commits from hotfix into stable-*.
  • Merge hotfix into master, and also merge hotfix into stable-*.
  • Cherry-pick commits from hotfix into master, and also cherry-pick commits from hotfix into stable-*.

Here is a summary of the pros and cons of each. I (pserwylo) have put them in order of my personal preference. I believe the first one is preferable. The main downside is that the hotfix branch must correctly be rebased on top of the stable-* release branch before merging, to ensure it doesn't contain unwanted commits from master. The other downside is that changes are not available in master immediately. However, if they are really really required in master in a short frame, then they can be cherry-picked or merged into master. Git has many ways to solve problems, and in certain circumstances, I have no issue with people making an exception to the currently adopted workflow in order to solve a problem at hand - such as requiring a hotfix in master before a release is released).

Merge into stable, and wait for stable-* to be merged into master

Checklist:

  • Similar to the usual MR based workflow? YES (exactly the same)
  • Changes get into master and stable-* immediately? NO
  • How are changes reverted? REVERT SINGLE MERGE COMMIT
  • Hotfix commits only appear once in history YES
  • Can mostly not worry about where code was branched from (if branched from an advanced master, it wont result in unwanted commits merged into stable-*)? NO

merge-to-release.png

Merge into master, cherry-pick into stable-*

Checklist:

  • Similar to the usual MR based workflow? YES
  • Changes get into master and stable-* immediately? YES
  • How are changes reverted? REVERT A MERGE AND ARBITRARY COMMITS FROM CHERRY-PICK?
  • Hotfix commits only appear once in history NO
  • Can mostly not worry about where code was branched from (if branched from an advanced master, it wont result in unwanted commits merged into stable-*)? YES

merge-to-master.cherry-pick-to-release.png

Merge into master, and merge into stable-*

Checklist:

  • Similar to the usual MR based workflow? YES
  • Changes get into master and stable-* immediately? YES
  • How are changes reverted? REVERT TWO SEPARATE MERGE COMMITS
  • Hotfix commits only appear once in history YES
  • Can mostly not worry about where code was branched from (if branched from an advanced master, it wont result in unwanted commits merged into stable-*)? NO

merge-to-master.merge-to-release.png

Cherry-pick into master, and cherry-pick into stable-*

Checklist:

  • Similar to the usual MR based workflow? NO
  • Changes get into master and stable-* immediately? YES
  • How are changes reverted? REVERT ARBITRARY CHERRY-PICK COMMITS... TWICE?
  • Hotfix commits only appear once in history NO
  • Can mostly not worry about where code was branched from (if branched from an advanced master, it wont result in unwanted commits merged into stable-*)? YES

cherry-pick-to-master.cherry-pick-to-release.png