Como escolher o fluxo de trabalho Git e o modelo de ramificação certo para sua equipe

Git é o sistema de controle de versão no centro de quase todo o desenvolvimento de software – é usado para armazenar e rastrear alterações no código que você escreve. Ao trabalhar em equipe, ter um fluxo de trabalho contínuo que funcione para o seu negócio é fundamental para crescer rapidamente.

Melhor organização do repositório, desenvolvimento mais rápido

Com o advento de pipelines de automação fáceis de usar, como Jenkins, muitas empresas estão começando a implementar integração e entrega contínuas (CI/CD), com alterações de desenvolvedores geralmente sendo mescladas em um repositório, geralmente entregando o produto semanalmente em vez de semanalmente. agenda mensal.

Essa velocidade coloca muita pressão em sua organização, especialmente quando se trata de Git. Se você tiver 50 pessoas tentando fazer commit de alterações no mesmo  master branch, você terá problemas com conflitos de merge frequentes.

Felizmente, o Git oferece a capacidade de criar ramificações e escolher quando você deseja mesclar o código, que toda equipe deve usar para organizar seu desenvolvimento. Assumir o controle do seu fluxo de trabalho do Git pelo menos evitará que você e seus colegas de equipe percam tempo pesquisando novos problemas do Git.

Características e desenvolvimento de filiais

Existem dois grandes problemas nos quais as ramificações do Git estão trabalhando: manter seus comandos internos sincronizados e manter sua versão pública.

Quando você inicia uma ramificação no Git, novos commits serão feitos para essa ramificação, não master. Isso pode ser útil para acompanhar o progresso individual em um determinado recurso ou correções de bugs; por exemplo, cada branch pode implementar um recurso descrito em um problema em um serviço Kanban, como Jira, Trello ou Github Issues & Projects.

A mesclagem de branches geralmente é feita usando pull requests, um recurso de soluções Git hospedadas como o Github, onde o comando solicita um master pull de feature um branch e integra as alterações para todos. Isso pode ser muito útil para equipes que fazem QA e testes de unidade para garantir que uma ramificação esteja funcionando corretamente antes de subir na cadeia.

Outro problema é gerenciar seus lançamentos – você não deseja enviar a seus clientes uma cópia de sua última compilação de desenvolvimento interna, pois ela pode ser corrompida por um commit incorreto.

Para resolver esse problema, muitas equipes usarão uma ramificação separada para lançamentos e mesclarão essa ramificação somente quando for a hora de lançar uma nova versão. Isso permite várias confirmações em segundo plano na ramificação de desenvolvimento entre as versões.

Outro benefício desse modelo é a capacidade de fazer commits separados na ramificação de produção, possivelmente fornecendo correções para problemas antes que a próxima versão esteja pronta.

Desenvolvimento principal

Sua estratégia de ramificação determina exatamente como você usará as ferramentas fornecidas. Existem muitas estratégias de ramificação diferentes projetadas para diferentes tipos de equipes.

O desenvolvimento baseado em estrada está próximo do que a programação da equipe deveria ser – iteração rápida em uma master ramificação para lançar rapidamente um produto viável. A equipe cria ramificações de recursos de curta duração, geralmente com duração não superior a alguns dias, e geralmente se compromete diretamente com o master.

É chamado de “tronco” porque master torna o galho o galho mais ativo e útil em todo o repositório, como um tronco de árvore grosso suportando todo o resto. Todo o desenvolvimento é focado neste ramo, que é fácil e rápido de aprender, proporcionando uma boa experiência ao desenvolvedor.

Uma vez pronto para lançamento, um novo branch versionado é criado para cada lançamento. Isso separa as versões mastere também ajuda a adicionar ou selecionar correções para versões LTS.

Isso tem muitas vantagens, especialmente para equipes pequenas. Se você trabalha com alguns desenvolvedores seniores que conhece e confia nas permissões de gravação de todo o repositório, integrar suas alterações o mais rápido possível pode realmente acelerar o desenvolvimento. No final, isso elimina quase toda a burocracia associada a constantes pull requests e merges, embora a comunicação simples com sua equipe ainda seja necessária para manter um ao outro e você deve sempre saber no que o outro está trabalhando.

No entanto, esta não é uma boa organização, pois depende de disciplina e bons desenvolvedores. Isso é realmente ótimo para lançar produtos rapidamente ou iterar rapidamente em projetos existentes, mas assim que você adiciona mais desenvolvedores juniores ao projeto ou obtém mais colaboradores de código aberto, ele começa a mostrar suas falhas.

Fluxo Git tradicional

“Git Flow” é um fluxo de trabalho que funciona em muitas equipes. Isso é mais complexo do que o fluxo de trabalho de desenvolvimento de backbone simples, mas oferece muitos benefícios para projetos de código aberto e grandes projetos com muitos membros da equipe.

Na estratégia de ramificação do Git Flow, as ramificações de recursos duram mais e são o foco principal da integração diária. As equipes trabalharão nos recursos até que estejam prontas para produção e, em seguida, passarão por um processo de solicitação de pull para obter sua aprovação. Pode haver qualquer número de recursos ao mesmo tempo, incluindo aqueles que duram o suficiente para que precisem ser rebaseados para master commits mais recentes.

Com o Git Flow, o acesso é mais limitado, pois a maioria dos desenvolvedores não terá permissão para mesclar diretamente com develop, e certamente não com master, e terá que criar branches como seu principal método de fazer alterações.

O Git Flow naturalmente deixa tempo para uma revisão de código adequada durante o processo de pull request. Isso permite que os conflitos sejam tratados com PRs, rebases e fusões, em vez de uma ramificação de backbone em constante mudança. Isso faz sentido para o código aberto porque esses forks podem vir de terceiros, mas também faz sentido em ambientes de equipes grandes ou para equipes que desenvolvem produtos monolíticos com muitos componentes.

Um dos principais recursos desse fluxo de trabalho é o modelo de versão. Quando chega a hora de uma nova versão, uma ramificação separada é criada para preparação. Correções de bugs e patches finais são feitos aqui, então enviados para a master ramificação real e recebem uma tag para compilar a versão.

A principal diferença é que essa master ramificação é mantida junto com o develop. Os commits das ramificações de lançamento são mesclados de volta ao develop, assim como as correções. Isso sempre torna develop o branch mais recente do qual os lançamentos são feitos quando eles são estáveis.

Essa separação facilita o gerenciamento de pequenas correções de bugs que precisam ser lançadas antes de serem master mescladas nas versões mais recentes. A ramificação de lançamento funciona da mesma maneira que a ramificação de recursos, com o bônus adicional de ser marcada como estável.

É claro que as solicitações constantes de pull, rebase e merge são um trabalho árduo e podem ser tediosas se você estiver tentando ser rápido. Mas, assim como a digitação estática ou os testes de unidade, vale a pena manter as coisas organizadas e funcionando sem problemas no final.

Escolha o que é certo para você

No final, é tudo uma questão de boa etiqueta de equipe, e sua equipe pode se sair bem com um histórico do Git que é mais como uma linha do que um diagrama sofisticado. Se o seu projeto é pequeno ou você é um hobbysta solo, aderir aos padrões rígidos do Git pode fazer mais mal do que bem.

Mas se você está tendo problemas com o Git, você pode tentar o desenvolvimento de backbone ou Git Flow. No mínimo, entender a organização do seu repositório ajudará você a melhorar o processo de integração.