Explore o fluxo de trabalho da bifurcação

Concluído

O fluxo de trabalho de bifurcação é fundamentalmente diferente de outros fluxos de trabalho populares do Git.

Em vez de usar um único repositório do lado do servidor para atuar como a base de código "central", ele dá a cada desenvolvedor seu repositório do lado do servidor.

Isso significa que cada contribuidor tem dois repositórios Git:

  • Um local privado.
  • Um servidor público.

O fluxo de trabalho de bifurcação é mais frequentemente visto 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 enviarem para um único repositório central.

Os desenvolvedores enviam por push para seus repositórios do lado do servidor, e apenas o mantenedor do projeto pode enviar por push para o repositório oficial.

Ele permite que o mantenedor aceite commits de qualquer desenvolvedor sem dar-lhes acesso por escrito à base de código oficial.

O fluxo de trabalho de bifurcação normalmente será destinado à fusão no repositório do mantenedor do projeto original.

O resultado é um fluxo de trabalho distribuído que fornece 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.

Mas quando um novo desenvolvedor quer começar a trabalhar no projeto, ele não clona diretamente o repositório oficial.

Em vez disso, eles bifurcam o repositório oficial para criar uma cópia dele no servidor.

Essa nova cópia serve como seu repositório público pessoal — nenhum outro desenvolvedor pode enviá-la por push, mas eles podem extrair alterações dela (veremos por que isso é necessário em um momento).

Depois de criar sua cópia do lado do servidor, o desenvolvedor faz um clone do git para obter uma cópia dele em sua máquina local.

Ele serve como seu ambiente de desenvolvimento privado, assim como nos outros fluxos de trabalho.

Quando estiverem prontos para publicar uma confirmação local, enviam a confirmação para o repositório público, não para o oficial.

Em seguida, eles arquivam 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 thread de discussão conveniente se houver problemas com o código contribuído.

Segue-se um exemplo passo-a-passo deste fluxo de trabalho:

  • Um desenvolvedor 'bifurca' um repositório 'oficial' do lado do servidor. Ele cria sua cópia do lado do servidor.
  • A nova cópia do lado do servidor é clonada para o sistema local.
  • Um caminho remoto Git para o repositório 'oficial' é adicionado ao clone local.
  • Uma nova ramificação de recurso local é criada.
  • O desenvolvedor faz alterações na nova ramificação.
  • Novas confirmações são criadas para as alterações.
  • A ramificação é enviada para a cópia do lado do servidor do desenvolvedor.
  • O desenvolvedor abre uma solicitação pull da nova ramificação para o repositório 'oficial'.
  • A solicitação pull é aprovada para mesclagem e mesclada no repositório original do servidor.

Para integrar o recurso na base de código oficial:

  • O mantenedor puxa as alterações do colaborador para seu repositório local.
  • Verifica se ele não quebra o projeto.
  • Mescla-o em sua filial principal local.
  • Envia a ramificação principal para o repositório oficial no servidor.

A contribuição agora faz parte do projeto, e outros desenvolvedores devem extrair do repositório oficial para sincronizar seus repositórios locais.

É essencial entender que a noção de um repositório "oficial" no fluxo de trabalho de bifurcação é meramente uma convenção.

A única coisa que torna o repositório oficial, tão oficial é que é o repositório do mantenedor do projeto.

Forking vs. clonagem

É essencial notar que repositórios "bifurcados" e "bifurcação" não são operações especiais.

Os repositórios bifurcados são criados usando o comando git clone padrão. Os repositórios bifurcados geralmente são "clones do lado do servidor" gerenciados e hospedados por um provedor de serviços Git, como o Azure Repos.

Não há um comando Git exclusivo para criar repositórios bifurcados.

Uma operação de clone é essencialmente uma cópia de um repositório e seu histórico.