Git

These are the guidelines for working with Git in the District Core framework.

Commit messages

Firstly, assume that your commit messages will end up in a changelog, so take care to write them in a way that is clear, concise and descriptive.

Conventional commits

Git messages should folow the Conventional Commits specification. This is to ensure that the commit messages are clear and can be used to generate changelogs. This is enforced by a git hook commit-msg that lives in /hooks and is symlinked to .git/hooks/commit-msg on composer install.

Examples of valid commit messages:

chore: Upgraded to Laravel 11
feat: Added new module for custom functionality
fix: Fixed issue with user login
docs: Updated README
style: Fixed formatting
refactor: Removed unused code
test: Added new test

JIRA ticket numbers in commit messages

Where possible, include the JIRA ticket number in the commit message. This is not a requirement but is helpful for tracking changes.

Branches

Branches should always contain the JIRA ticket number followed by a short description of the branch. For example:

feature/DISTCORE-123-new-module

Like commit messages, assume that the branch name may end up in a changelog.

Squashing, amending and cleanup

Sometimes it is unavoidable to have a number of commit messages relating to fixing a single issue. In these cases, it is recommended to squash the commits into a single commit before merging the branch. This can be done with the following

git rebase -i HEAD~n

Where n is the number of commits you want to squash. This will open an editor where you can choose which commits to squash.

If you have already pushed the branch to the remote, you will need to force push the branch after squashing.

If fixes relate to the same issue, it is recommended to use --amend to add to the last commit message. This can be done with the following

git commit --amend