Git Workflow for Small Teams (Keep It Simple)

Na última terça-feira, assisti a um desenvolvedor júnior passar quarenta e cinco minutos tentando descobrir por que seu branch de recurso não conseguia fazer merge. O culpado? O fluxo de trabalho do Git da nossa equipe, excessivamente complexo, que envolvia quatro tipos diferentes de branch, protocolos de rebase obrigatórios e uma estratégia de merge que exigia um fluxograma para entender. Estou liderando equipes de engenharia há doze anos, e posso te dizer com absoluta certeza: a maioria das pequenas equipes está se afogando em uma complexidade do Git que não precisa.

Sou Sarah Chen, e passei a última década construindo e escalando equipes de desenvolvimento em três startups diferentes. Vi equipes de cinco desenvolvedores usando fluxos de trabalho projetados para organizações com quinhentos engenheiros. Assisti a programadores brilhantes desperdiçarem horas navegando em estratégias de branching que não agregam valor ao seu trabalho real. E aprendi que, quando se trata de workflows de Git para pequenas equipes—digamos de dois a dez desenvolvedores—simplicidade não é apenas algo desejável. É a diferença entre enviar funcionalidades e enviar confusão.

Aqui está o que ninguém te diz: o Git é incrivelmente poderoso, o que significa que também é incrivelmente fácil de complicar. A internet está cheia de artigos sobre Git-flow, fluxo do GitHub, fluxo do GitLab, desenvolvimento baseado em trunk e uma dúzia de outras estratégias. A maioria deles está resolvendo problemas que você não tem. Vou te mostrar o fluxo de trabalho do Git que manteve minhas equipes produtivas, felizes e enviando código sem a sobrecarga da complexidade de nível empresarial.

Por que a Maioria dos Workflows de Git Falha em Pequenas Equipes

Antes de mergulharmos no que funciona, vamos falar sobre o que não funciona. Eu herdei bases de código de equipes que estavam usando Git-flow com seu branch develop, branches de release, branches de hotfix e branches de função. Para uma equipe de quatro desenvolvedores trabalhando em um produto SaaS com lançamentos semanais, isso era um exagero total.

O problema com fluxos de trabalho complexos não é que eles estão errados—é que eles estão resolvendo problemas que surgem em grande escala. O Git-flow foi criado por Vincent Driessen em 2010 para um contexto específico: equipes gerenciando várias versões de produção simultaneamente, com longos ciclos de lançamento e a necessidade de um extenso gerenciamento de hotfixes. Se você é uma pequena equipe que envia continuamente para um único ambiente de produção, está carregando toda a sobrecarga do Git-flow sem nenhum de seus benefícios.

Eu fiz uma experiência no ano passado com duas equipes de tamanho e nível de habilidade semelhantes. A Equipe A usou um fluxo de trabalho simplificado que descreverei. A Equipe B usou o Git-flow padrão. Em três meses, a Equipe A enviou 23% mais funcionalidades e relatou níveis de frustração significativamente mais baixos em nossa pesquisa trimestral. A diferença não foi talento ou esforço—foi fricção. Cada tipo extra de branch, cada passo adicional de merge, cada operação de rebase complexa adiciona carga cognitiva e desacelera sua equipe.

Pequenas equipes têm restrições diferentes das grandes organizações. Você provavelmente não tem gerentes de release dedicados. Você provavelmente não precisa suportar várias versões de produção. Seus desenvolvedores usam múltiplos chapéus e trocam de contexto frequentemente. Seu fluxo de trabalho deve refletir essas realidades, não lutar contra elas. Quando vejo uma equipe de cinco pessoas usando a mesma estratégia de Git que o Google, sei que eles estão otimizando para problemas que esperam ter um dia, em vez de para os problemas que têm hoje.

O custo da complexidade se acumula ao longo do tempo. Um desenvolvedor que gasta dez minutos por dia navegando em um fluxo de trabalho do Git desnecessariamente complexo perde mais de quarenta horas por ano—uma semana inteira de trabalho—apenas gerenciando branches. Multiplique isso pela sua equipe e você verá semanas de produtividade perdida anualmente. Isso sem contar o tempo gasto corrigindo conflitos de merge que não existiriam em um fluxo de trabalho mais simples, ou a energia mental drenada por lembrar constantemente qual branch deve ser mesclada em qual.

A Filosofia dos Dois Branches: Principal e Recurso

Aqui está o fluxo de trabalho que funcionou para todas as pequenas equipes que liderei: dois tipos de branches, ponto final. Você tem o branch principal (ou master, se estiver trabalhando com repositórios mais antigos), e você tem branches de recurso. É isso. Sem branch develop, sem branches de release, sem branches de hotfix. Apenas principal e recursos.

O Git é incrivelmente poderoso, o que significa que também é incrivelmente fácil de complicar. A maioria das equipes está resolvendo problemas que não têm.

Seu branch principal representa a produção. O que está no principal deve estar implantável a qualquer momento. Isso é inegociável. Se o principal não é implantável, seu fluxo de trabalho falhou. Este princípio único elimina uma quantidade enorme de complexidade porque significa que você está sempre trabalhando em direção a um alvo claro: colocar seu código em um estado onde ele possa ser mesclado com segurança no principal.

Branches de recurso são onde todo o trabalho acontece. Começando um novo recurso? Crie um branch a partir do principal. Corrigindo um bug? Crie um branch a partir do principal. Refatorando algum código? Crie um branch a partir do principal. O padrão é consistente e previsível. Não há árvore de decisão sobre de qual branch ramificar ou em qual branch mesclar. Cada branch de recurso tem o mesmo ciclo de vida: ramificar do principal, fazer seu trabalho, mesclar de volta ao principal.

Eu nomeio branches de recurso com uma convenção simples: tipo/descrição-curta. Por exemplo: feature/autenticação-de-usuário, bugfix/redirect-de-login, refactor/client-api. O prefixo de tipo torna imediatamente claro que tipo de trabalho está acontecendo, e a descrição é legível. Eu já vi equipes usando números de ticket (feature/JIRA-1234), mas acho isso menos intuitivo quando você está olhando para uma lista de branches. Você quer ser capaz de escanear seus branches e entender imediatamente no que está sendo trabalhado.

A beleza dessa abordagem é sua previsibilidade. Um novo desenvolvedor que se junta à sua equipe pode entender todo o seu fluxo de trabalho do Git em cerca de cinco minutos. Não há diagrama de ramificação complexo para decorar, nem casos especiais para lembrar. Ramifique do principal, faça seu trabalho, mescle ao principal. Essa simplicidade tem um efeito acumulativo na produtividade. Quando seu fluxo de trabalho é simples, os desenvolvedores gastam menos energia mental no processo e mais na resolução de problemas reais.

Uma pergunta que recebo frequentemente: e quanto a recursos de longa duração que levam semanas para serem concluídos? Você não precisa de um branch develop para isso? Não. Você precisa de flags de recurso. Se um recurso não está pronto para os usuários, esconda-o atrás de uma flag. Isso mantém seu código integrado continuamente enquanto te dá controle sobre quando os recursos se tornam visíveis. Já vi equipes criarem estratégias de ramificação elaboradas para resolver problemas que as flags de recurso resolvem de forma mais elegante.

Pull Requests: Seu Portão de Qualidade

Cada branch de recurso é mesclada ao principal através de um pull request. Sem exceções. Eu não me importo se você é o CTO ou se é uma alteração de uma linha. Pull requests não são apenas sobre revisão de código—são sobre criar um momento de tomada de decisão deliberada antes que o código entre em produção.

Aqui está meu modelo de pull request, que refinei ao longo de anos de experimentação. É curto porque modelos longos não são preenchidos corretamente. Cada pull request deve incluir: uma breve descrição do que mudou, por que mudou e como testar. É isso. Três seções, cada uma com tipicamente três a cinco frases. Se você não consegue explicar sua alteração nesse espaço, sua alteração provavelmente é grande demais.

Para revisão de código, sigo uma regra simples: cada pull request precisa de pelo menos uma aprovação antes de mesclar, mas a pessoa que a aprova compartilha a responsabilidade por quaisquer problemas que surgirem. Isso cria a estrutura de incentivo certa. Os revisores levam seu papel a sério porque não estão apenas carimbando—estão co-assinando. Ao mesmo tempo, uma aprovação é suficiente porque somos uma equipe pequena e confiamos uns nos outros. Exigir duas ou três aprovações pode fazer sentido para uma equipe de cinquenta, mas para uma equipe de cinco, isso só está desacelerando as coisas.

Eu experimentei diferentes expectativas de tempo de resposta para revisões. O que funciona melhor: os revisores devem fornecer feedback dentro de quatro horas durante o horário de trabalho. Não quatro horas de tempo de revisão focado—quatro horas para pelo menos reconhecer o pull request e fornecer feedback inicial. Isso mantém o código em movimento sem criar uma expectativa de resposta instantânea. Se alguém precisar de mais tempo para uma revisão completa, eles comentam avisando, e o autor sabe que pode esperar um feedback detalhado mais tarde.

Uma prática que melhorou dramaticamente nossa qualidade de código: exigir que o autor do pull request mescle seu próprio código após aprovação. Isso pode parecer um pequeno detalhe, mas muda o comportamento. Quando você sabe que será você a clicar no botão de mesclagem, você é mais cuidadoso com suas alterações. Você