Desenvolvimento baseado em tronco vs. Git Flow

Para desenvolver um software de qualidade, precisamos ser capazes de rastrear todas as alterações e revertê-las, se necessário. Os sistemas de controle de versão cumprem essa função rastreando o histórico do projeto e ajudando a mesclar as alterações feitas por várias pessoas. Eles aceleram muito o trabalho e nos dão a capacidade de encontrar bugs com mais facilidade.

Além disso, trabalhar em equipes distribuídas é possível principalmente graças a essas ferramentas. Eles permitem que várias pessoas trabalhem em diferentes partes de um projeto ao mesmo tempo e, posteriormente, unam seus resultados em um único produto. Vamos dar uma olhada mais de perto nos sistemas de controle de versão e explicar como o desenvolvimento baseado em tronco e o fluxo Git surgiram.

Como os sistemas de controle de versão mudaram o mundo

Antes da criação dos sistemas de controle de versão, as pessoas dependiam do backup manual das versões anteriores dos projetos. Eles estavam copiando manualmente os arquivos modificados para incorporar o trabalho de vários desenvolvedores no mesmo projeto.

Custou muito tempo, espaço no disco rígido e dinheiro.

Quando olhamos para a história, podemos distinguir amplamente três gerações de software de controle de versão.

Vamos dar uma olhada neles:

Notamos que à medida que os sistemas de controle de versão amadurecem, há uma tendência de aumentar a capacidade de trabalhar em projetos em paralelo.

Uma das mudanças mais revolucionárias foi a mudança do bloqueio de arquivos para a mesclagem de alterações. Permitiu que os programadores trabalhassem com mais eficiência.

Outra melhoria considerável foi a introdução de sistemas distribuídos. O Git foi uma das primeiras ferramentas a incorporar essa filosofia. Ele literalmente permitiu que o mundo do código aberto florescesse. O Git permite que os desenvolvedores copiem todo o repositório, em uma operação chamada bifurcação, e introduzam as alterações desejadas sem precisar se preocupar com conflitos de mesclagem.

Mais tarde, eles podem iniciar uma solicitação pull para mesclar suas alterações no projeto original. Se o desenvolvedor inicial não estiver interessado em incorporar essas alterações de outros repositórios, ele poderá transformá-las em projetos separados por conta própria. Tudo isso é possível graças ao fato de que não existe o conceito de armazenamento central.

Estilos de Desenvolvimento

Atualmente, o sistema de controle de versão mais popular é definitivamente o Git, com uma participação de mercado de cerca de 70% em 2016.

O Git foi popularizado com a ascensão do Linux e da cena de código aberto em geral. O GitHub, atualmente o armazenamento online mais popular para projetos públicos, também contribuiu consideravelmente para sua prevalência. Devemos a introdução de pull requests fáceis de gerenciar ao Git.

Simplificando, as solicitações pull são solicitações criadas por um desenvolvedor de software para combinar as alterações criadas com o projeto principal. Inclui um processo de revisão dessas mudanças. Os revisores podem inserir comentários em cada parte que eles acham que podem ser melhorados ou que consideram desnecessários.

Depois de receber o feedback, o criador pode responder a ele, criando uma discussão ou simplesmente segui-lo e alterar seu código de acordo.

Git é apenas uma ferramenta. Você pode usá-lo de muitas maneiras diferentes. Atualmente, dois estilos de desenvolvimento mais populares que você pode encontrar são o fluxo Git e o desenvolvimento baseado em tronco. Muitas vezes, as pessoas estão familiarizadas com um desses estilos e podem negligenciar o outro.

Vamos dar uma olhada em ambos e aprender como e quando devemos usá-los.

Git Flow

No modelo de desenvolvimento de fluxo do Git, você tem uma ramificação de desenvolvimento principal com acesso restrito a ela. É muitas vezes chamado de ramo de develop .

Os desenvolvedores criam ramificações de recursos dessa ramificação principal e trabalham nelas. Depois de concluídos, eles criam pull requests. Em pull requests, outros desenvolvedores comentam sobre mudanças e podem ter discussões, muitas vezes bem longas.

Leva algum tempo para concordar com uma versão final das alterações. Uma vez acordado, o pull request é aceito e mesclado ao branch principal. Uma vez decidido que a ramificação principal atingiu maturidade suficiente para ser lançada, uma ramificação separada é criada para preparar a versão final. O aplicativo deste branch é testado e correções de bugs são aplicadas até o momento em que ele está pronto para ser publicado para os usuários finais. Feito isso, mesclamos o produto final ao branch master e o marcamos com a versão de lançamento. Enquanto isso, novos recursos podem ser desenvolvidos na ramificação de develop .

Abaixo, você pode ver o diagrama de fluxo do Git, descrevendo um fluxo de trabalho geral:

Uma das vantagens do fluxo Git é o controle estrito. Somente desenvolvedores autorizados podem aprovar alterações depois de analisá-las de perto. Ele garante a qualidade do código e ajuda a eliminar bugs antecipadamente.

