Fluxo de trabalho com Git em time: branch, PR e main protegida

Um fluxo de Git é um acordo sobre onde nasce o trabalho, quem revisa, quais testes bloqueiam integração e como uma versão chega à produção. Branch e PR são ferramentas; proteção, tamanho das tarefas e responsabilidade fazem o sistema funcionar.

O sandbox modelou uma feature com dois commits:

git --no-pager log --oneline -3

Combine regras antes do primeiro conflito

Defina branch principal, forma de atualizar, requisitos de PR, estratégia de merge, convenção de mensagem e resposta a emergência. Regra tácita funciona até duas pessoas assumirem coisas diferentes. Registre o acordo no README ou guia de contribuição.

Main protegida impede push direto, exige revisão e checks conforme a configuração do GitHub. Essa proteção não foi alterada nesta produção: depende de permissões de administrador. Localmente, o estado foi preparado para mostrar o histórico que cada política produziria.

Antes de qualquer integração, a lista de branches do sandbox mostrou quais nomes apontavam para o hotfix e quais preservavam alternativas de merge:

git branch -vv | sed -n '1,6p'

Essa inspeção local não prova proteção no GitHub; prova somente a posição das referências. Status de checks, aprovação e regras precisam ser consultados na plataforma por quem possui acesso.

Uma tarefa curta ganha uma branch curta

git switch -c feat/busca

Nome comunica intenção; descrição da issue comunica contexto. Branch curta reduz distância da main e superfície de conflito. “Curta” é tempo e escopo, não poucos caracteres. Uma tarefa de três semanas provavelmente precisa ser dividida ou integrar incrementos desativados por flag.

O ciclo diário tem observação entre comandos

Atualize referências, integre a base conforme política, trabalhe, teste, revise o stage, faça commit e envie:

git status --short
git branch --show-current
git diff --cached --stat

Status e diff ficaram sem saída; a única linha veio da branch atual. O hábito é mais importante: não faça pull, add e push numa cadeia que impede leitura entre estados. Cada pausa é uma chance de encontrar branch errada ou arquivo estranho.

Conventional Commits melhora leitura, não corrige escopo

feat, fix, docs, refactor, test e chore classificam intenção. O assunto usa imperativo e explica resultado. Um commit gigante chamado feat continua gigante; a convenção não substitui decomposição.

git --no-pager log --oneline --all -6

Mensagens permitem gerar changelog como ponto de partida, ligar automações e encontrar decisões. Corpo do commit explica por que quando o assunto não basta.

Três fluxos servem a cadências diferentes

Git Flow cobra merges e sincronização adicionais. Trunk-based cobra testes, flags e disciplina para integrar incompleto sem expor. GitHub Flow é simples, mas exige main sempre saudável. Escolha pelo ciclo de entrega, não pelo fluxo mais famoso.

O grafo de merge explícito do sandbox ficou:

git --no-pager log --oneline --graph --decorate main-merge -5

O squash da mesma feature reduziu a tarefa a um commit:

git --no-pager log --oneline --graph --decorate main-squash -3

Esses desenhos não elegem vencedor. O ciclo de pull request explica o efeito da escolha na revisão.

Duas pessoas no mesmo arquivo reduzem conflito com coordenação

Divida tarefas por resultado, mantenha branches atualizadas e avise mudanças estruturais cedo. Não tente “reservar” arquivos: módulos se relacionam. PRs pequenos diminuem o intervalo entre base e integração. Testes detectam conflito sem marcador, quando duas mudanças mesclam textualmente mas quebram regra.

Ao encontrar conflito, preserve intenções, não lados. “Aceitar o meu” apaga a contribuição sem avaliar. Leia commits e converse com a pessoa autora.

Hotfix encurta o caminho sem remover revisão

O sandbox abriu fix/busca-vazia, registrou uma correção e fez fast-forward:

git switch -c fix/busca-vazia
# edite busca.js e execute git add busca.js
git commit -m "fix: evita busca sem termo"
git switch main-merge
git merge --ff-only fix/busca-vazia

Em produção, hotfix ainda precisa teste, revisão proporcional e rastreabilidade. Urgência pode reduzir espera; não autoriza senha no código, force na main ou mudança sem responsável.

Checklist do primeiro dia

Confirme remote, branch principal, estratégia de pull, comandos de teste, responsáveis por revisão, padrão de mensagem, regra de segredo e processo de release. Faça uma alteração pequena para observar o ciclo inteiro. Perguntar antes evita aprender a política pelo erro do servidor.

Sua missão é simular GitHub Flow com bare local: feature curta, dois commits, revisão do diff e integração. Compare o grafo com squash e registre sua tabela de decisão. Depois conecte rebase, tags e README ao projeto final sem afirmar que proteção ou PR externo foram criados automaticamente.