Para desenvolver software de qualidade, precisamos 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 permitem localizar 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 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 arquivos modificados manualmente para incorporar o trabalho de vários desenvolvedores no mesmo projeto.

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

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

Vamos dar uma olhada neles:

Geração	Operações	Simultaneidade	Networking	Exemplos
Primeiro	Em um único arquivo apenas	Fechaduras	Centralizado	RCS
Segundo	Em vários arquivos	Unir antes de confirmar	Centralizado	Subversion, CVS
Terceiro	Em vários arquivos	Confirmar antes de mesclar	Distribuído	Git, Mercurial

Percebemos 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 inovadoras foi a mudança do bloqueio de arquivos para a fusão das alterações. Permitiu que os programadores trabalhassem com mais eficiência.

Outra melhoria considerável foi a introdução de sistemas distribuídos. Git foi um dos primeiros ferramentas para incorporar esta filosofia. Literalmente, permitiu que o mundo do código aberto prosperasse. O Git permite que os desenvolvedores copiem todo o repositório, em uma operação chamada forking, e introduzam as alterações desejadas sem a necessidade de se preocupar com conflitos de mesclagem.

Posteriormente, 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 mudanças de outros repositórios, ele pode 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

Hoje em dia, o sistema de controle de versão mais popular é definitivamente o Git, com uma participação de mercado de cerca de 70 por cento em 2016.

Git foi popularizado com o surgimento do Linux e a cena do código aberto em geral. GitHub , atualmente o armazenamento online mais popular para projetos públicos, também contribuiu consideravelmente para sua prevalência. Devemos a introdução de solicitações pull 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 por ele com o projeto principal. Inclui um processo de revisão dessas mudanças. Os revisores podem inserir comentários em tudo que acham que pode ser melhorado ou considerado desnecessário.

Depois de receber 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 Fluxo Git e desenvolvimento baseado em tronco . Muitas vezes, as pessoas estão familiarizadas com um desses estilos e podem negligenciar o outro.

Vamos dar uma olhada mais de perto ambos e aprender como e quando devemos usá-los.

Fluxo Git

No modelo de desenvolvimento de fluxo Git, você tem um branch de desenvolvimento principal com acesso estrito a ele. Geralmente é chamado de develop ramo.

Os desenvolvedores criam branches de recursos a partir deste branch principal e trabalham neles. Depois de concluídos, eles criam solicitações pull. Em solicitações pull, outros desenvolvedores comentam sobre as mudanças e podem ter discussões, geralmente demoradas.

Leva algum tempo para chegar a um acordo sobre uma versão final das mudanças. Depois de acordado, a solicitação pull é aceita e mesclada com o branch principal. Assim que for decidido que o branch principal atingiu maturidade suficiente para ser lançado, um branch separado é criado para preparar a versão final. O aplicativo deste branch é testado e as 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 master ramificar e marcá-lo com a versão de lançamento. Enquanto isso, novos recursos podem ser desenvolvidos no develop ramo.

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

Uma das vantagens do fluxo Git é o controle rígido. Somente desenvolvedores autorizados podem aprovar mudanças depois de analisá-las de perto. Ele garante a qualidade do código e ajuda a eliminar bugs antecipadamente.

No entanto, é preciso lembrar que também pode ser uma grande desvantagem. Ele cria um funil que retarda o desenvolvimento de software. Se a velocidade é sua principal preocupação, então pode ser um problema sério. Os recursos desenvolvidos separadamente podem criar ramos de longa duração que podem ser difíceis de combinar com o projeto principal.

Além disso, as solicitações de pull focam a revisão do 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 otimização prematura já que é sempre possível implementar algo para um desempenho mais rápido.

Além disso, as solicitações pull podem levar a um microgerenciamento extenso, em que 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 seu tempo e habilidades. Também pode desmotivar severamente os desenvolvedores.

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

Prós e contras do fluxo Git

Como você pode ver, fazer solicitações de pull 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 do código aberto e funciona melhor lá. Como todos podem contribuir, você deseja ter acesso estrito a todas as alterações. Você quer ser capaz de verificar cada linha de código, porque, francamente, você não pode confiar nas pessoas que contribuem. 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, deve 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 solicitações pull têm controle estrito sobre alterações recorrentes, para que possam 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 carregamento. Esse tipo de otimização requer mudanças muito precisas. Normalmente, o tempo não é uma restrição, então este estilo funciona bem aqui. Além do mais, grandes empresas são uma ótima opção para esse estilo. Eles precisam controlar cada mudança de perto, uma vez 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 fluxo do Git não é para você. Provavelmente, você deseja criar um produto mínimo viável rapidamente. Fazer solicitações pull cria um grande gargalo que retarda a equipe inteira drasticamente. Você simplesmente não pode pagar. O problema com o fluxo do Git é o fato de que as solicitações de pull podem levar muito tempo. Simplesmente não é possível fornecer um desenvolvimento rápido dessa forma.

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

