[ad_1]
Git é um sistema de controle de versão no coração de quase todo 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 fácil de seguir que funcione para o seu negócio é crucial para um desenvolvimento rápido.
Melhor organização do repositório, desenvolvimento mais rápido
Com o surgimento de pipelines de automação fáceis de usar, como Jenkins, muitas empresas estão começando a fazer integração e entrega contínuas (CI/CD), e as alterações do desenvolvedor estão sendo incorporadas ao repositório com frequência, geralmente enviando um produto semanalmente em vez de agendar mensalmente .
Esse tipo de velocidade coloca muito estresse em sua organização, especialmente quando se trata de Git. Se você tem 50 pessoas tentando fazer alterações no mesmo master branch, você terá problemas com conflitos de mesclagem freqüentes.
Felizmente, o Git oferece a capacidade de ramificar e escolher quando você deseja mesclar o código, que cada equipe deve usar para organizar seu desenvolvimento. Estar no controle do seu fluxo de trabalho do Git, no mínimo, evitará que você e seus colegas de equipe percam tempo pesquisando mais problemas do Git.
Introduzir e desenvolver ramos
Existem dois grandes problemas que as ramificações do Git trabalham para ajudar a resolver: manter suas equipes internas sincronizadas e manter sua versão pública.
Quando você inicia uma ramificação no Git, novos commits serão feitos para essa ramificação, em vez de master. Isso pode ser útil para acompanhar o progresso individual em um determinado recurso ou correções de bugs; por exemplo, cada branch pode implantar um recurso descrito em um problema para um serviço Kanban, como Jira, Trello ou Github Issues & Projects.
A fusão de ramos geralmente é feita com solicitações de pull, um recurso de soluções hospedadas em Git como o Github, onde a equipe solicita que master Puxe a feature branch e integrar as mudanças para todos. Isso pode ser muito útil para as equipes realizarem testes de controle de qualidade e de unidade para garantir que a ramificação esteja funcionando corretamente antes de subir na cadeia.
A outra questão é gerenciar seus lançamentos: você não quer enviar a seus clientes uma cópia de sua última compilação de desenvolvimento interna, pois ela pode quebrar devido a um commit incorreto.
Para resolver isso, muitas equipes usarão uma ramificação separada para lançamentos e apenas mesclarão essa ramificação quando for a hora de enviar uma nova versão. Isso permite que vários commits sejam feitos em segundo plano, na ramificação de desenvolvimento entre os lançamentos.
Outro benefício desse modelo é poder fazer commits separados na ramificação de produção, talvez fornecendo correções para problemas antes que a próxima versão esteja pronta.
Desenvolvimento baseado em tronco
Sua estratégia de ramificação determina exatamente como você usa essas ferramentas que são fornecidas a você. Existem muitas estratégias de bifurcação feitas para diferentes tipos de equipes.
O desenvolvimento baseado em tronco está próximo do que a programação em equipe deve ser: iteração rápida no master filial, para empurrar um produto viável rapidamente. A equipe cria ramificações de recursos de curta duração, normalmente com duração não superior a alguns dias, e muitas vezes se envolvendo diretamente com master.
É chamado de “tronco” porque o efeito disso faz com que o master branch o branch mais ativo e útil de todo o repositório, como um tronco de árvore grosso que suporta todo o resto. Todo o desenvolvimento é feito em torno desse branch, que é rápido e fácil de entender, proporcionando uma boa experiência de desenvolvedor.
Quando estiver pronto para lançamento, um novo branch com versão será criado para cada lançamento. Isso mantém os lançamentos separados dos mastere também ajuda a adicionar ou selecionar patches para versões LTS.
Isso traz muitos benefícios, especialmente para equipes pequenas. Se você estiver trabalhando com um punhado de desenvolvedores seniores que conhece e confia com permissões de gravação para todo o repositório, integrar suas alterações o mais cedo possível pode realmente acelerar o desenvolvimento. Afinal, elimina quase toda a burocracia de constantes pull requests e merges, mas a comunicação simples com sua equipe ainda é necessária para evitar pisar no calo um do outro, e você precisa saber no que o outro está trabalhando o tempo todo.
No entanto, esta não é uma grande organização, pois depende de disciplina e bons desenvolvedores para realizá-la. É realmente ótimo para lançar produtos rapidamente ou iterar rapidamente em projetos existentes, mas assim que você adicionar mais desenvolvedores juniores ao projeto ou obter mais contribuidores de código aberto, ele começará a mostrar suas falhas.
Fluxo Git Tradicional
“Git Flow” é um fluxo de trabalho que funcionou para muitas equipes. É mais complicado do que o simples fluxo de trabalho de desenvolvimento baseado em tronco, mas oferece muitos benefícios para projetos de código aberto e grandes projetos com muitos membros da equipe.
Em uma estratégia de bifurcação do Git Flow, as bifurcações de recursos têm uma vida útil mais longa e são o foco principal da integração do dia-a-dia. As equipes trabalharão nos recursos até que estejam prontos para produção e, em seguida, passarão pelo processo de solicitação de pull para aprová-los. Pode haver qualquer número de recursos por vez, incluindo aqueles que duram o suficiente para que você precise rebaseá-los em mais novos. master compromete-se
Com o Git Flow, o acesso é mais restrito, pois a maioria dos desenvolvedores não terá permissão para mesclar diretamente develope claro que não em mastere você terá que fazer forks como o método principal para fazer alterações.
O Git Flow naturalmente deixa tempo para uma revisão de código adequada durante o processo de pull request. Ele permite que os conflitos sejam tratados por meio de relações públicas, reorganização e fusão, em vez de uma filial em constante mudança. Isso faz sentido para o código aberto, pois essas ramificações podem ser externas, mas também faz sentido em ambientes de equipes grandes ou para equipes que entregam produtos monolíticos com muitos componentes.
Um dos principais recursos desse fluxo de trabalho é o padrão de versão. Quando é hora de uma nova versão, uma ramificação separada é criada para prepará-la. Correções de bugs e patches finais são feitos aqui e depois enviados para a versão real. master branch e recebe uma tag, a partir da qual uma versão pode ser construída.
A diferença fundamental é que este master ramo fica junto develop. Os commits das ramificações de lançamento são mesclados de volta em develop, bem como quaisquer comentários. Isto faz develop sempre a ramificação mais atualizada, a partir da qual os lançamentos são feitos quando estão estáveis.
Ter essa separação facilita o gerenciamento de correções de bugs menores que precisam ser lançadas mais cedo. master combina com os lançamentos mais recentes. Uma ramificação de lançamento funciona como uma ramificação de recurso, sendo o recurso o fato de ser marcado como uma versão estável.
É claro que as constantes solicitações de pull, reorganização e mesclagem são um trabalho árduo e podem ser exaustivos se você tentar trabalhar rapidamente. Mas, assim como a escrita estática ou o teste de unidade, no final vale a pena manter as coisas organizadas e funcionando sem problemas o tempo todo.
Escolha o que é certo para você
No final das contas, é tudo uma questão de boa etiqueta de equipe, e sua equipe pode se sair bem com um histórico do Git que se parece mais com uma linha do que com um diagrama sofisticado. Se o seu projeto for pequeno, ou se você for 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 baseado em tronco ou Git Flow. No mínimo, estar ciente da organização do seu repositório ajudará a melhorar seu processo de integração.
[ad_2]
