Skip to main content

Commit, comment and PR naming

PR; Pull-Request​

PR Title​

<Prefix>: [ID] <ticket number> <full title of the ticket>

Pull request title should be meaningful. It can have the same as the ticket's title. For example, <Prefix> could be same as the branch prefix. But it is started with capital word.

  • Feature: 1234 remove the logo in the Compare page
  • Bugfix: 1234 fix the logo

PR Comments​

  • Normal Text: explain your suggestion with codelet as possible you can. ask politely.
  • nit: to let the author know that it's just a point of polish that they could choose to ignore i.e. the reviewer is suggesting a change, but the PR owner can choose to ignore.
  • fyi: to let the author know that the comment is only informational for their knowledge. There is no suggestion from the reviewer that a change needs to be made.

Git Commit Messages​

Git is software for tracking changes and versioning any set of files, usually used for coordinating work among programmers collaboratively developing source code during software development.

The original purpose for Git commit messages is to add human-readable messages to commits, which assist humans to make an understanding of the changes related to the commits.

Due to Git commit messages only being attached to the commit rather than the commit message shaping part of the commit itself, a commit is unaware of its commit message.

<type>(<scope>): <subject>

commit type​

  • build: Build related changes (change or add external dependencies)
  • chore: A code change that external user won't see (eg: change to .gitignore or .prettierrc)
  • feat: A new feature
  • fix: A bug fix
  • docs: Documentation related changes
  • refactor: A code change that neither fixes a bug nor adds a feature (You can use this when there are semantic changes like renaming)
  • perf: A code change that improves performance
  • style: A code change that is related to styling
  • test: Adding a new test or making changes to an existing test
  • <type>!: For bringing attention to a breaking change
  • revert: reverted commit

scope (optional)​

  • The scope must be a noun and it represents the section of the codebase

subject​

  • use imperative, present tense (eg: use "add" instead of "added" or "adds")
  • don't use dot(.) at the end
  • don't capitalize the first letter

Examples​

simple expression​

fix(backend): ensure the SignIn with AppVersion in the validateData 
fix(config): change the URLs 
test: add Quote UI clicking tests 
refactor!: drop support Caligraphy library

With description

refactor!: drop support Caligraphy library  

BRAKING CHANGE: refactor to use native Google Font features instead of 3rd party

Comments (in the code)​

// <type>: <subject>

type​

  • TODO: A small task that needs to be done (non-urgent, something will be changed eventually)
  • FIXME: An urgent problem that needs to be fixed (none of these should exist when pushing to prod)
  • WARN: A warning that the current code could potentially cause an issue (should be looked at when convenient)

Examples​

A small task​

// TODO: Refactor this code for more clarity

An urgent issue​

// FIXME: This does not take the user to the right page

A warning​

// WARN: No error handling, if an error happens we will have no way of knowing