Descrever inner source com forks
As pessoas bifurcam repositórios quando desejam alterar o código em um repositório no qual não precisam gravar o acesso.
Se você não tiver acesso de gravação, não faz parte da equipe que contribui para esse repositório, então por que modificaria o repositório de código?
Tendemos a procurar razões técnicas para melhorar algo em nosso trabalho.
Você pode encontrar uma maneira melhor de implementar a solução ou aprimorar a funcionalidade contribuindo ou melhorando um recurso existente.
Você pode bifurcar repositórios nas seguintes situações:
- Quero fazer uma mudança.
- Acho que o projeto é emocionante e pode querer usá-lo.
- Quero usar algum código nesse repositório como ponto de partida para o meu projeto.
As equipes de software são incentivadas a contribuir para todos os projetos internamente, não apenas para seus projetos de software.
Forks são uma ótima maneira de promover uma cultura de código aberto interno.
Forks são uma adição recente aos repositórios Git do Azure DevOps.
Esta receita ensinará você a bifurcar um repositório existente e contribuir com alterações upstream por meio de uma solicitação pull.
Preparando-se
Um fork começa com todo o conteúdo de seu repositório upstream (original).
Ao criar uma bifurcação no Azure DevOps, você pode incluir todas as ramificações ou limitá-las apenas ao branch padrão.
Uma bifurcação não copia as permissões, as políticas ou as definições de build do repositório que está sendo bifurcado.
Depois que uma bifurcação for criada, os arquivos, pastas e branches recém-criados não serão compartilhados entre os repositórios, a menos que você inicie uma solicitação de pull.
As solicitações pull têm suporte em qualquer direção: do fork para upstream ou de upstream para o fork.
A abordagem mais comum de uma solicitação de pull será a do fork para upstream.
Como fazer isso
Escolha o botão Bifurcação (1) e, em seguida, selecione o projeto no qual você deseja que a bifurcação seja criada (2). Dê um nome ao fork e escolha o botão Fork (3).
Quando seu fork estiver pronto, clone-o usando a linha de comando ou uma IDE, como o Visual Studio. O fork será sua origem remota. Para sua conveniência, é interessante adicionar o repositório upstream (o local do qual você criou o fork) como um repositório remoto chamado upstream. Na linha de comando, digite:
git remote add upstream {upstream_url}
É possível trabalhar diretamente no fork principal, pois ele é a 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. Faça e confirme suas alterações como faria normalmente. Ao concluir as modificações, envie-as por push à origem (o fork).
Abra uma solicitação de pull em seu fork para o upstream. O repositório upstream será responsável por aplicar todas as políticas necessárias para revisores e compilações. Depois que todas as políticas forem atendidas, a PR poderá ser concluída e as alterações se tornarão uma parte permanente do repositório upstream:
Quando a PR é aceita upstream, o fork precisa refletir o estado mais recente do repositório. É recomendável basear novamente na branch principal do upstream (supondo que ele seja o principal branch de desenvolvimento). Na linha de comando, execute:
git fetch upstream main git rebase upstream/main git push origin
Para obter mais informações sobre o Git, consulte: