gitmyhub

padroes-de-commits

Shell ★ 9.5k updated 1y ago

Padrões de commits

A Portuguese-language reference guide for writing consistent Git commit messages using the Conventional Commits standard, with optional emoji mappings and a shell hook that enforces the format automatically.

ShellGitsetup: easycomplexity 1/5

This repository is a reference guide, written in Portuguese, for writing consistent and meaningful Git commit messages. It follows the Conventional Commits specification, which is a widely adopted convention that gives each commit message a standard structure so that anyone reading the project history can quickly understand what changed and why.

The core idea is to start every commit message with a short prefix called a type. Each type signals the intent of the change: "feat" means a new feature was added, "fix" means a bug was resolved, "docs" means only documentation changed, "test" covers changes to automated tests, and so on. The guide defines about a dozen of these types, including ones for code style formatting, performance changes, build-system updates, and cleanup of unused code. None of these types overlap, so the history stays readable even as a project grows.

The repository also pairs each commit type with an emoji. This is optional but lets teams scan a commit log visually, spotting a bug fix or a new feature at a glance before reading the full message. The emoji mapping is laid out in a table in the README, covering everything from accessibility changes to dependency upgrades.

For teams that want to enforce this convention automatically, the repository includes a shell script called commit-msg.sh. It acts as a Git hook, meaning Git runs it each time a developer tries to commit. If the commit message does not match the expected pattern, the hook blocks the commit and shows an error. The README walks through the setup step by step: verify Git is installed, copy the script into the correct hooks folder, and make it executable.

Additional guidance covers how to write the body and footer of a commit for more detailed context, how to keep the first line short, and how to add links without shorteners. The guide is aimed at developers and teams who want a shared language for their version-control history, making code review and automated changelog generation easier.

Where it fits