Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add commit standards #14

Open
wants to merge 4 commits into
base: main
Choose a base branch
from
+41 −0
Open

Add commit standards #14

Changes from 2 commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
de7adfc
Add commit standards
lindenmckenzie Jan 30, 2025
9dee812
Clarify commit standard
lindenmckenzie Feb 4, 2025
8362ffa
Add squashing examples
lindenmckenzie Feb 6, 2025
ced85d0
Remove squash merge flow
lindenmckenzie Feb 10, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
31 changes: 31 additions & 0 deletions COMMIT_STANDARDS.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,31 @@
# Commit standards

We follow the [GDS Way styleguide](https://gds-way.digital.cabinet-office.gov.uk/standards/source-code/working-with-git.html#commits) for our commit standards.

This means that each commit:

- is self-contained
- only includes changes that achieve a specific step
- should be in a logical order

## Commit messages

Writing good commit messages is important. Not just for yourself, but for other developers on your project. This includes:

- new (or recently absent) developers who want to get up to speed on progress
- interested external parties who want to follow progress of the project
- people in the public (remember, we code in the open) who want to see our work, or learn from our practices
- any future developers (including yourself) who want to see why a change was made

A good commit message should:

- summarise the "what", providing a concise, scan-friendly headline that captures the essence of the change.
- explain the "why" by including details in the message body that clarify the motivation behind the change. While the code diff shows what changed, the reasoning often isn't apparent.
- follow a consistent format by using the imperative mood (e.g. "Add", "Fix", "Update") to give a clear, action-oriented description.

## Merging and squashing

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would it also be useful to add a command line example of how this should be done here?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is that on how to commit? or how to squash? or how to squash merge?

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The squash and squash merge

When working on a feature branch, it's common for your branch to become outdated relative to its parent. We prefer to update your branch by rebasing rather than merging. Rebasing offers a cleaner, linear history on the parent branch, which is easier to follow. However:

- Coordinate with Reviewers/Team: Rebasing during an active code review can complicate the review process. Always check with your reviewer/team style guide before rebasing or tidying up commit histories.
- Use Squashing Judiciously: Squash commits when it makes sense to consolidate minor, related changes into one atomic commit. Just ensure that you retain enough detail in the commit message to explain the consolidated changes.