• Quando você trabalha principalmente com desenvolvedores sênior.
  Se sua equipe consiste principalmente de desenvolvedores seniores que trabalharam uns com os outros por um longo período de tempo, então você realmente não precisa do microgerenciamento de solicitação de pull mencionado acima. Você confia em seus desenvolvedores e sabe que eles são profissionais. Deixe-os fazer seu trabalho e não os atrapalhe 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 filial com acesso aberto a ela. Muitas vezes é simplesmente o master ramo. Eles confirmam o código e o executam. É super simples.

Em alguns casos, eles criam ramificações de recursos de curta duração. Depois que o código em sua ramificação é compilado e aprovado em todos os testes, eles o mesclam diretamente para master. Ele garante que o desenvolvimento seja verdadeiramente contínuo e evita que os desenvolvedores criem conflitos de mesclagem que são 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, as 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 ter experiência para que você saiba que eles não reduzirão a qualidade do código-fonte.

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

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

Prós e contras do desenvolvimento baseado em tronco

Vamos dar uma olhada em ambos os lados do custo - os melhores e os piores cenários.

Quando o desenvolvimento baseado em tronco funciona melhor?

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

• Quando você precisa iterar rapidamente.
  Depois de chegar à primeira versão de seu produto e perceber que seus clientes querem algo diferente, não pense duas vezes e use esse estilo para tomar 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 sênior.
  Se sua equipe consiste principalmente de desenvolvedores sênior, 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 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 tronco pode causar problemas?

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

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

• Quando você estabelece um produto ou gerencia grandes equipes.
  Se você já tem um produto próspero ou gerencia grandes equipes em uma grande empresa, o fluxo Git pode ser uma ideia melhor. Você deseja ter 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 carregamento 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 de maneira adequada.

O fluxo Git gerencia todas as mudanças por meio de solicitações pull. Ele fornece controle de acesso estrito para 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 extensa microgestão, disputas envolvendo políticas de escritório e desenvolvimento significativamente mais lento.

O desenvolvimento baseado em tronco dá aos programadores autonomia total 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. Oferece excelente velocidade de desenvolvimento de software e reduz processos. Esses fatores o tornam perfeito ao criar novos produtos ou direcionar um aplicativo existente em uma direção totalmente nova. Ele 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 fluxo Git é uma alternativa muito melhor.

Munido com esse conhecimento, espero que você seja capaz de escolher o fluxo de trabalho que se adapta perfeitamente ao seu projeto.

Relacionado: Fluxo Git aprimorado explicado

Compreender o básico

O que é um tronco no software?

No mundo do desenvolvimento de software, 'tronco' significa principal ramo de desenvolvimento em um sistema de controle de versão. É a base de um projeto, onde todas as melhorias estão sendo mescladas.

O que é ramificação e fusão de código?

Ramificações são criadas a partir do projeto base, a fim de desenvolver um novo recurso, corrigir um bug ou simplesmente fazer alguma refatoração. Eles evitam que os desenvolvedores de software atrapalhem uns aos outros e permitem que trabalhem em paralelo. Depois que uma alteração é concluída e testada, o branch é mesclado de volta ao tronco.

O que é uma ramificação no controle de versão?

Uma ramificação em um sistema de controle de versão é uma duplicata do projeto base. É criado para que as mudanças possam acontecer em paralelo em outros ramos. Essencialmente, ele resolve o problema de trabalhar nos mesmos arquivos ao mesmo tempo.

O que é um branch de recursos?

O branch de recursos tem um propósito claro e altamente focado - adicionar funcionalidade específica a um projeto. Ele não deve conter nenhuma outra alteração que corrige bugs, introduza outros recursos ou faça parte de uma refatoração.

O que é um sistema de controle de versão?

Os sistemas de controle de versão rastreiam as alterações que ocorrem nos arquivos de um projeto. Eles podem ser recuperados ou revisados ​​posteriormente. É extremamente útil para trazer de volta versões anteriores também. Isso permite que os desenvolvedores encontrem bugs com menos esforço, pois eles podem ver e rastrear todas as alterações à medida que ocorrem.