Releases

Cutting a release branch, and what finishing one does to production, the tag and integration.

A release branch is where a version settles: no new features, only what it takes to ship.

Starting one

Innesta suggests the next version — see versioning — and then checks that the release branch and its tag do not already exist, first locally and then, when it can reach it, on the push remote.

The two checks are treated differently, because they are different problems:

  • A local collision blocks. The branch or tag is already here; creating it again is not a thing that can happen.
  • A remote-only collision warns. Someone else may have started the same release, or a tag may exist that you have not fetched. You can accept it and create the local branch anyway, because the situation is sometimes exactly what you meant.

Start Release — the confirmation behind Start in the GitFlow popover, with Release picked — opens straight away. Its Tag row reads Checking the remote… until the remote answers, and the question above it is rewritten if either check finds the version taken. Confirming creates the branch from the integration branch, or from the Starting Point you chose, and switches to it.

Finishing one

Finish Release runs the same validation as a feature, rechecks the collisions, and then does four things in order:

  1. Optionally updates the version in your project’s manifest — see versioning.
  2. Merges the release into production with --no-ff.
  3. Creates an annotated tag for the version.
  4. Merges into the integration branch with --no-ff, so that anything fixed during the release is not lost from the line development continues on.

Then it tries to delete the local release branch.

What the confirmation asks

The sheet opens straight away, on what Innesta can work out from the repository alone, and the rest arrives underneath — the same as Start Release. It names the Tag the version would get and, when versioning is on and a file was found, the Version file it would rewrite. Verification reads Checking the remote… until the push remote answers, and Finish GitFlow stays unavailable until it has: the answer can change what is being proposed.

If the version is free, that is the whole sheet. If the tag is taken the row reads Existing tag instead, and what you are offered depends on where it is taken:

  • Locally, with versioning on. Innesta works out the next free version and offers it — a New tag row, a Branch row reading the rename it would make, release/1.5.0 → release/1.6.0, and the checkbox Use these values to finish. Nothing is renamed until you tick it.
  • Only on the remote. The name is still free here, so the checkbox reads Finish and create the local tag anyway.
  • Locally, with versioning off. There is no next version to offer, so the sheet says so and Finish GitFlow stays unavailable. Change the branch’s version yourself and come back.

Tick a box and then let the remote change the proposal, and the tick clears: agreeing to one set of values is not agreeing to another.

Why the back-merge matters

Step 4 is the one people forget when they do this by hand. Fixes made on the release branch exist only on production until integration gets them, and the next feature branched from integration reintroduces the bug. GitFlow’s answer is to merge both ways, and Innesta does both.