Implementar o fluxo de trabalho de fork

Um fork é uma cópia de um repositório. Fazer um fork de um repositório permite que você faça experimentos com alterações de forma livre, sem afetar o projeto original.

Geralmente, forks são usados para propor alterações no 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 (opcionalmente) ramificações.

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 essas alterações, é fácil contribuí-las novamente usando solicitações de pull.

O que há em um garfo?

Um fork começa com todo o conteúdo de seu repositório upstream (original). Você pode incluir todas as ramificações ou limitá-las apenas ao branch padrão ao criar uma bifurcação.

Notas importantes:

• Nenhuma das permissões, políticas ou pipelines de build é copiada.
• O novo fork atua como se alguém tivesse clonado o repositório original e, em seguida, o tivesse enviado para um novo repositório vazio.
• Depois que um fork for criado, novos arquivos, pastas e branches não serão compartilhados entre os repositórios, a menos que uma Solicitação de Pull os carregue.

Compartilhando código entre forks

Você pode criar solicitações de pull em qualquer direção: de fork para upstream ou upstream para fork. A abordagem mais comum é de fork para upstream.

As permissões, as políticas, os builds e os itens de trabalho do repositório de destino serão aplicados à solicitação de pull.

Escolhendo entre galhos e garfos

• Equipes pequenas (2 a 5 desenvolvedores): recomendamos trabalhar em um único repositório. Todos devem trabalhar em um branch de tópico e a ramificação principal deve ser protegida com políticas de branch.

• Equipes maiores: à medida que sua equipe cresce, você pode se encontrar superando essa disposição e preferir mudar para um fluxo de trabalho de fork.

• Quando usar forks:

  • Seu repositório tem muitos colaboradores casuais ou pouco frequentes (como um projeto de software livre).
  • Somente os principais colaboradores têm permissões de commit diretas em seu repositório.
  • Você deseja que os colaboradores de fora da equipe principal trabalhem de um fork.
  • Você deseja isolar as alterações até ter a chance de revisar o trabalho.

O fluxo de trabalho de fork

Estas são as principais etapas para o fluxo de trabalho de ramificação:

1. Criar um fork.
2. Clone-o localmente.
3. Faça suas alterações localmente e envie por push para um branch.
4. Crie e conclua uma solicitação de pull para upstream.
5. Sincronize seu fork com a versão mais recente do upstream.

Etapa 1: Criar a bifurcação

1. Navegue até o repositório que você deseja criar o fork e escolha "Fork".
2. Especifique um nome e escolha o projeto no qual você deseja que a bifurcação seja criada.
3. Se o repositório contiver muitos ramos de tópicos, recomendamos que você bifurque apenas o ramo padrão.
4. Escolha as reticências e, em seguida, "Criar fork" para criar o fork.

Etapa 2: Clonar seu fork localmente

Quando o fork estiver pronto, clone-o usando a linha de comando ou um IDE como Visual Studio. O fork será sua origem remota.

git clone {your_fork_url}
For convenience, after cloning, you'll want to add the upstream repository (where you forked from) as a remote named upstream:

```bash
git remote add upstream {upstream_url}

Etapa 3: Fazer e enviar alterações via push

É possível trabalhar diretamente no main – afinal, esse fork é sua cópia do repositório. No entanto, recomendamos que você ainda trabalhe em um branch de tópicos porque:

• Ele permite que você mantenha vários fluxos de trabalho independentes ao mesmo tempo.
• Isso reduz a confusão mais tarde quando você deseja sincronizar alterações em seu fork.

Faça e confirme suas alterações como faria normalmente. Quando terminar as alterações, envie-as para a origem (seu fork).

Etapa 4: Criar e concluir uma solicitação de pull

Abra uma solicitação de pull do fork para o repositório upstream. Todas as políticas, os revisores necessários e os builds serão aplicados no repositório upstream. Depois que todas as políticas forem atendidas, a solicitação de pull poderá ser concluída e as alterações se tornarão uma parte permanente do repositório upstream.

Etapa 5: Sincronizar seu fork com a versão mais recente

Quando sua solicitação de pull for aceita no upstream, você desejará garantir que seu fork reflita o estado mais recente do repositório.

É recomendável basear novamente na ramificação principal do upstream (supondo que este seja o principal branch de desenvolvimento):

git fetch upstream main
git rebase upstream/main
git push origin

Benefícios do fluxo de trabalho de bifurcação

O fluxo de trabalho de bifurcação permite isolar as alterações do repositório principal até que você esteja pronto para integrá-las. Quando você estiver pronto, a integração de código é tão fácil quanto concluir uma solicitação de pull.

Essa abordagem fornece:

• Segurança: as alterações são isoladas até serem revisadas.
• Colaboração: várias pessoas podem trabalhar em diferentes recursos simultaneamente.
• Qualidade: todas as alterações passam pelo mesmo processo de revisão.
• Flexibilidade: os colaboradores não precisam de acesso de gravação ao repositório principal.