-
Notifications
You must be signed in to change notification settings - Fork 69
A Commit Style Guide
Mithi Sevilla edited this page Jul 2, 2020
·
6 revisions
These prefixes for commits is a work in progress. Suggestions are welcome.
-
api-breaking / change-behavior
- Rename public functions
- Change parameters of class constructors, methods functions
- Change return type of existing functions
- Change functionality of existing function
- Remove existing properties of objects
-
major-feat a large feature that's user facing
- functional: Add new functionality for the app
-
minor-feat a small enhancement
- functional: Add Small changes in functionality, new small utility functions
-
style / page-design
- Apply changes in how the page looks, UI, css, etc
-
prettier / format
- Fix formatting for consistency, add missing semi colons, etc
- Add comments within functions (not module or function docstring)
-
refactor (of production code) Recommended to use these verbs:
- Remove unused code
- Rename private variables, private functions and methods
- Move functions to own module
- Rearrange relative positions of functions or blocks of code within the same file
- Extract method move some code from a large function to a helper function
- Reduce cognitive complexity of blocks of codes
- Reimplement the same thing, but function is now is more readable ( not necessarily faster)
- Remove duplication, be dry
- See also: https://sourcemaking.com/refactoring/refactorings
-
optimize (small, medium, large)
- Remove redundancy or unnecessary calculations
- Apply modifications that improve speed of the app
-
fix a bug fix
- Fix something that is not working as expected
-
test
- Tests, refactored tests, no production code change
-
docs
- Change in documentation or README
- Write / Update docstrings or descriptions of modules, classes, functions, or methods
-
chore updating build tasks, package manager configs, etc; no production code change
Consider starting the commit message with an applicable emoji: (taken from Atom contribution guide!)
- π¨ π¨ when improving the format/structure of the code
- π π when improving performance
- π π when writing docs
- π π when fixing a bug
- π₯ π₯ when removing code or files
- β β when adding tests
- Should be no greater than 50 characters
- Should begin with a capital letter
- Should not end with a period
- Use an imperative tone to describe what a commit does, rather than what it did For example, use change; not changed or changes.
feat: Summarize changes in around 50 characters or less
Only add a body if necessary. Explain the problem that this commit is solving.
Focus on why you are making this change as opposed to how (the code explains that).
Write side effects or other unintuitive consequences of this change if any.
- Bullet points are okay, too
- A hyphen or asterisk is used for the bullet
Resolves: #123
See also: #456, #789
If you like this project, consider:
- Buying Mithi a coffee β β β
- Submitting a PR. What kind?
- Sharing this project to all your friends. Thanks! β€οΈ