From 1a5ae2ab72b7966faae81ec70fadbdef91ee7adf Mon Sep 17 00:00:00 2001 From: adeleroi Date: Sun, 1 Mar 2026 01:02:30 -0500 Subject: [PATCH] docs(engineering-practices): Correct minor grammar issues in commit message guidelines Fix minor grammatical issues and improve clarity in the commit message guidelines documentation. No structural or behavioral changes. --- develop-docs/engineering-practices/commit-messages.mdx | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/develop-docs/engineering-practices/commit-messages.mdx b/develop-docs/engineering-practices/commit-messages.mdx index d5ce8ff12c809b..806994a78e1be6 100644 --- a/develop-docs/engineering-practices/commit-messages.mdx +++ b/develop-docs/engineering-practices/commit-messages.mdx @@ -16,13 +16,13 @@ sidebar_order: 10 ### Merge vs Rebase -Sentry uses a rebase workflow. That means that every commit on its own should be a clear, functional, and stable change. This means then when you’re building a new feature, you should try to pare it down into functional steps, and when that’s not reasonable, the end patch should be a single commit. This is counter to having a Pull Request which may include “fix [unmerged] behavior”. Those commits should be squashed, and the final patch when landed should be rebased. +Sentry uses a rebase workflow. That means that every commit on its own should be a clear, functional, and stable change. This means that when you’re building a new feature, you should try to pare it down into functional steps, and when that’s not reasonable, the end patch should be a single commit. This is counter to having a Pull Request which may include “fix [unmerged] behavior”. Those commits should be squashed, and the final patch when landed should be rebased. Remember: each commit should follow the commit message format and be stable (green build). #### Rebase and Merge -The GitHub UI exposes a “Rebase and Merge” option, which, if your commits are already in following the commit guidelines, is a great way to bring your change into the codebase. +The GitHub UI exposes a “Rebase and Merge” option, which, if your commits already follow the commit guidelines, is a great way to bring your change into the codebase. #### Squashing @@ -46,7 +46,7 @@ The header has a special format that includes a type, a scope and a subject: The **header** is mandatory and the **scope** of the header is optional. If you have a Jira issue to link to, add the **jira-id** the commit belongs to. This helps to connect changes back to Jira tickets. -Any line of the commit message should not be longer 100 characters! This allows the message to be easier to read on GitHub as well as in various git tools. +Any line of the commit message should not be longer than 100 characters! This allows the message to be easier to read on GitHub as well as in various git tools. The footer should contain a closing reference to an issue as well as a relevant Sentry issue if any.