Feature branches

GitFlow is a convention about branch names and where work is merged. Innesta runs the parts of it that have a lifecycle: features, releases and hotfixes.

Setting it up

GitFlow is configured per repository. Initialising it stores your production and integration branches — by default main and develop — writes the standard feature/, release/, hotfix/ and support/ prefixes, and creates the integration branch if it does not exist yet.

The settings live in the repository’s own Git config. A repository that already has GitFlow configured — by another tool, or by hand — is detected rather than reconfigured.

support/ is stored for compatibility with the convention. Innesta has no dedicated workflow for it.

Where the actions are

GitFlow in the toolbar opens a popover. Its top half is Start Branch: a Feature / Release / Hotfix picker, a field for the name, and one Start button that does whichever of the three is picked. Its bottom half appears only once you are on a flow branch, and carries what can be done to that branch.

Each of them then asks to be confirmed, and it is the confirmation that spells the action out in full — Start Feature, Publish Feature, Pull Feature.

Where a branch starts

Every Start confirmation carries a Starting Point picker, and names the branch it will cut from in its own question. First in the list, marked as the default, is the configured branch — integration for a feature or a release, production for a hotfix — and under it the repository’s other local branches, in name order.

Choosing another one changes only the commit the new branch starts at, and the sheet warns that you have left the configured branch. Version suggestions, the manifest, the collision checks and the branches a finish merges into all go on using the configured pair.

A feature, start to finish

Start Feature creates feature/<name> from the integration branch — or from the Starting Point you chose — and switches to it.

Publish pushes it with -u, so it has an upstream and the pull and push buttons can count.

Pull fetches and brings in the remote copy of the current feature, through the same safe pull path as anything else.

The finish button is named for the branch you are on — Finish Feature — and it switches to the integration branch, merges the feature with --no-ff, and then tries to delete the local feature branch.

--no-ff is deliberate: it makes a merge commit even when a fast-forward would have been possible, so the integration branch’s history records that a feature existed. Without it, a feature merged the day it was branched vanishes into the line.

What blocks a finish

Finishing validates first, and refuses when:

• a merge is in progress;
• there are conflicts;
• there are changes to tracked files;
• there are commits you have not pushed.

Untracked files do not block it. And the validation checks the state of the repository — it does not simulate the merge, so a finish that passes validation can still conflict.

The status header

The GitFlow section says whether the repository is configured, which branches are the production and integration pair, which branch you are on, and — when it is a flow branch — whether it is a feature, a release or a hotfix.