styleguide-git-commit-message

/sBin/StyleGuide/Git/CommitMessage

1,008

View on GitHub

Top Related Projects

cz-cli

16,701

The commitizen command line utility. #BlackLivesMatter

angular

95,657

Deliver web apps with confidence 🚀

git-commit-message

1,178

Git commit message: how to write a great git commit message and commit template for version control

Quick Overview

The slashsbin/styleguide-git-commit-message repository is a comprehensive guide for writing clear and consistent Git commit messages. It provides a set of rules and best practices to help developers create more meaningful and informative commit histories, improving project collaboration and maintainability.

Pros

Offers a structured approach to writing commit messages, enhancing readability and consistency
Includes examples and explanations for various types of commits, making it easy to understand and implement
Provides guidelines for both the subject line and body of commit messages, ensuring thorough documentation
Encourages better project management and easier code review processes

Cons

May be perceived as overly strict or time-consuming for some developers
Requires team-wide adoption and enforcement to be truly effective
Some guidelines may not fit all project types or team preferences
Can be challenging to implement in projects with existing inconsistent commit histories

Getting Started

To implement this Git commit message style guide in your project:

Copy the contents of the README.md file from the repository.
Create a CONTRIBUTING.md file in your project's root directory.
Paste the copied content into the CONTRIBUTING.md file.
Customize the guidelines as needed for your project.
Share the guidelines with your team and encourage adoption.

Example of a well-formatted commit message following these guidelines:

feat(auth): implement OAuth2 authentication

- Add OAuth2 client library
- Create authentication middleware
- Update user model to include OAuth2 tokens

Closes #123

Competitor Comparisons

commitlint

16,617

📓 Lint commit messages

Pros of commitlint

Automated enforcement of commit message conventions
Customizable rules and configurations
Integration with popular development tools and CI/CD pipelines

Cons of commitlint

Steeper learning curve for new users
Requires additional setup and configuration
May be overly strict for some projects or teams

Code comparison

styleguide-git-commit-message:

<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>

commitlint:

module.exports = {
  extends: ['@commitlint/config-conventional'],
  rules: {
    'type-enum': [2, 'always', ['feat', 'fix', 'docs', 'style', 'refactor', 'test', 'chore']],
  },
};

Summary

styleguide-git-commit-message provides a comprehensive guide for writing commit messages, offering a structured format and best practices. It's a static resource that developers can reference.

commitlint, on the other hand, is an active tool that enforces commit message conventions through automated checks. It offers more flexibility and customization but requires additional setup and integration into the development workflow.

While styleguide-git-commit-message is more accessible for quick reference, commitlint provides stronger enforcement and consistency across a project or team. The choice between them depends on the project's needs, team size, and desired level of automation in the commit process.

cz-cli

16,701

The commitizen command line utility. #BlackLivesMatter

Pros of cz-cli

Interactive CLI tool that guides users through commit message creation
Customizable prompts and commit message formats
Integrates with popular commit message conventions (e.g., Angular)

Cons of cz-cli

Requires installation and setup, which may be overkill for small projects
Learning curve for team members unfamiliar with the tool
Dependency on external package for commit message creation

Code comparison

styleguide-git-commit-message:

<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>

cz-cli (example usage):

const commitizen = require('commitizen');
commitizen.prompt({
  // Custom configuration options
}).then((answers) => {
  // Generate commit message based on answers
});

Summary

styleguide-git-commit-message provides a static guide for writing commit messages, while cz-cli offers an interactive tool to generate structured commit messages. cz-cli is more feature-rich but requires setup, whereas styleguide-git-commit-message is simpler but less automated. Choose based on project size, team preferences, and desired level of commit message standardization.

husky

32,324

Git hooks made easy 🐶 woof!

Pros of husky

Provides a more comprehensive Git hooks management solution
Offers easy integration with popular development tools and workflows
Supports multiple programming languages and frameworks

Cons of husky

Requires Node.js and npm, which may not be suitable for all projects
Can add complexity to the project setup and configuration
May have a steeper learning curve for beginners

Code comparison

styleguide-git-commit-message:

<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>

husky:

{
  "husky": {
    "hooks": {
      "pre-commit": "npm test",
      "pre-push": "npm run lint"
    }
  }
}

The styleguide-git-commit-message repository provides a template for structuring commit messages, while husky offers a configuration file for setting up Git hooks to run scripts automatically.

styleguide-git-commit-message focuses specifically on commit message formatting, providing guidelines and examples for creating clear and informative commit messages. It's a static resource that developers can reference when writing commits.

husky, on the other hand, is a dynamic tool that integrates with your project's development workflow. It allows you to define and execute custom scripts at various stages of the Git process, such as before committing or pushing changes. This enables automated testing, linting, and other quality checks to be performed automatically.

While both repositories aim to improve Git workflow and code quality, they serve different purposes and can be used complementarily in a project.

angular

95,657

Deliver web apps with confidence 🚀

Pros of Angular

Comprehensive framework with a full ecosystem of tools and libraries
Extensive documentation and large community support
Built-in dependency injection and modular architecture

Cons of Angular

Steeper learning curve due to its complexity
Larger bundle size compared to lighter alternatives
More opinionated, which may limit flexibility in some cases

Code Comparison

Angular (TypeScript):

@Component({
  selector: 'app-root',
  template: '<h1>{{title}}</h1>'
})
export class AppComponent {
  title = 'My Angular App';
}

styleguide-git-commit-message (Markdown):

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

<body>

<footer>

Summary

Angular is a full-featured framework for building complex web applications, while styleguide-git-commit-message focuses specifically on Git commit message conventions. Angular offers a complete development ecosystem but comes with a steeper learning curve. The styleguide-git-commit-message repository provides a simpler, more focused approach to standardizing commit messages.

Angular's code structure revolves around components and modules, utilizing TypeScript for enhanced type safety. In contrast, styleguide-git-commit-message presents a straightforward template for structuring Git commit messages, emphasizing clarity and consistency in version control practices.

While both projects aim to improve development workflows, they serve different purposes and cater to distinct aspects of the software development lifecycle.

git-commit-message

1,178

Git commit message: how to write a great git commit message and commit template for version control

Pros of git-commit-message

More comprehensive guide with detailed explanations and examples
Includes sections on commit message structure, best practices, and tips
Provides guidance on specific scenarios like reverting commits and referencing issues

Cons of git-commit-message

Less concise, which may be overwhelming for beginners
Lacks a quick reference or cheat sheet for easy consultation
Does not include language-specific commit message conventions

Code comparison

styleguide-git-commit-message:

<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>

git-commit-message:

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

Both repositories provide similar basic structures for commit messages, but git-commit-message offers more flexibility with optional components.

Summary

styleguide-git-commit-message offers a concise and straightforward guide, while git-commit-message provides a more detailed and comprehensive approach. The choice between the two depends on the user's preference for brevity versus depth of information. Both repositories serve as valuable resources for improving Git commit message practices.

git-style-guide

5,082

A Git Style Guide

Pros of git-style-guide

More comprehensive coverage of Git practices beyond commit messages
Includes guidelines for branching, merging, and rebasing
Provides examples and explanations for various Git commands and workflows

Cons of git-style-guide

Less focused on commit message structure and formatting
Doesn't provide as detailed guidelines for commit message content
Lacks specific examples of good and bad commit messages

Code Comparison

styleguide-git-commit-message:

<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>

git-style-guide:

Short (50 chars or less) summary of changes

More detailed explanatory text, if necessary. Wrap it to about 72
characters or so. In some contexts, the first line is treated as the
subject of an email and the rest of the text as the body.

Both repositories provide guidelines for Git usage, but they focus on different aspects. styleguide-git-commit-message is more specific to commit message structure and content, while git-style-guide covers a broader range of Git practices. The code comparison shows the different approaches to commit message formatting, with styleguide-git-commit-message offering a more structured template and git-style-guide providing a simpler, more flexible format.

Convert designs to code with AI

Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.

Try Visual Copilot

README

Git Commit Message StyleGuide

About

This is an attempt to standardize the format of commit messages, for the sake of uniformity in git log, best practices for writing commit messages & fun!

