Explorar o fluxo de trabalho de fork
O fluxo de trabalho de criação de fork é fundamentalmente diferente de outros fluxos de trabalho do Git populares.
Em vez de usar um só repositório do lado do servidor para atuar como a base de código "central", ele fornece a cada desenvolvedor um repositório do lado do servidor.
Isso significa que cada colaborador tem dois repositórios Git:
- Um local privado.
- Um público do lado do servidor.
O fluxo de trabalho de criação de fork geralmente é visto em projetos públicos de código aberto.
A principal vantagem do fluxo de trabalho de criação de fork é que as contribuições podem ser integradas sem que todos precisem fazer o envio por push a um só repositório central.
Os desenvolvedores fazem o envio por push aos próprios repositórios do lado do servidor e apenas o mantenedor do projeto pode fazer o envio por push ao repositório oficial.
Isso permite que o mantenedor aceite confirmações de qualquer desenvolvedor sem permitir acesso de gravação à base de código oficial.
O fluxo de trabalho de bifurcação normalmente será destinado à mesclagem no repositório do mantenedor do projeto original.
O resultado é um fluxo de trabalho distribuído que oferece um modo 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 ele funciona
Como nos outros fluxos de trabalho do Git, o fluxo de trabalho de criação de fork 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, ele bifurca o repositório oficial para criar uma cópia dele no servidor.
Essa nova cópia funciona como o repositório público pessoal. Nenhum outro desenvolvedor pode fazer envio por push a ele, mas pode efetuar pull das alterações dele (veremos por que isso é necessário em instantes).
Depois de criar uma cópia do lado do servidor, o desenvolvedor faz um git clone para obter uma cópia dele no computador local.
Ele funciona como o ambiente de desenvolvimento privado, assim como nos outros fluxos de trabalho.
Quando o desenvolvedor está pronto para publicar um commit local, ele envia o commit por push ao próprio repositório público, não para o oficial.
Em seguida, arquiva uma solicitação de pull no repositório principal, o que permite que o mantenedor do projeto saiba que uma atualização está pronta para ser integrada.
A solicitação de pull também funciona como um thread de discussão conveniente quando há problemas com o código contribuído.
Veja a seguir um exemplo passo a passo desse fluxo de trabalho:
- Um desenvolvedor 'faz fork' de um repositório do lado do servidor 'oficial'. Isso cria a cópia do lado do servidor.
- A nova cópia do lado do servidor é clonada no sistema local.
- Um caminho remoto do Git para o repositório 'oficial' é adicionado ao clone local.
- Um novo branch de recurso local é criado.
- O desenvolvedor faz alterações no novo branch.
- Novos commits são criados para as alterações.
- O branch é enviado por push para a cópia do lado do servidor do desenvolvedor.
- O desenvolvedor abre uma solicitação de pull do novo branch para o repositório 'oficial'.
- A solicitação de pull é aprovada para mesclagem e é mesclada no repositório original do lado do servidor.
Para integrar o recurso à base de código oficial:
- O mantenedor efetua pull das alterações do colaborador no repositório local.
- Ele verifica se essa ação não interrompe o projeto.
- Mescla-o no branch principal local.
- Envia por push o branch principal para o repositório oficial no servidor.
A contribuição agora faz parte do projeto e outros desenvolvedores devem efetuar pull do repositório oficial para sincronizar os repositórios locais.
É essencial entender que a noção de um repositório "oficial" no fluxo de trabalho de criação de fork é meramente uma convenção.
A única coisa que torna o repositório oficial realmente oficial é que ele é o repositório do mantenedor do projeto.
Criação de fork versus clonagem
É essencial observar que os repositórios "bifurcados" e a "criação de fork" 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 do Git, como o Azure Repos.
Não há nenhum comando do Git exclusivo para criar repositórios bifurcados.
Uma operação de clonagem é essencialmente uma cópia de um repositório e do respectivo histórico.