No entanto, você precisa lembrar que também pode ser uma grande desvantagem. Ele cria um funil que atrasa o desenvolvimento de software. Se a velocidade é sua principal preocupação, pode ser um problema sério. Os recursos desenvolvidos separadamente podem criar ramificações duradouras que podem ser difíceis de combinar com o projeto principal.

Além disso, as solicitações pull focam a revisão de código apenas no novo código. Em vez de olhar para o código como um todo e trabalhar para melhorá-lo como tal, eles verificam apenas as alterações introduzidas recentemente. Em alguns casos, eles podem levar a uma otimização prematura, pois sempre é possível implementar algo para ter um desempenho mais rápido.

Além disso, pull requests podem levar a um microgerenciamento extensivo, onde o desenvolvedor líder literalmente gerencia cada linha de código. Se você tem desenvolvedores experientes em quem pode confiar, eles podem lidar com isso, mas você pode estar desperdiçando o tempo e as habilidades deles. Também pode desmotivar severamente os desenvolvedores.

Em organizações maiores, a política do escritório durante os pull requests é outra preocupação. É concebível que as pessoas que aprovam pull requests possam usar sua posição para bloquear propositalmente certos desenvolvedores de fazer qualquer alteração na base de código. Eles podem fazer isso devido à falta de confiança, enquanto alguns podem abusar de sua posição para acertar contas pessoais.

Prós e contras do Git Flow

Como você pode ver, fazer pull requests nem sempre é a melhor escolha. Eles devem ser usados ​​apenas quando apropriado.

Quando o Git Flow funciona melhor?

• Quando você executa um projeto de código aberto.
  Esse estilo vem do mundo de código aberto e funciona melhor lá. Como todos podem contribuir, você deseja ter acesso muito estrito a todas as alterações. Você quer poder verificar cada linha de código, porque francamente você não pode confiar nas pessoas contribuindo. Normalmente, esses não são projetos comerciais, então a velocidade de desenvolvimento não é uma preocupação.

• Quando você tem muitos desenvolvedores juniores.
  Se você trabalha principalmente com desenvolvedores juniores, então você quer ter uma maneira de verificar o trabalho deles de perto. Você pode dar a eles várias dicas sobre como fazer as coisas com mais eficiência e ajudá-los a melhorar suas habilidades mais rapidamente. As pessoas que aceitam pull requests têm controle estrito sobre as alterações recorrentes para evitar a deterioração da qualidade do código.

  

• Quando você tem um produto estabelecido.
  Esse estilo também parece funcionar bem quando você já tem um produto de sucesso. Nesses casos, o foco geralmente está no desempenho do aplicativo e nos recursos de carga. Esse tipo de otimização requer mudanças muito precisas. Normalmente, o tempo não é uma restrição, então esse estilo funciona bem aqui. Além disso, grandes empresas são uma ótima opção para esse estilo. Eles precisam controlar cada mudança de perto, já que não querem quebrar seu investimento multimilionário.

Quando o Git Flow pode causar problemas?

• Quando você está apenas começando.
  Se você está apenas começando, o Git flow não é para você. É provável que você queira criar um produto mínimo viável rapidamente. Fazer pull requests cria um gargalo enorme que diminui drasticamente a velocidade de toda a equipe. Você simplesmente não pode pagar. O problema com o fluxo do Git é o fato de que as solicitações pull podem levar muito tempo. Simplesmente não é possível fornecer um desenvolvimento rápido dessa maneira.

• Quando você precisa iterar rapidamente.
  Depois de chegar à primeira versão do seu produto, você provavelmente precisará dinamizá-lo algumas vezes para atender às necessidades de seus clientes. Novamente, várias ramificações e solicitações pull reduzem drasticamente a velocidade de desenvolvimento e não são recomendadas nesses casos.

• Quando você trabalha principalmente com desenvolvedores seniores.
  Se sua equipe consiste principalmente de desenvolvedores seniores que trabalharam uns com os outros por um longo período de tempo, você realmente não precisa do microgerenciamento de pull request mencionado acima. Você confia em seus desenvolvedores e sabe que eles são profissionais. Deixe-os fazer seu trabalho e não os atrase com toda a burocracia de fluxo do Git.

Fluxo de trabalho de desenvolvimento baseado em tronco

No modelo de desenvolvimento baseado em tronco, todos os desenvolvedores trabalham em uma única ramificação com acesso aberto a ela. Muitas vezes é simplesmente o branch master . Eles confirmam o código para ele e o executam. É super simples.

Em alguns casos, eles criam ramificações de recursos de curta duração. Depois que o código em seu branch compila e passa em todos os testes, eles o mesclam diretamente para master . Ele garante que o desenvolvimento seja realmente contínuo e evita que os desenvolvedores criem conflitos de mesclagem difíceis de resolver.

Vamos dar uma olhada no fluxo de trabalho de desenvolvimento baseado em tronco.

