Implementar o fluxo de trabalho de fork
Um fork é uma cópia de um repositório. Ao criar fork em um repositório você pode experimentar alterações livremente, sem afetar o projeto original.
Normalmente, os forks são usados para propor alterações ao projeto de outra pessoa. Ou usar o projeto de outra pessoa como ponto de partida para sua ideia.
Um fork é uma cópia completa de um repositório, incluindo todos os arquivos, commits e branches (opcionalmente).
Os forks são uma ótima forma de dar suporte a um fluxo de trabalho de Inner Source: você pode criar um fork para sugerir alterações quando não tiver permissão para gravar diretamente no projeto original.
Quando você estiver pronto para compartilhar as alterações, será fácil contribuir com elas usando solicitações de pull.
O que há em um fork?
Um fork começa com todo o conteúdo de seu repositório upstream (original).
Você pode incluir todos os branches ou limitá-los apenas ao branch padrão ao criar um fork.
Nenhuma das permissões, políticas ou pipelines de build é aplicada.
O novo fork atua como se alguém tivesse clonado o repositório original e, em seguida, enviado para um repositório novo e vazio.
Após a criação de um fork, novos arquivos, pastas e branches não são compartilhados entre os repositórios, a menos que uma PR (Solicitação de Pull) faça isso.
Compartilhando código entre forks
Você pode criar PRs em qualquer direção: do fork para upstream ou upstream para o fork.
A abordagem mais comum será do fork para upstream.
As permissões, políticas, os builds e os itens de trabalho do repositório de destino serão aplicados à PR.
Escolhendo entre branches e forks
Para uma pequena equipe (2 a 5 desenvolvedores), é recomendável trabalhar em um único repositório.
Todos devem trabalhar em um branch de tópico e o principal deve ser protegido com políticas de branch.
À medida que sua equipe cresce mais significativamente, você pode achar essa forma de organização ultrapassada e preferir mudar para um fluxo de trabalho de fork.
Recomendamos o fluxo de trabalho de fork se seu repositório tiver muitos commits casuais ou pouco frequentes (como um projeto de código aberto).
Normalmente, somente os colaboradores principais do projeto têm direitos de fazer commits diretos em seu repositório.
Seria de ajuda se você solicitasse aos colaboradores de fora desse conjunto principal de pessoas que trabalhassem em um fork do repositório.
Além disso, isso isolará as alterações desses colaboradores das suas até que você tenha a oportunidade de aprovar o trabalho.
O fluxo de trabalho de fork
- Criar um fork.
- Clone-o localmente.
- Faça suas alterações localmente e envie por push para um branch.
- Crie e conclua uma PR para upstream.
- Sincronize seu fork com a versão mais recente do upstream.
Criar o Fork
- Navegue até o repositório para criar o fork e escolha fork.
- Especifique um nome e escolha o projeto em que você deseja que o fork seja criado. Se o repositório contiver muitos branches de tópico, recomendamos criar fork apenas do branch padrão.
- Escolha as elipses e, em seguida, Fork para criar o fork.
Observação
Você deve ter a permissão Criar Repositório no projeto que você escolheu para criar um fork. Recomendamos que você crie um projeto dedicado para forks em que todos os colaboradores tenham a permissão Criar Repositório. Para ver um exemplo de como conceder essa permissão, confira Definir permissões de repositório Git.
Clonar o fork localmente
Quando o fork estiver pronto, clone-o usando a linha de comando ou um IDE como o Visual Studio. O fork será sua origem remota.
Para sua conveniência, após a clonagem, é interessante adicionar o repositório upstream (o local do qual você criou o fork) como um repositório remoto chamado upstream.
git remote add upstream {upstream_url}
Fazer e efetuar push de alterações
É possível trabalhar diretamente no principal; – afinal de contas, esse fork é sua cópia do repositório.
No entanto, é recomendável que você continue trabalhando em um branch de tópico.
Ele permite que você mantenha vários fluxos de trabalho independentes simultaneamente.
Além disso, ele reduz a confusão posteriormente quando você quiser sincronizar as alterações em seu fork.
Altere e faça commit das alterações como faria normalmente. Quando você terminar as alterações, envie-as por push para a origem (seu fork).
Criar e concluir uma PR
Abra uma solicitação de pull em seu fork para o upstream. Todas as políticas, os revisores necessários e os builds serão aplicadas no repositório upstream. Depois que todas as políticas forem satisfeitas, a PR poderá ser concluída e as alterações se tornarão uma parte permanente do repositório upstream.
Importante
Qualquer pessoa com a permissão de Leitura pode abrir uma PR para o repositório upstream. Se um pipeline de build da PR estiver configurado, o build será executado no código introduzido no fork.
Sincronizar o fork com a versão mais recente
Quando a PR for aceita no upstream, será interessante que o fork reflita o estado mais recente do repositório.
É recomendável basear novamente na branch principal do upstream (supondo que este seja o principal branch de desenvolvimento).
git fetch upstream main
git rebase upstream/main
git push origin
O fluxo de trabalho de fork permite isolar as alterações do repositório principal até que você esteja pronto para integrá-las. Quando você estiver pronto, integrar o código é tão fácil quanto concluir uma solicitação de pull.