Use environment-specific URLs instead of

...hard-coded ones
This commit is contained in:
Oliver Davies 2024-09-03 00:34:58 +01:00
parent 6ca5704c21
commit 1b05e63a20
76 changed files with 91 additions and 91 deletions

View file

@ -8,7 +8,7 @@ tags:
- git
---
An important thing when using a tool like [git bisect](https://www.oliverdavies.uk/archive/2023/01/23/debugging-with-git-bisect) as well as reviewing pull/merge requests and commits is to have small (aka "atomic") commits.
An important thing when using a tool like [git bisect]({{site.url}}/archive/2023/01/23/debugging-with-git-bisect) as well as reviewing pull/merge requests and commits is to have small (aka "atomic") commits.
Commits with small changes make them easier to review and, if needed, to revert and debug with bisect. If a commit has ten new or changed lines, it's much easier to see and fix a bug than if the commit had a hundred lines.
@ -20,4 +20,4 @@ Also take some time to write good, informative commit messages.
As well as the short one-line subject, you can add as much detail as you need to the body of the message about the change that's being committed, why it's needed, what other approaches were considered or tried, as well as links to supporting documentation such as ADRs, technical design documents or diagrams.
Having as much information as possible makes it much easier when someone needs to review or fix a specific commit. I like to use the [conventional commits specification](https://www.oliverdavies.uk/archive/2022/09/01/conventional-commits-changelogs), though the main objective is to have all of the information documented so it's available in the future.
Having as much information as possible makes it much easier when someone needs to review or fix a specific commit. I like to use the [conventional commits specification]({{site.url}}/archive/2022/09/01/conventional-commits-changelogs), though the main objective is to have all of the information documented so it's available in the future.