Bifurcação vs. Ramificação no GitHub

Gostaria de saber mais sobre as vantagens e desvantagens de criar um projeto github em vez de criar um ramo de um projeto github.

Forking torna minha versão do projeto mais isolada da original porque não preciso estar na lista de colaboradores do projeto original. Como estamos desenvolvendo um projeto internamente, não há problema em adicionar pessoas como colaboradores. Porém, gostaríamos de entender se a criação de um projeto dificultaria as alterações de mesclagem no projeto principal. Ou seja, gostaria de saber se a ramificação facilita a manutenção dos dois projetos em sincronia. Em outras palavras, é mais fácil mesclar e enviar alterações entre minha versão do projeto principal e o projeto principal quando eu ramifico?

Você nem sempre pode criar uma ramificação ou extrair uma ramificação existente e retornar a ela, porque não está registrado como um colaborador desse projeto específico.

A bifurcação nada mais é do que um clone no lado do servidor GitHub :

• sem a possibilidade de recuar diretamente
• com o recurso fila de bifurcação adicionado para gerenciar a solicitação de mesclagem

Você mantém uma bifurcação em sincronia com o projeto original:

• adicionando o projeto original como um controle remoto
• buscando regularmente a partir desse projeto original
• refaça seu desenvolvimento atual sobre o ramo de interesse que você atualizou a partir dessa busca.

A rebase permite que você garanta que suas alterações sejam diretas (sem conflito de mesclagem), facilitando a solicitação de recebimento quando você deseja que o mantenedor do projeto original inclua seus patches no projeto.

O objetivo é realmente permitir a colaboração, embora a participação direta nem sempre seja possível.

O fato de você clonar no lado do GitHub significa que agora você tem dois repositórios "central" ("central" como "visível de vários colaboradores).
Se você pode adicioná-los diretamente como colaborador de um projeto, não precisa gerenciar outro um com um garfo.

A experiência de mesclagem seria a mesma, mas com um nível extra de indireção (empurre primeiro o garfo e depois peça um puxão, com o risco de evoluções no repo original, fazendo com que suas combinações de avanço rápido não sejam mais um avanço rápido) .
Isso significa que o fluxo de trabalho correto é git pull --rebase upstream(refazer o seu trabalho sobre novas confirmações do upstream) e, em seguida,git push --force origin , em , para reescrever o histórico de maneira que seus próprios commits estejam sempre atualizados sobre as confirmações do repo original (upstream) .

Veja também:

• Git fork é git clone?
• Puxe novas atualizações do repositório original do Github para o repositório bifurcado do Github

Aqui estão as diferenças de alto nível:

Bifurcação

Prós

• Mantém ramificações separadas pelo usuário
• Reduz a desorganização no repositório primário
• O processo da sua equipe reflete o processo do colaborador externo

Contras

• Torna mais difícil ver todos os ramos ativos (ou inativos).
• Colaborar em uma filial é mais complicado (o proprietário do fork precisa adicionar a pessoa como colaborador)
• Você precisa entender o conceito de vários controles remotos no Git
  • Requer contabilidade mental adicional
  • Isso tornará o fluxo de trabalho mais difícil para as pessoas que não estão super confortáveis ​​com o Git

Ramificação

Prós

• Mantém todo o trabalho sendo realizado em torno de um projeto em um só lugar
• Todos os colaboradores podem enviar para o mesmo ramo para colaborar nele
• Existe apenas um controle remoto Git para lidar

Contras

• Ramos que são abandonados podem se acumular mais facilmente
• O processo de contribuição da sua equipe não corresponde ao processo de contribuidor externo
• Você precisa adicionar membros da equipe como colaboradores antes de poderem ramificar

Tem a ver com o fluxo de trabalho geral do Git. É improvável que você possa enviar diretamente para o repositório do projeto principal. Não tenho certeza se o repositório do projeto GitHub oferece suporte ao controle de acesso baseado em ramificação, pois você não deseja conceder a ninguém a permissão de enviar para a ramificação principal, por exemplo.

O padrão geral é o seguinte:

• Bifurque o repositório do projeto original para ter sua própria cópia do GitHub, para a qual você poderá fazer alterações.
• Clone seu repositório GitHub na sua máquina local
• Opcionalmente, adicione o repositório original como um repositório remoto adicional no seu repositório local. Você poderá buscar diretamente as alterações publicadas nesse repositório.
• Faça suas modificações e seus próprios commits localmente.
• Envie suas alterações ao seu repositório GitHub (como você geralmente não terá permissões de gravação diretamente no repositório do projeto).
• Entre em contato com os mantenedores do projeto e peça que eles busquem suas alterações e revisem / mesclem e permita que eles retornem ao repositório do projeto (se você e eles quiserem).

Sem isso, é bastante incomum que projetos públicos permitam que alguém faça seus próprios compromissos diretamente.

A bifurcação cria um repositório totalmente novo a partir do repositório existente (simplesmente executando o git clone no gitHub / bitbucket)

Os garfos são mais bem utilizados: quando a intenção da 'divisão' é criar um projeto logicamente independente, que pode nunca se reunir com seu pai.

A estratégia de ramificação cria uma nova ramificação sobre o repositório existente / em funcionamento

As ramificações são mais usadas: quando são criadas como locais temporários para trabalhar com um recurso, com a intenção de mesclar a ramificação com a origem.

Mais específico: - Nos projetos de código aberto, é o proprietário do repositório quem decide quem pode enviar por push para o repositório. No entanto, a ideia do código aberto é que todos possam contribuir com o projeto.

Esse problema é resolvido por garfos: sempre que um desenvolvedor deseja alterar algo em um projeto de código aberto, ele não clona o repositório oficial diretamente. Em vez disso, eles o bifurcam para criar uma cópia. Quando o trabalho é concluído, eles fazem uma solicitação de recebimento para que o proprietário do repositório possa revisar as alterações e decidir se as mesclará ao seu projeto.

Em sua essência, a bifurcação é semelhante à ramificação de recursos, mas, em vez de criar ramificações, é feita uma bifurcação do repositório e, em vez de fazer uma solicitação de mesclagem, você cria uma solicitação de recebimento.

Os links abaixo fornecem a diferença de uma maneira bem explicada:

https://blog.gitprime.com/the-definitive-guide-to-forks-and-branches-in-git/

https://buddy.works/blog/5-types-of-git-workflows

http://www.continuousagile.com/unblock/branching.html