The stability step is a branch, not a pipeline: inside one team's release-candidate discipline

A developer writing on dev.to has published the Git methodology he says he developed while managing software development, and its load-bearing claim is unfashionable: stable releases come from where you stabilise code, not from how much you automate ^[1]. The process assumes CI/CD but states plainly that a lack of automation does not prevent adoption ^[2], while making two other things non-negotiable: a release-candidate branch that is tested before it merges to master, and an issue tracker that mints short readable IDs ^[1].

The shape is ordinary feature-branch work. master is always stable, there is one branch per task, and releases are tags cut from master using SemVer names ^[3]. What differs is that task branches never reach master directly. Changes bound for a release live in a release-candidate branch named rc-*, the worked example being rc-v1.5.24, created from an up-to-date master and put through a stabilisation phase before it merges ^[4][5]. Code review still happens in a merge request opened from the task branch into master, but each of those MRs is closed automatically when the RC merges ^[6]. The review target and the merge path are deliberately different objects.

Admission to a release has three gates: the task's MR has passed review, it has no conflicts with master, and the task's changes have been tested ^[7]. The version number falls out of the task list plus SemVer, and creating a release entity in the tracker is optional but is presented as improving the link between tracker and Git ^[8].

Then comes the requirement that decides whether a given team can adopt this at all. Because branch names carry issue identifiers, the tracker has to generate a short, human-readable unique ID automatically ^[9]. Jira and YouTrack do that out of the box, and the Issues features in GitHub, GitLab or Gitea work using either the local or global identifier, for example 42 or acme/service#42 ^[10]. Trello, Asana and Notion, the author writes, probably will not fit, because they do not produce a readable unique ID ^[11]. That is a tooling veto written into the process, not a taste preference.

On testing the author allows latitude everywhere except one place: testing the release branch cannot be skipped, because that is the step that stabilises what will reach master and then production ^[12]. Testing a task in isolation, or using a shared test environment, is offered as an option ^[13]. The recommended pipelines are modest by current standards: builds of fixed environments from their branches, an on-demand environment for an individual task, and static analysis plus automated tests in task MRs ^[14].

The claimed payoff is operational rather than aesthetic. According to the author, a clear link between Git history, build artifacts and production instance tags simplifies incident management ^[15], and the history graph gives an overview of the state of development or the cost of a project without time tracking ^[16]. There is one escape hatch: under a "green trunk" practice, shared code that does not affect users can go straight into master, bypassing the release cycle, treated as an exception requiring extra control ^[17].

Worth watching, if you try this. The account is experiential, drawn from cross-functional, product-based and outsourcing teams of three to twenty people ^[18], and the material carries no defect-rate or lead-time figures to compare against trunk-based alternatives ^[2]. The pressure points are obvious from the design: the stabilisation window becomes the queue every task waits in, the green-trunk exception is the thing that will quietly widen, and the auto-closing MR behaviour ^[6] is the part most likely to depend on which forge you run.