Branching Workflows

A plain git push sends branch refs only; tags live in refs/tags and are excluded by the default refspec. Push one explicitly with git push origin v1.4.0, or push a branch plus its reachable annotated tags with git push --follow-tags.

Trunk-based development means everyone integrates into one shared branch — the trunk, usually main — continuously. Branches off it are short-lived, typically merged back within a day or two, so the repository never accumulates long-running parallel lines of development.

git format-patch writes one mbox-formatted file per commit, containing the message plus the diff and author metadata. A maintainer replays them with git am, which recreates the commits with their original author, date and message rather than just applying a diff.

Make each commit one self-contained step that builds and passes tests on its own: preparation and refactoring first, behaviour change second, then tests and docs. Order them so a reviewer reading top to bottom sees the change being argued, not assembled.

GitHub Flow keeps one long-lived branch: topic branches start from main and merge straight back, so a change integrates once. Git Flow adds develop as a second integration point, so work merges at least twice before it reaches main.

An annotated tag creates a real tag object storing a tagger name, email, date, message and optional signature, and can be verified. A lightweight tag is just a ref file pointing at a commit, carrying no metadata of its own.

Propagate it deliberately: merge the release branch into main, or replay the commit with git cherry-pick -x. Skip it and the next release cut from main ships without the fix, so the bug returns as a regression nobody expects.

The -s flag appends a Signed-off-by trailer carrying your configured name and email. Projects governed by the Developer Certificate of Origin read that line as your certification that you have the right to submit the code under the project's licence.

Environment branches are long-lived Git branches named for deploy targets, such as staging and production, whose tips represent what each environment runs. Changes always land on main first and are then merged downstream, never committed directly to an environment branch.

It names the nearest reachable tag (v1.4.0), the number of commits since it (14), and the abbreviated commit id prefixed by g for git (2414721). By default it searches annotated tags only, so a repository without one cannot be described.

You make the incomplete code inert rather than keeping it on a branch: merge it switched off behind a flag, or introduce it behind an abstraction that still routes to the old implementation. The trunk stays releasable because the new path is never taken.

Fetch directly from the contributor's repository URL and branch, which lands in FETCH_HEAD, review and test it on a local topic branch, then merge it into your integration branch — typically with a no-fast-forward merge so the contribution stays visible as a unit.

Rebase your topic branch onto the current upstream tip, re-run the tests, then regenerate the series with git format-patch using a bumped version prefix and a range-diff against the previous round, and reply in the same mail thread.

A single long-lived main with short topic branches, GitHub Flow style. At that cadence a develop branch is never meaningfully ahead of main, so it adds a second merge and a second place for fixes to be missing without buying any stabilization window.

Commit the fix on the oldest affected line, release/1.4, then merge forward: 1.4 into 1.5, 1.5 into main. Each merge makes the fix reachable, so git branch --contains proves coverage instead of you having to trust three independent cherry-picks.

Because the branch was verified against its own commits on an older base, not against the merged result. Changes that landed on main since the branch's merge base are never combined with it until the merge happens, so a clean textual merge can still be logically broken.

Converge the two lines first: ship or merge everything on develop into main so nothing is stranded, re-point in-flight branches onto main, then delete develop locally and on the remote and update every ref, hook and upstream that named it.

As few as the support promise requires — each extra live line multiplies every fix by another merge or cherry-pick, retest and tag. Bound the cost with a published end-of-life date, strictly ordered merge-up, and no refactoring on maintenance lines.

Automated verification the team actually trusts on every merge, changes that can be split into small independently-shippable pieces, a way to keep unfinished work inert on the trunk, and a release model that does not require several shipped versions to be maintained in parallel.