You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
<p>All projects must define and publish a branching strategy in the project documentation site. See <ahref="#project-documentation">project documentation</a></p>
195
-
</div>
196
-
<p>A Git branching strategy is a set of rules to manage and organize code changes in a Git system. A strategy helps to:</p>
197
-
<ul>
198
-
<li>Prevent conflicts: Avoid merge conflicts that can occur when multiple developers work on the same project at the same time</li>
199
-
<li>Increase productivity: Allow multiple developers to work on different features simultaneously</li>
200
-
<li>Reduce versioning management time: Help teams to manage release of code more efficiently</li>
201
-
</ul>
202
-
<p>There are <ahref="https://graphite.dev/guides/git-branching-strategies" target="_blank" rel="noopener">many Git branching strategies</a> including:</p>
<li>The head of <codeclass="md">main</code> should be git tagged with a semantic version number, indicating the current version of production software.</li>
<p>A release candidate branch will hold code intended for release into production. Quality controls such as automated acceptance tests must succeed before a release candidate is accepted for release into production.</p>
182
+
<p>A release candidate branch will hold code intended for release into production. Quality controls such as automated acceptance tests must succeed before a release candidate is accepted into production.</p>
224
183
<p>We use these branch names for release candidates:</p>
<li>Changes must not be pushed directly to release candidate branches. Use branch protection to prevent developers from pushing.</li>
235
-
<li>Rebased code may be force pushed by Maintainers only when aligning divergent production code (see <ahref="#rebasing">rebasing</a> below). Rebasing a protected branch will require temporary rule changes.</li>
194
+
<li>Rebased code may be force pushed by Maintainers only when aligning divergent production code (see <ahref="../dev-git/#rebasing">rebasing</a>). Rebasing a protected branch will require temporary change of push rules.</li>
<p>A change candidate branch is the most common type of branch, used by developers to iterate their change, before <ahref="../coding-peer-review/">review</a> and merge into a release candidate branch.</p>
239
-
<p>We adopt this convention for change candidate branch names:</p>
240
-
<ul>
241
-
<li><codeclass="md">build</code><br>
242
-
Changes that affect the build system or external dependencies (example scopes: maven, npm).</li>
243
-
<li><codeclass="md">ci</code><br>
244
-
Changes to our CI configuration files and scripts (example scopes: Gitlab-CI, Azure Devops)</li>
245
-
<li><codeclass="md">docs</code><br>
246
-
Documentation only changes</li>
247
-
<li><codeclass="md">feature</code><br>
248
-
A new feature</li>
249
-
<li><codeclass="md">fix</code><br>
250
-
A bug fix</li>
251
-
<li><codeclass="md">perf</code><br>
252
-
A code change that improves performance</li>
253
-
<li><codeclass="md">refactor</code><br>
254
-
A code change that neither fixes a bug nor adds a feature</li>
255
-
<li><codeclass="md">style</code><br>
256
-
Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)</li>
257
-
<li><codeclass="md">test</code><br>
258
-
Adding missing tests or correcting existing tests</li>
259
-
</ul>
260
-
<p>Branch names must follow our <ahref="../coding-naming-conventions/">naming conventions</a> to include change ID and description. e.g. <codeclass="md">feature/LIS-1234-add-back-button</code></p>
<p>Git repository hosting providers provide various features to add additional controls on what can be done. These must be configured to protect the branch and release process.</p>
263
-
<ul>
264
-
<li>Prevent unauthorised push to production and release branches</li>
265
-
<li>Prevent unapproved merge of code into the release process</li>
266
-
<li>Prevent non-compliant commits and branch names</li>
<p>Change candidate branch names follow our <ahref="../coding-naming-conventions/">naming conventions</a> to include change ID and description:</p>
292
199
<ul>
293
-
<li>Branch name regex: <codeclass="md">(main|develop|hotfix)|(build|ci|docs|feature|fix|perf|refactor|style|test)[\-\/]([A-Z]{3,4}|NO-JIRA)</code></li>
<p>Rebasing is a way to tidy up the Git commit history. It involves rewriting commits in various ways:</p>
300
-
<ul>
301
-
<li>Fixing merge conflicts: Rebasing can alter changes in a branch to avoid conflict with changes in another branch.</li>
302
-
<li>Cleaning up project history: Rebasing can create a cleaner project history by combining multiple commits into one.</li>
303
-
<li>Editing commit messages: Rebasing can be used to edit previous commit messages.</li>
304
-
<li>Deleting or reverting commits: Rebasing can be used to delete or revert commits that are no longer necessary</li>
305
-
</ul>
306
-
<divclass="admonition warning">
307
-
<pclass="admonition-title">Proceed with caution</p>
308
-
<p>Rebasing will change the Git commit graph and has potential to create an inconsistent repository that is difficult to recover from. Rebase with caution and consult your professional lead if you are unsure of what you are doing.</p>
309
-
<p>Whenever a shared branch is rebased, the entire team needs to be notified. Every team member will need to reset their local branch to the rewritten remote:</p>
<h3id="rebase-or-merge" tabindex="-1"><aclass="header-anchor" href="#rebase-or-merge">Rebase or merge</a></h3>
315
-
<p>We recommend that project teams rebase their branches against the upstream branch whenever they diverge. This provides a more streamlined and understandable git history, and simplifies squashing.</p>
316
-
<p>Merging from an upstream branch on the other hand makes squashing and reverting change more difficult.</p>
<p>We recommend that developers squash commits into logical commits for change candidate branches prior to merge into a release candidate branch. This removes unneccesary commits that can confuse and provides a clean and logical git history.</p>
<li>must import into an empty repository in the Git hosting provider. Merging a repository into a pre-existing <codeclass="md">main</code> will cause confusion in the git history</li>
327
211
</ul>
328
212
</li>
329
-
<li><ahref="#controls">Controls</a> must be applied as above</li>
<li>Developer creates a new change candidate branch, <codeclass="md">feature-xyz</code> branch from the newly created <codeclass="md">develop-xyz</code> branch</li>
344
227
<li>When the feature changes are complete they raise a merge request for <ahref="../coding-peer-review/">review</a></li>
345
-
<li>The changes are merged (ideally <ahref="#squashing">commits squashed</a>) in to the <codeclass="md">develop</code> branch. The change candidate branch should be deleted</li>
346
-
<li>The <em>change</em> -> <em>release</em> cycle is repeated until all the changes relating the release are stable and tested</li>
<p>All projects must document their git branching and release strategy. Deviation from standards must also be documented along with decision records explaining the reason for deviation.</p>
350
-
<p>Documentation should define:</p>
351
-
<ul>
352
-
<li>Root git branching strategy. e.g. nhsbsa, git-flow, github-flow, trunk-based-development, other</li>
353
-
<li>Branch naming convention</li>
354
-
<li>Rebasing approach including rebase vs merge commits, and squashing</li>
355
-
<li>Branch protection</li>
356
-
<li>Approval rules</li>
228
+
<li>The changes are merged (ideally <ahref="../dev-git/#squashing">commits squashed</a>) in to the <codeclass="md">develop</code> branch. The change candidate branch should be deleted</li>
229
+
<li>The <em>change</em> -> <em>release</em> cycle is repeated until all the changes relating to the release are stable and tested</li>
357
230
</ul>
358
231
359
232
<hr>
@@ -379,7 +252,7 @@ <h2 class="nhsuk-heading-l header-anchor" id="improve-the-playbook">Improve the
0 commit comments