Fluxo de trabalho de bifurcação

O fluxo de trabalho de bifurcação tem diferenças fundamentais em relação aos outros fluxos de trabalho populares do Git. Em vez de usar um único repositório do lado do servidor para funcionar como a base de código “central”, ele dá a cada desenvolvedor seu próprio repositório do lado do servidor. O que quer dizer que cada colaborador tem não apenas um, mas dois repositórios do Git: um local privado e um público do lado do servidor. O fluxo de trabalho de bifurcação é visto com mais frequência em projetos públicos de código aberto.

A principal vantagem do fluxo de trabalho de bifurcação é que as contribuições podem ser integradas sem a necessidade de todos realizarem envios para um único repositório central. Os desenvolvedores fazem envios aos seus próprios repositórios do lado do servidor e somente o mantenedor do projeto pode realizar envios ao repositório oficial. Isso permite ao mantenedor aceitar commits de qualquer desenvolvedor sem dar a ele acesso de gravação à base de código oficial.

Em geral, o fluxo de trabalho de bifurcação segue um modelo de ramificação baseado no fluxo de trabalho do Gitflow. Isso significa que ramificações completas de recursos vão ser projetadas para merge no repositório do mantenedor do projeto original. O resultado é um fluxo de trabalho distribuído que oferece uma maneira flexível para equipes grandes e orgânicas (incluindo terceiros não confiáveis) colaborarem com segurança. Isso também o torna um fluxo de trabalho ideal para projetos de código aberto.

Como funciona

Como nos outros fluxos de trabalho do Git, o fluxo de trabalho de bifurcação começa com um repositório público oficial armazenado em um servidor. Porém, quando um novo desenvolvedor quer começar a trabalhar no projeto, não é realizada a clonagem direta do repositório oficial.

Em vez disso, o repositório oficial é bifurcado para criar uma cópia dele no servidor. Essa nova cópia funciona como seu repositório público pessoal – nenhum outro desenvolvedor tem permissão para fazer envios a ela, mas é possível enviar pull das alterações dela (vamos ver por que isso é importante daqui a pouco). Após criar sua cópia do lado do servidor, o desenvolvedor executa um git clone para obter uma cópia dela em sua máquina local. Isso serve como ambiente de desenvolvimento privado, assim como nos outros fluxos de trabalho.

Quando o desenvolvedor está pronto para realizar um commit local, ele envia o commit para seu próprio repositório público, e não para o oficial. Em seguida, ele arquiva uma solicitação pull com o repositório principal, o que permite que o mantenedor do projeto saiba que uma atualização está pronta para ser integrada. A solicitação pull também serve como um tópico de discussão conveniente se houver itens com o código contribuído. Veja a seguir um exemplo passo a passo desse fluxo de trabalho.

1. Um desenvolvedor "bifurca" um repositório "oficial" do lado do servidor. Isso cria uma cópia do lado do servidor.
2. A nova cópia do lado do servidor é clonada no sistema local.
3. Um caminho remoto do Git para o repositório "oficial" é adicionado à cópia local.
4. Uma nova ramificação de recursos local é criada.
5. O desenvolvedor faz alterações na nova ramificação.
6. Novos commits são criados para as alterações.
7. A ramificação é enviada à cópia do lado do servidor do desenvolvedor.
8. O desenvolvedor abre uma solicitação pull da nova ramificação ao repositório "oficial".
9. A solicitação pull é aprovada para merge e é mesclada no repositório original do lado do servidor
   

Para integrar o recurso na base de código oficial, o mantenedor envia as alterações do contribuidor ao seu repositório local, verifica se isso não vai causar problemas ao projeto, faz merge na ramificação principal local e, em seguida, envia a ramificação principal ao repositório oficial no servidor. A contribuição agora faz parte do projeto, e outros desenvolvedores devem fazer envios do repositório oficial para sincronizar seus repositórios locais.

É importante entender que a noção de um repositório “oficial” no fluxo de trabalho de bifurcação é apenas uma convenção. Na verdade, a única coisa que torna o repositório oficial tão importante é que ele é o repositório público do mantenedor do projeto.

Bifurcação versus clonagem

É importante observar que repositórios "bifurcados" e "bifurcação" não são operações especiais. Repositórios bifurcados são criados usando o comando padrão git clone. Em geral, são "cópias do lado do servidor" e, via de regra, gerenciados e hospedados por um serviço Git de terceiros, como o Bitbucket. Não existe um comando exclusivo do Git para criar repositórios bifurcados. Uma operação de clonagem é essencialmente uma cópia de um repositório e seu histórico.

Ramificação no fluxo de trabalho de bifurcação

Todos esses repositórios públicos pessoais são, na verdade, apenas uma maneira conveniente de compartilhar ramificações com outros desenvolvedores. Todos ainda devem utilizar ramificações para isolar recursos individuais, assim como no fluxo de trabalho de ramificação de recurso e no fluxo de trabalho do Gitflow. A única diferença é como as ramificações são compartilhadas. No fluxo de trabalho de bifurcação, elas são enviadas ao repositório local de outro desenvolvedor, já nos fluxos de trabalho de ramificação de recurso e do Gitflow, elas são enviadas ao repositório oficial.

Bifurque um repositório

