iuricode/padroes-de-commits

★ 9,358ShellAudience · developerComplexity · 1/5Setup · easy

Mindmap

mindmap
  root((repo))
    What it does
      Commit message guide
      Conventional Commits
    Commit types
      feat fix docs test
      style perf build chore
    Emoji mapping
      Visual log scanning
      Optional add-on
    Automation
      commit-msg hook
      Changelog generation

mindmap root((repo)) What it does Commit message guide Conventional Commits Commit types feat fix docs test style perf build chore Emoji mapping Visual log scanning Optional add-on Automation commit-msg hook Changelog generation

Click or tap to explore — scroll the page freely

Things people build with this

USE CASE 1

Install the included commit-msg.sh Git hook to automatically block commits that do not follow the Conventional Commits format.

USE CASE 2

Use the emoji-to-type mapping table to make your project's git log visually scannable at a glance.

USE CASE 3

Share the guide with your team to agree on a shared commit message convention that makes code review and changelog generation easier.

Tech stack

ShellGit

Getting it running

Difficulty · easy Time to first run · 5min

In plain English

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.

Copy-paste prompts

Prompt 1

Install the commit-msg.sh hook from padroes-de-commits in my repo, show me the exact terminal steps and test that it rejects a non-conforming commit.

Prompt 2

Using the Conventional Commits format from padroes-de-commits, help me write properly formatted commit messages for these changes: added a login page, fixed a null pointer error, updated the README.

Prompt 3

Set up a changelog generator that reads my git history and parses Conventional Commits format as described in padroes-de-commits.

Open on GitHub → Explain another repo

← iuricode on gitmyhub — every repo by this author, as a profile.

Verify against the repo before relying on details.