Using emojis at the beginning of commit messages, other than being fun, provides a simple way to indicate the intention of that commit, an ease for the eyes when browsing/reviewing git log. It's also a simple measure of the fact that how much that commit is focused on a single purpose, which is a good practice.

If these rules and/or using emojis is an overkill for your productivity or simply losing its purposes, please tailor them to your needs or don't use them.

Summary of the reasons for these conventions:

Fun!
Simple navigation through git history (e.g. ignoring style changes).
Automatic generating of the changelog.

Commit Message Format

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

<body>

<footer>

Message Subject(first line)

Capitalize the <subject>.
Do not end the first line with a period.
Total characters of the first line MUST be Less than or Equal to 50 characters Long.
Use the present tense ("Add feature" not "Added feature").
Use the imperative mood ("Move cursor to..." not "Moves cursor to...").
Use <type> to identify what type of changes introduced in this commit; Allowed <type> keywords:
- An Emoji(see below for list of Suggested Emojis)
- Or a Text:
  - feat: new feature for the user(or :sparkles: emoji)
  - fix: bug fix for the user(or :ambulance: emoji)
  - docs: changes to the documentation(or :books: emoji)
  - style: formatting, missing semi colons, etc; no production code change(or :art: emoji)
  - refactor: refactoring production code, eg. renaming a variable(or :tractor: emoji)
  - test: adding missing tests, refactoring tests; no production code change(or :microscope: emoji)
  - chore: updating grunt tasks etc; no production code change
If you need more than one keyword or emoji to use, you should probably think twice!. This usally means you need to break this commit into more smaller commits; If thats not the case then separate each emoji with a space.
Use <scope> to identify which component this <type> is related to; Example <scope> values:
- init
- runner
- watcher
- config
- web-server
- proxy
- etc.
The <scope> can also be empty (e.g. if the change is a global or difficult to assign to a single component), in which case the parentheses are omitted.

Message Body

Includes motivation for the change and contrasts with previous behavior.
Use the body to explain whats and whys vs. hows.
Wrap each line of the body at 72 characters.

Message Footer

Reference issues this commit is related to with the status of that Issue; Ex. Issue #27, Ref T27 or Ref T27, T56 or Fixes T8.
Supported issue tracker status keywords:
- Fixes
- Fixed
- Closes
- Closed
- Resolves
- Resolved
- Ref
- Issue
- Issues
More info on issue tracker status keywords:
It's also recommended to use Full URL to the Issues, instead of just issue ID Number; Doing so will ease browsing issues from terminal.
In the case of multiple issues separate them with commas, Ex. Closes #27, #56.

Notes

Use valid MarkDown format in the <body>.
All WIP(Work In Progress) commits SHOULD have the :construction: Emoji.
All WIP commits SHOULD be avoided!.
Referencing Issues by using special keywords like Fixes or Resolves will mark them as closed automatically! For more information about automatic issue closing using ketwords see their documentation(linked above).
There is NO new-line after the <footer>.
Every emoji text(:emoji:) is counted as one character!.
See ToDo Grammar StyleGuide for more Information on @XXX Comment Tags.

Suggested Emojis

