Receber por email
← Voltar para o catálogo

git-workflow

Trunk-based development with atomic commits, clean history, and meaningful commit messages. Every commit should be deployable.

64estrelas
Atualizado há 6 meses

Ver no GitHub ↗ Licença: MIT

Como adicionar

/plugin marketplace add DevelopersGlobal/ai-agent-skills

O comando exato pode variar conforme o repositório. Confira o README no GitHub.

Para o autor da skill

Cole no README do seu repo

Mostra que sua skill está catalogada na Skillteca, gera backlink e tráfego rastreável.

[![Skillteca](https://www.skillteca.com.br/api/badge/git-workflow-developersglobal/svg)](https://www.skillteca.com.br/skills/git-workflow-developersglobal)

Skills relacionadas

Ver todas de DevOps e Infra →

Alerta por categoria

Receba novas skills de DevOps e Infra toda segunda

1 email curto, só com as skills novas de DevOps e Infra. 4 minutos de leitura, sem spam, cancela com 1 clique.

Você confirma o email no primeiro envio. Sem spam. Cancela com 1 clique.

Ler descrição completa

Overview

Git is not just a backup system — it's a communication tool. Clean git history enables fast debugging (git bisect), clear attribution, and safe reverts. This skill enforces atomic commits, meaningful messages, and trunk-based development.

When to Use

  • Before making any commit
  • When reviewing a PR's git history
  • When setting up a new project

Process

Step 1: Atomic Commits

  1. Each commit should represent ONE logical change — not a day's worth of work.
  2. A commit should be: independently deployable, independently revertable.
  3. Never commit "WIP" or partial implementations.

Verify: You could revert this commit without affecting adjacent functionality.

Step 2: Commit Message Format

  1. Follow Conventional Commits:

``` type(scope): short summary (max 72 chars)

Body: what changed and WHY (not how — the diff shows how).

Closes: #issue-number ```

  1. Types: feat, fix, docs, style, refactor, test, chore
  2. The summary is imperative mood: "Add feature" not "Added feature"

Verify: Message passes: feat|fix|docs|...(<scope>): <summary> format.

Step 3: Trunk-Based Development

  1. Work directly on main for small changes (<1 day of work).
  2. For larger features: short-lived feature branches (max 2 days), frequent merges to main.
  3. Never let a branch live more than 3 days without merging or rebasing.
  4. Use feature flags for incomplete features, not long-lived branches.

Verify: No branch is more than 2 days old without a merge/rebase plan.

Step 4: Pre-Commit Gates

  1. Before every commit: tests pass, linter passes, no secrets in diff.
  2. Use pre-commit hooks to enforce automatically.

Common Rationalizations (and Rebuttals)

| Excuse | Rebuttal | |--------|----------| | "I'll clean up the commits later" | You won't. Clean as you go. | | "The commit message doesn't matter" | It matters in 6 months when you're bisecting a production bug. | | "Feature branches protect main" | Long-lived branches cause merge nightmares. Trunk-based is safer. |

Verification

  • [ ] Commits are atomic and independently deployable
  • [ ] Commit messages follow Conventional Commits format
  • [ ] No long-lived branches (> 3 days)
  • [ ] Pre-commit hooks in place

References

Compartilhar X LinkedIn