TSP Logo TSP Wiki
Docs
TSP Wiki

    Commits

    Commit Content

    Each commit should only contain changes for a specific ticket.

    If the ticket in question is for a complex feature with many components, your commits should be broken down into logically independent changes.

    DO NOT push a huge commit containing changes for multiple tickets. It makes code review extremely difficult

    Commit Message

    Commits without an issue tracker ticket

    All commit messages should follow this format:

    <short description of changes> 
<more details about the changes>

    With Git CLI it would be

    git commit -m '<short description of changes>'

    Requirements for the short description:

    • Short: keep it under 10 words
    • Imperative form: write your commit message in the imperative: “Fix bug” and not “Fixed bug” or “Fixes bug.”
    • Concise: write only about the changes/fixes/features included in the commit.

    Commits for an issue tracker ticket

    All commit messages should follow this format:

    [<issue tracker ticket ID>] <short description of changes> 
<more details about the changes>

    Commit message should talk about WHAT changed, and WHY. Not HOW – how is the diff, and you don’t need to repeat it

    Example 1: you are fixing a bug for YT-999, related to login for users. The commit message would be:

    [YT-999] Fix bug for user login

All users with role “Officer” were unable to login because of an unhandled case. 

Admins were not affected.

This commit fixes the bug by handling the case where a user has the role “Officer”.

    Example 2: you are fixing a bug for YT-1000, related to filtering. The changes also happen to fix YT-1001. In this case, the commit message would be:

    [YT-1000] [YT-1001] Fix bug for filtering user list by username

Filtering of user list in the admin dashboard was not working because 
the filter function was filtering by userID instead.

Fixed the function to properly filter by username

    Take note that every commit message should have a ticket ID included. Having the ticket ID makes it easier to trace back and find out why a specific change was made.

    If there is no ticket for the changes that you have made, check with your BA/PM or lead developer to see if a ticket should be created

    Make use of smart commits where possible

    Summary

    • ✅ DO include the ticket ID that your commit is intended to resolve
    • ✅ DO include a summary of the changes in the first line
    • ✅ DO include a more detailed explanation for the changes in the commit body
    • ✅ DO break your commits down into logically independent components
    • ✅ DO make use of smart commits
    • ❌ DO NOT use generic commit messages like UI fix
    • ❌ DO NOT combine changes for different tickets into a single commit (unless the exact same change happens to resolve another ticket)

    Learn More

    Edit this page on Gitlab