Emoji	Raw Emoji Code	Description
:art:	`:art:`	when improving the format/structure of the code
:newspaper:	`:newspaper:`	when creating a new file
:pencil:	`:pencil:`	when performing minor changes/fixing the code or language
:racehorse:	`:racehorse:`	when improving performance
:books:	`:books:`	when writing docs
:bug:	`:bug:`	when reporting a bug, with `@FIXME`Comment Tag
:ambulance:	`:ambulance:`	when fixing a bug
:penguin:	`:penguin:`	when fixing something on Linux
:apple:	`:apple:`	when fixing something on Mac OS
:checkered_flag:	`:checkered_flag:`	when fixing something on Windows
:fire:	`:fire:`	when removing code or files, maybe with `@CHANGED` Comment Tag
:tractor:	`:tractor:`	when change file structure. Usually together with :art:
:hammer:	`:hammer:`	when refactoring code
:umbrella:	`:umbrella:`	when adding tests
:microscope:	`:microscope:`	when adding code coverage
:green_heart:	`:green_heart:`	when fixing the CI build
:lock:	`:lock:`	when dealing with security
:arrow_up:	`:arrow_up:`	when upgrading dependencies
:arrow_down:	`:arrow_down:`	when downgrading dependencies
:fast_forward:	`:fast_forward:`	when forward-porting features from an older version/branch
:rewind:	`:rewind:`	when backporting features from a newer version/branch
:shirt:	`:shirt:`	when removing linter/strict/deprecation warnings
:lipstick:	`:lipstick:`	when improving UI/Cosmetic
:wheelchair:	`:wheelchair:`	when improving accessibility
:globe_with_meridians:	`:globe_with_meridians:`	when dealing with globalization/internationalization/i18n/g11n
:construction:	`:construction:`	WIP(Work In Progress) Commits, maybe with `@REVIEW` Comment Tag
:gem:	`:gem:`	New Release
:egg:	`:egg:`	New Release with Python egg
:ferris_wheel:	`:ferris_wheel:`	New Release with Python wheel package
:bookmark:	`:bookmark:`	Version Tags
:tada:	`:tada:`	Initial Commit
:speaker:	`:speaker:`	when Adding Logging
:mute:	`:mute:`	when Reducing Logging
:sparkles:	`:sparkles:`	when introducing New Features
:zap:	`:zap:`	when introducing Backward-InCompatible Features, maybe with `@CHANGED` Comment Tag
:bulb:	`:bulb:`	New Idea, with `@IDEA` Comment Tag
:snowflake:	`:snowflake:`	changing Configuration, Usually together with :penguin: or :ribbon: or :rocket:
:ribbon:	`:ribbon:`	Customer requested application Customization, with `@HACK` Comment Tag
:rocket:	`:rocket:`	Anything related to Deployments/DevOps
:elephant:	`:elephant:`	PostgreSQL Database specific (Migrations, Scripts, Extensions, ...)
:dolphin:	`:dolphin:`	MySQL Database specific (Migrations, Scripts, Extensions, ...)
:leaves:	`:leaves:`	MongoDB Database specific (Migrations, Scripts, Extensions, ...)
:bank:	`:bank:`	Generic Database specific (Migrations, Scripts, Extensions, ...)
:whale:	`:whale:`	Docker Configuration
:handshake:	`:handshake:`	when Merge files
:cherries:	`:cherries:`	when Commit Arise from one or more Cherry-Pick Commit(s)

Tools

Commit(CLI): This is a nifty CLI tool to aid in standardizing commit messages based on this document, thanks to @jakeasmith.
gitMoji(Firefox & Chrome Extension): Enhance your commits with emojis!, thanks to @louisgrasset.

Related Ideas

gitmoji: An emoji guide for your commit messages.
Conventional Commits: A specification for adding human and machine readable meaning to commit messages.
Keep a Changelog: Donât let your friends dump git logs into changelogs.

Fun Emoji Usages

CodeEmoji: Mozillaâs Codemoji enciphers your messages with emoji for fun and profit.
Emoji Based Diagram: Emoji Based Diagram of Data Bearing Subscription Updates(WebPush VAPID).
HTTP status codes as emoji.
OSI Model with emojis.

Contributing

Ask to Be Creative!

To add a new Emoji to the list: Create an Issue & Send a PR.

License

The Code is licensed under the MIT License.

Top Related Projects

Convert designs to code with AI

Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.

Try Visual Copilot

Top Related Projects

Quick Overview

Pros

Cons

Getting Started

Competitor Comparisons

Pros of commitlint

Cons of commitlint

Code comparison

Summary

Pros of cz-cli

Cons of cz-cli

Code comparison

Summary

Pros of husky

Cons of husky

Code comparison

Pros of Angular

Cons of Angular

Code Comparison

Summary

Pros of git-commit-message

Cons of git-commit-message

Code comparison

Summary

Pros of git-style-guide

Cons of git-style-guide

Code Comparison

Convert designs to code with AI

README

Git Commit Message StyleGuide

TOC

About

Summary of the reasons for these conventions:

Commit Message Format

Message Subject(first line)

Message Body

Message Footer

Notes

Suggested Emojis

Tools

Related Ideas

Fun Emoji Usages

Contributing

License

Top Related Projects

Convert designs to code with AI