Por que a Maioria dos Fluxos de Trabalho do Git Falha para Desenvolvedores Solo
O problema com a maioria dos tutoriais e fluxos de trabalho do Git é que eles são escritos por pessoas que trabalham em empresas com múltiplas equipes, processos de revisão de código e pipelines de implantação que envolvem pelo menos três ambientes diferentes. Quando você é um desenvolvedor solo, você não tem essas restrições—mas também não tem essas redes de segurança. GitFlow, o fluxo de trabalho que dominou a década de 2010, é um exemplo perfeito. Ele foi criado por Vincent Driessen para um problema específico: gerenciar lançamentos de software que precisavam suportar várias versões simultaneamente. Se você está construindo uma aplicação desktop que os clientes instalam localmente, o GitFlow faz sentido. Se você é um desenvolvedor solo entregando um produto SaaS ou um site para cliente, é um exagero completo. A jornada típica do desenvolvedor solo com o Git é mais ou menos assim: Você começa apenas fazendo commits em `main` (ou `master`, dependendo de quando aprendeu Git). Então você lê um artigo sobre "fluxos de trabalho profissionais do Git" e se sente culpado. Você implementa ramos de recurso. Então você adiciona um ramo `develop` porque foi isso que o diagrama mostrou. Antes que você perceba, você está gastando 20 minutos por dia apenas gerenciando ramos, e não tem nem certeza do porquê metade deles existe. Eu já estive lá. Eu tive repositórios com ramos nomeados `feature/new-feature`, `feature/new-feature-2`, `feature/new-feature-actually-final` e `feature/new-feature-for-real-this-time`. Se você nunca teve uma crise de nomenclatura de ramos, você está mentindo ou não tem experiência suficiente como desenvolvedor solo. A questão fundamental é que fluxos de trabalho de equipe são projetados para resolver problemas de equipe: coordenar o trabalho entre várias pessoas, prevenir conflitos, gerenciar processos de revisão de código e manter a estabilidade em ambientes compartilhados. Quando você está trabalhando solo, a maioria desses problemas simplesmente não existe. Você não pode ter um conflito de mesclagem com outra pessoa se não houver mais ninguém.A Regra dos Três Commits que Mudou Tudo
Após meu desastre às 2 da manhã, comecei a analisar meus padrões de trabalho reais. Eu puxei meu histórico do Git dos seis meses anteriores e olhei para cada ramo que eu havia criado, cada mesclagem que eu havia feito e cada conflito que eu havia resolvido. O que encontrei foi iluminador. Noventa por cento dos meus ramos de recursos continham três commits ou menos antes de mesclar. Eles não eram recursos complexos de várias semanas que precisavam de isolamento. Eram pequenas melhorias, correções de bugs e mudanças incrementais que eu havia separado artificialmente em ramos porque achei que era isso que "desenvolvedores reais" faziam. Os restantes dez por cento—os recursos complexos de fato—eram onde os ramos faziam sentido. Mas mesmo assim, percebi algo: os ramos que causavam problemas eram aqueles que eu deixara abertos por mais de uma semana. Quanto mais tempo um ramo viveu, mais provável era causar problemas ao mesclar novamente. Isso me levou ao que chamo de Regra dos Três Commits: Se uma mudança leva mais de três commits, provavelmente é grande demais e deve ser dividida. Se não pode ser dividida, é um dos raros casos em que um ramo realmente ajuda. Essa regra me forçou a pensar de forma diferente sobre como trabalho. Em vez de criar um ramo para "redesenhar toda a UI", eu criava um ramo para "atualizar estilos de botão" ou "implementar novo componente de navegação." Cada ramo vivia por um dia ou dois no máximo, continha mudanças focadas e mesclava de forma limpa. A mudança psicológica foi significativa. Eu parei de pensar em termos de "recursos" e comecei a pensar em termos de "incrementos implantáveis." Cada ramo tinha que representar algo que eu pudesse enviar para produção sem quebrar a funcionalidade existente. Isso naturalmente mantinha os ramos pequenos e de vida curta.O Dia em que Enviei um Bug para Produção (E por que Isso Melhorou Meu Fluxo de Trabalho)
Deixe-me contar sobre a pior implantação da minha carreira. Eu estava trabalhando em um projeto de cliente—um sistema de reservas para uma pequena rede de hotéis. Eu havia estado trabalhando em um ramo de recursos por duas semanas (sim, eu sei, quebrei minha própria regra) que adicionava uma nova integração de pagamento. O ramo havia se desviado significativamente de `main`. Eu estava tão focado no recurso de pagamento que não havia acompanhado as pequenas correções e melhorias que havia feito diretamente em `main` para pedidos urgentes do cliente. Quando chegou a hora de mesclar, eu tive conflitos em 14 arquivos. Resolvi os conflitos, rodei os testes (eles passaram) e implantei em produção. Em menos de uma hora, recebi uma ligação apavorada do cliente. O formulário de reserva estava quebrado. Não a nova integração de pagamento—o formulário básico de reserva que estava funcionando bem há meses. O que aconteceu? Ao resolver um dos conflitos de mesclagem, eu acidentalmente mantive a versão errada de uma função. Os testes não detectaram isso porque eu não havia escrito testes para aquele caso extremo em particular (lição aprendida). O bug foi totalmente culpa minha, mas o fluxo de trabalho facilitou esse erro. Esse incidente me ensinou algo crucial: como desenvolvedor solo, meu maior risco não é o código de outras pessoas—é meu próprio código de duas semanas atrás. Quando estou mudando de contexto entre diferentes partes de um projeto, estou essencialmente colaborando com versões passadas de mim mesmo. E o passado eu muitas vezes é um colega não confiável. Essa realização levou ao segundo pilar do meu fluxo de trabalho: a Regra da Uma Semana. Nenhum ramo vive mais de uma semana. Se um recurso vai levar mais tempo do que isso, eu o divido em pedaços menores que podem ser concluídos e mesclados dentro de uma semana. Se isso não for possível, uso flags de recursos para mesclar código incompleto em `main` enquanto o mantenho oculto dos usuários. A Regra da Uma Semana já me salvou inúmeras vezes. Ela me força a ficar perto de `main`, o que significa que estou sempre trabalhando com a versão mais atual do código. Previne o tipo de divergência que leva a conflitos de mesclagem complexos. E me mantém honesto sobre o escopo—se não consigo terminar algo em uma semana, provavelmente estou tentando fazer muito de uma vez.O Custo Real da Complexidade dos Ramo
Vamos falar de números. Eu rastreei minhas atividades relacionadas ao Git por três meses antes e depois de simplificar meu fluxo de trabalho. Os resultados foram impressionantes:| Atividade | Antes (horas/semana) | Depois (horas/semana) | Tempo Economizado |
|---|---|---|---|
| Criando e gerenciando ramos | 2.5 | 0.5 | 2 horas |
| Resolvendo conflitos de mesclagem | 3.0 | 0.3 | 2.7 horas |
| Decidindo qual ramo trabalhar | 1.5 | 0.1 | 1.4 horas |
| Limpando ramos obsoletos | 1.0 | 0.1 | 0.9 horas |
| Rebaseando e sincronizando ramos | 2.0 | 0.2 | 1.8 horas |
| Custo total do Git | 10.0 | 1.2 | 8.8 horas |
Por que "Comite Cedo, Comite Frequente" Está Errado para Desenvolvedores Solo
Aqui está uma opinião controversa: o conselho de "comitar cedo, comitar frequentemente" é na verdade prejudicial para desenvolvedores solo. Sei que isso vai contra a sabedoria convencional, mas ouça-me.O propósito dos commits não é criar um registro detalhado de cada digitação. É criar pontos de verificação significativos que contam uma história sobre como seu código evoluiu. Quando você está trabalhando solo, você é a única pessoa que precisa entender isso...