A única maneira de revisar o código em tal abordagem é fazer uma revisão completa do código-fonte. Normalmente, discussões longas são limitadas. Ninguém tem controle estrito sobre o que está sendo modificado na base do código-fonte - é por isso que é importante ter um estilo de código aplicável. Os desenvolvedores que trabalham nesse estilo devem ser experientes para que você saiba que eles não irão diminuir a qualidade do código-fonte.

Esse estilo de trabalho pode ser ótimo quando você trabalha com uma equipe de desenvolvedores de software experientes. Permite-lhes introduzir novas melhorias rapidamente e sem burocracia desnecessária. Também mostra que você confia neles, pois eles podem introduzir código diretamente no branch master . Os desenvolvedores neste fluxo de trabalho são muito autônomos - eles estão entregando diretamente e são verificados nos resultados finais no produto de trabalho. Definitivamente, há muito menos microgerenciamento e possibilidade de política de escritório nesse método.

Se, por outro lado, você não tem uma equipe experiente ou não confia neles por algum motivo, você não deve usar esse método - você deve escolher o fluxo Git. Isso vai lhe poupar preocupações desnecessárias.

Prós e contras do desenvolvimento baseado em troncos

Vamos examinar mais de perto os dois lados do custo - os melhores e os piores cenários.

Quando o desenvolvimento baseado em troncos funciona melhor?

• Quando você está apenas começando.
  Se você está trabalhando em seu produto mínimo viável, esse estilo é perfeito para você. Oferece a máxima velocidade de desenvolvimento com o mínimo de formalidade. Como não há pull requests, os desenvolvedores podem entregar novas funcionalidades na velocidade da luz. Apenas certifique-se de contratar programadores experientes.

• Quando você precisa iterar rapidamente.
  Depois de chegar à primeira versão do seu produto e perceber que seus clientes querem algo diferente, não pense duas vezes e use esse estilo para mudar para uma nova direção. Você ainda está na fase de exploração e precisa ser capaz de mudar seu produto o mais rápido possível.

• Quando você trabalha principalmente com desenvolvedores seniores.
  Se sua equipe consiste principalmente de desenvolvedores seniores, você deve confiar neles e deixá-los fazer o trabalho deles. Esse fluxo de trabalho lhes dá a autonomia de que precisam e permite que eles exerçam o domínio de sua profissão. Apenas dê a eles um propósito (tarefas a serem cumpridas) e observe como seu produto cresce.

Quando o desenvolvimento baseado em troncos pode causar problemas?

• Quando você executa um projeto de código aberto.
  Se você estiver executando um projeto de código aberto, o Git flow é a melhor opção. Você precisa de um controle muito estrito sobre as alterações e não pode confiar nos contribuidores. Afinal, qualquer pessoa pode contribuir. Incluindo trolls online.

• Quando você tem muitos desenvolvedores juniores.
  Se você contrata principalmente desenvolvedores juniores, é uma ideia melhor controlar rigidamente o que eles estão fazendo. Solicitações de pull estritas os ajudarão a melhorar suas habilidades e encontrarão possíveis bugs mais rapidamente.

• Quando você estabeleceu um produto ou gerencia grandes equipes.
  Se você já tem um produto próspero ou gerencia grandes equipes em uma grande empresa, o Git flow pode ser uma ideia melhor. Você quer ter um controle estrito sobre o que está acontecendo com um produto bem estabelecido que vale milhões de dólares. Provavelmente, o desempenho do aplicativo e os recursos de carga são as coisas mais importantes. Esse tipo de otimização requer mudanças muito precisas.

Use a ferramenta certa para o trabalho certo

Como eu disse antes, o Git é apenas uma ferramenta. Como qualquer outra ferramenta, ela precisa ser usada adequadamente.

O fluxo do Git gerencia todas as alterações por meio de pull requests. Ele fornece controle de acesso rigoroso a todas as alterações. É ótimo para projetos de código aberto, grandes empresas, empresas com produtos estabelecidos ou uma equipe de desenvolvedores juniores inexperientes. Você pode verificar com segurança o que está sendo introduzido no código-fonte. Por outro lado, pode levar a um microgerenciamento extenso, disputas envolvendo política de escritório e desenvolvimento significativamente mais lento.

O desenvolvimento baseado em troncos dá aos programadores total autonomia e expressa mais fé neles e em seu julgamento. O acesso ao código-fonte é gratuito, então você realmente precisa confiar em sua equipe. Fornece excelente velocidade de desenvolvimento de software e reduz processos. Esses fatores o tornam perfeito ao criar novos produtos ou dinamizar um aplicativo existente em uma direção totalmente nova. Faz maravilhas se você trabalha principalmente com desenvolvedores experientes.

Ainda assim, se você trabalha com programadores juniores ou pessoas em quem não confia totalmente, o Git flow é uma alternativa muito melhor.

Equipado com esse conhecimento, espero que você consiga escolher o fluxo de trabalho que combina perfeitamente com seu projeto.