Git Standards - Syntax-Meridian/TesseractCMS GitHub Wiki

Git Branching and Commit Style Guidelines

Main Branch Protection

The main branch should always be deployable. It may only be updated via pull requests. (That means you, Justin!)

Feature Branching

Create a new branch for every new feature or task. Name it descriptively and include the Jira ticket # if applicable, e.g., feature/CMS-4_user-authentication.

Tip: Jira offers a way to create branches from stories and defects automatically if you click through to the details of a story card.

image

Commit Atomicity

Each commit should ideally represent a single logical change. Avoid bundling unrelated changes when possible. Commit early, commit often!

Descriptive Commit Messages

Write clear and meaningful commit messages. Start with the issue # in brackets, then a short summary (under 50 characters).

Optionally, you may follow with a longer description two lines after.

Also optionally, You can add comments to a Jira issue using special syntax, as well. If you use this special syntax, they should be the last lines of the commit message.

Example:

[CMS-4] Fix Playwright tests & add draft of admin page
    
Added a draft of the admin page that can be used for Playwright testing. Also updated the Playwright tests to work with the new page.

[CMS-4] #comment Tests fixed, pending documentation update.

Use Present Tense and Imperative Mood

Commit messages should be in the present tense and imperative mood.

  • Bad: "Fixed names not displaying" or "Fixing names not displaying"
  • Good: "Fix names not displaying"

Issue Tracking Integration

If using an issue tracker, reference issue numbers in your commits.

Avoid Long-lived Branches

Branches should be short-lived to avoid complicated merges. Regularly rebase or merge from the main branch.

Sign Your Commits (Recommended)

Use GPG to sign your commits, ensuring the authenticity and integrity of your work. Not strictly necessary but good practice and helpful when engaging on any high security projects.

Review Before Merging

Always conduct code reviews before merging branches. Create a pull request (PR) for any changes you want to make to the main branch.