Fluxo de trabalho de bifurcação

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 ao clone local.

4. Uma nova ramificação de recurso 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 pull request da nova ramificação ao repositório "oficial".

9. A pull request é aprovada para mesclagem e é mesclada no repositório original do lado do servidor

Para integrar a característica 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.

É 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 é, em essência, a cópia de um repositório e seu histórico.

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 características individuais, assim como no fluxo de trabalho de ramificação de característica 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 características e do Gitflow, elas são enviadas ao repositório oficial.

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 características de bifurcação de repositório que automatizam essa etapa.

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 características de bifurcação de repositório que automatizam essa etapa.

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:

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.

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:

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

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:

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:

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

Quando um desenvolvedor estiver pronto para compartilhar sua nova característica, 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 é:

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 sua característica 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 característica na ramificação principal do remoto upstream.

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. No 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 no repositório local

5. O trabalho é feito para concluir a nova função, e o git commit é executado para salvar as alterações

6. Em seguida, você envia a nova ramificação de característica ao seu repositório bifurcado remoto

7. Usando o Bitbucket, você abre uma pull request 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.