Committing ​

Formatting ​

Here are a few conventions.

• Capitalize the first word as commit messages are sentences.
• Start commit messages with verbs to indicate activity. Present tense is required.
• For clarity, commit messages should be as long as Commit messages should be as informative as possible, hence there is no character restriction.
• Periods only work in multi-sentence commit messages.
• Don't use colons—they're verbose and violate the sentence concept.
• Emoji is permitted

Message Structure ​

Standard ​

Incomplete feature commits must end with wip e.g.,

git commit -c "You commit message.. wip"

Skip CI ​

If the build is likely to fail, skip it to save CI/CD resources. Adding [skip ci] to the commit message structure does that. Such as:

git commit -c "[skip ci] As a user I can view the list of job positions"

When to skip the pipeline ​

• When a pull request is marked as a draft pull request. Triggering builds is now unnecessary since more commits may be added later.
• When a pull request uses a branch else than main release dev branchs
• When a pull request to a dev branch requires updating before merging. When many branches are ready for review and based on the dev branch. Merge pull requests by approval date. Pipelines are unnecessary until the pull request is ready to merge.

Best Practices ​

• Clear, meaningful commit messages. Imagine seeing this commit message in a year's time then. What would you encourage your future self or developer?
• Do not write commit messages like "Resolve feedback" or "Fix all comments" when receiving reviewer criticism. Instead, create meaningful commit statements.
• Commit changes for a group of files with a suitable commit message. Staged files must match the change. If the commit message contains "and," it may need to be split into multiple commits.
• Commit often to avoid missing a lot of changes when working on a big assignment.