Todos os novos desenvolvedores de um projeto de fluxo de trabalho de bifurcação precisam bifurcar o repositório oficial. Como dito antes, a bifurcação é apenas uma operação padrão do git clone. É possível fazer isso realizando o SSH no servidor e executando o git clone para copiá-lo para outro local no servidor. Serviços populares de hospedagem do Git, como o Bitbucket, oferecem recursos de bifurcação de repositório que automatizam essa etapa.

Clonar a bifurcação

Em seguida, cada desenvolvedor precisa clonar seu próprio repositório bifurcado público. Isso pode ser feito com o conhecido comando git clone.

Supondo o uso do Bitbucket para hospedar esses repositórios, os desenvolvedores em um projeto devem ter sua própria conta do Bitbucket e clonar sua cópia bifurcada do repositório com:

git clone https://user@bitbucket.org/user/repo.git

Adicionar um remoto

Enquanto outros fluxos de trabalho do Git utilizam um único remoto de origem que aponta para o repositório central, o fluxo de trabalho de bifurcação requer dois remotos: um para o repositório oficial e outro para o repositório pessoal do lado do servidor do desenvolvedor. Embora seja possível chamar esses remotos como quiser, uma convenção comum é utilizar origin como o remoto do seu repositório bifurcado (isso é criado de modo automático ao executar o comando git clone) e upstream para o repositório oficial.

git remote add upstream https://bitbucket.org/maintainer/repo

Vai ser preciso criar o remoto upstream usando o comando acima. Isso vai permitir que você mantenha seu repositório local atualizado com facilidade à medida que o projeto oficial faz progressos. Observe que, se o repositório upstream tiver a autenticação habilitada (ou seja, não for de código aberto), vai ser necessário fornecer um nome de usuário, da seguinte forma:

git remote add upstream https://user@bitbucket.org/maintainer/repo.git

Isso exige que os usuários forneçam uma senha válida antes de clonar ou enviar pull da base de código oficial.

Trabalhando em uma ramificação: criação e envio de alterações

Na cópia local do desenvolvedor do repositório bifurcado, ele pode editar o código, fazer commit das alterações e criar ramificações como em outros fluxos de trabalho do Git:

 git checkout -b some-feature # Edite alguns códigos git commit -a -m "Adicione o primeiro rascunho de alguma funcionalidade"

Todas as alterações ficam privadas até que sejam enviadas ao repositório público. E, se o projeto oficial avançou, ele pode acessar os novos commits com o comando git pull:

 git pull upstream main

Como os desenvolvedores devem trabalhar em uma ramificação de recurso dedicada, em geral, deve resultar em um merge de avanço rápido.

Fazendo uma solicitação pull

Quando um desenvolvedor estiver pronto para compartilhar seu novo recurso, ele vai precisar fazer duas coisas. Primeiro, vai ser necessário disponibilizar sua contribuição aos outros desenvolvedores por meio do seu envio ao repositório público. O remoto de origem já deve estar configurado, portanto, tudo o que ele precisa fazer é:

git push origin feature-branch

Isso diverge dos outros fluxos de trabalho, pois o remoto de origem aponta para o repositório pessoal do lado do servidor do desenvolvedor, não para a base de código principal.

Segundo, ele precisa notificar o mantenedor do projeto que quer mesclar seu recurso na base de código oficial. O Bitbucket fornece um botão “pull request” que leva a um formulário solicitando que você especifique em qual ramificação quer realizar o merge no repositório oficial. Em geral, você vai querer integrar sua ramificação de recurso na ramificação principal do remoto upstream.

Resumo

Para recapitular, o fluxo de trabalho de bifurcação é muito usado em projetos públicos de código aberto. A bifurcação é uma operação do git clone executada em uma cópia do servidor de um repositório de projetos. Um fluxo de trabalho de bifurcação é usado com frequência em conjunto com um serviço de hospedagem do Git, como o Bitbucket. Um exemplo de alto nível de um fluxo de trabalho de bifurcação é:

1. Você quer contribuir com uma biblioteca de código aberto hospedada em bitbucket.org/userA/open-project
2. Usando o Bitbucket, você cria uma bifurcação do repositório para bitbucket.org/YourName/open-project
3. Em seu sistema local, você executa o git clone em https://bitbucket.org/YourName/open-project para obter uma cópia local do repositório
4. Você cria uma nova ramificação de recurso em seu repositório local
5. O trabalho é feito para concluir o novo recurso e o git commit é executado para salvar as alterações
6. Em seguida, você envia a nova ramificação de recurso ao seu repositório bifurcado remoto
7. Usando o Bitbucket, você abre uma solicitação pull para a nova ramificação no repositório original em bitbucket.org/userA/open-project
   

O fluxo de trabalho de bifurcação ajuda o mantenedor de um projeto a abrir o repositório para contribuições de qualquer desenvolvedor sem ter que gerenciar, de forma manual, as configurações de autorização para cada colaborador individual. Isso dá ao mantenedor um fluxo de trabalho que consiste mais no estilo "enviar pull". Mais utilizado em projetos de código aberto, o fluxo de trabalho de bifurcação também pode ser aplicado a fluxos de trabalho de negócios privados para dar mais controle autoritário sobre o que é mesclado em uma versão. Isso pode ser útil em equipes com gerentes de implementação ou ciclos de lançamento rigorosos.

Não tem certeza de qual fluxo de trabalho é o ideal para você? Consulte nossa abrangente página de comparação de fluxo de trabalho do Git.