Os garfos do Git são realmente clones do Git?

817

Eu continuo ouvindo as pessoas dizerem que estão criando código no Git. O "garfo" do Git parece suspeito como o "clone" do Git, além de alguma disposição psicológica (sem sentido) de renunciar a futuras fusões. Não há comando de bifurcação no Git, certo?

O GitHub torna os garfos um pouco mais reais grampeando correspondência nele. Ou seja, você pressiona o botão da bifurcação e, mais tarde, ao pressionar o botão de solicitação de recebimento, o sistema é inteligente o suficiente para enviar um e-mail ao proprietário. Portanto, é um pouco de dança em torno da propriedade e das permissões do repositório.

Sim não? Alguma angústia sobre o GitHub estender o Git nessa direção? Ou algum boato de que o Git absorva a funcionalidade?

— Brian
fonte

10

Sim, é apenas um tipo de clone que é rastreado pelo banco de dados do github.

— Paŭlo Ebermann

15

O GitHub não faz algo especial para evitar duplicar os requisitos de armazenamento (nos próprios servidores do GitHub)?

— Keith Thompson

18

Ainda não mencionado: a exclusão de um repo privado exclui todos os seus garfos. A exclusão de um repositório público mantém os garfos, mas promove um garfo para ser o novo repositório pai. Se o seu chefe tornar seu repositório público privado, ele quebrará todos os garfos existentes e você não poderá fazer solicitações pull deles para o repositório particular. help.github.com/articles/…

— Platão

Eu acredito (sem provas, já que o GitHub não mostra isso para nós) que o mecanismo real aqui é "alternativo" do Git. Em outras palavras, o fork é um clone de espelho --referenceusado. Exatamente como os repositórios e exclusões públicas são manipulados não é de todo claro (mover alterna para o repositório promovido escolhido aleatoriamente - aponte todos os garfos para alguma alternativa comum que não faz parte do fork original?), Mas o uso de alternativas explica vários comportamentos observáveis.

— Torek #

925

Fork , no contexto do GitHub, não estende o Git.
Permite apenas clonar no lado do servidor.

Quando você clona um repositório GitHub na estação de trabalho local, não pode contribuir de volta para o repositório upstream, a menos que seja explicitamente declarado como "colaborador". Isso ocorre porque o seu clone é uma instância separada desse projeto. Se você deseja contribuir com o projeto, pode usar o bifurcação para fazê-lo, da seguinte maneira:

clone o repositório GitHub na sua conta GitHub (que é a parte "fork" , um clone no lado do servidor)
O commit contribui com esse repositório GitHub (ele está em sua própria conta GitHub, portanto você tem todo o direito de enviá-lo)
sinalize qualquer contribuição interessante de volta ao repositório original do GitHub (que é a parte "solicitação de recebimento" por meio das alterações feitas em seu próprio repositório GitHub)

Verifique também " Fluxo de trabalho colaborativo do GitHub ".

Se você deseja manter um link com o repositório original (também chamado de upstream), é necessário adicionar um controle remoto referente ao repositório original.
Consulte " Qual é a diferença entre origem e upstream no GitHub? "

garfo e montante

E com o Git 2.20 (quarto trimestre de 2018) e mais, buscar do fork é mais eficiente, com ilhas delta .

— VonC
fonte

6

"Quando você está clonando um repositório GitHub em sua estação de trabalho local, não pode contribuir de volta para o repositório upstream, a menos que seja declarado explicitamente como" colaborador "." --- Isso não é verdade com "bifurcação"? Por favor explique.

— precisa saber é o seguinte

61

@ TestSubject528491 não, com uma bifurcação, significa que você está clonando o repositório upstream como seu próprio repositório no lado do servidor GitHub. Em seguida, você pode clonar localmente esse novo repositório "fork" no seu computador e empurrá-lo livremente, pois você é o criador e o proprietário desse fork.

— VonC

9

Para mim, o ponto principal é que você não pode enviar um PR a partir de sua cópia local, a menos que seja declarado um colaborador . Estou tão acostumado a enviar PRs do meu repo local, mas é porque estou sempre marcado como colaborador. Se você pensar bem, para enviar um PR, é necessário enviar uma ramificação para o repositório remoto e criar o PR. Eu acho que faz sentido se você não quiser que pessoas aleatórias criem ramificações em seu repositório. E que você prefere que eles bifurcem e enviem PRs dessa maneira.

— Adam Zerner

Eu já vi a segunda abordagem remota "upstream" em outro lugar, mas não é mais simples extrair diretamente de "GitHub - Original" para "GitHub - Fork"? A segunda abordagem remota parecia não funcionar na minha configuração do Eclipse e do eGit, falhando ao enviar para o meu repositório "GitHub - Fork" (nada para enviar).

— William T. Mallard

Não importa, o link de informações aqui me deu algumas dicas. Como colaborador, faz sentido extrair de "GitHub - Original" para "GitHub - Fork" e depois de "- Fork" para a máquina local, mas se você é o proprietário, provavelmente deseja extrair diretamente do meu "- Fork" primeiro a revisar, executar testes etc. antes de passar para "- Original".

— William T. Mallard

135

Eu continuo ouvindo as pessoas dizerem que estão criando código no git. Git "fork" soa suspeitamente como git "clone" mais alguma vontade psicológica (sem sentido) de renunciar a futuras fusões. Não há nenhum comando fork no git, certo?

"Bifurcação" é um conceito, não um comando suportado especificamente por qualquer sistema de controle de versão.

O tipo mais simples de bifurcação é sinônimo de ramificação. Toda vez que você cria uma ramificação, independentemente do seu VCS, você "bifurca". Esses garfos geralmente são muito fáceis de unir novamente.

O tipo de problema que você está falando, onde uma parte separada pega uma cópia completa do código e se afasta, necessariamente acontece fora do VCS em um sistema centralizado como o Subversion. Um VCS distribuído como o Git tem um suporte muito melhor para bifurcar toda a base de código e iniciar efetivamente um novo projeto.

O Git (não o GitHub) suporta nativamente "bifurcar" um repositório inteiro (ou seja, cloná-lo) de duas maneiras:

quando você clona, um controle remoto chamado originé criado para você
por padrão, todos os ramos do clone rastrearão seus originequivalentes
buscar e mesclar alterações do projeto original do qual você se originou é trivialmente fácil

O Git simplifica a contribuição de mudanças na origem da bifurcação, como pedir a alguém do projeto original para extrair de você ou solicitar acesso de gravação para empurrar as alterações de volta. Essa é a parte que o GitHub facilita e padroniza.

Alguma angústia sobre o Github estender o git nessa direção? Ou algum boato de que o git absorva a funcionalidade?

Não há angústia porque sua suposição está errada. O GitHub "estende" a funcionalidade de bifurcação do Git com uma boa interface gráfica e uma maneira padronizada de emitir solicitações pull, mas não adiciona a funcionalidade ao Git. O conceito de fork-repo-fork é incorporado diretamente ao controle de versão distribuído em um nível fundamental. Você pode abandonar o GitHub a qualquer momento e continuar a empurrar / puxar os projetos "bifurcados".

— magro
fonte

6

Obrigado pela sua excelente resposta. Eu só quero esclarecer, isso significa que, fora do contexto do github, eu poderia clonar alguns X projectna minha máquina. Se eu fizer alterações no meu local e não tiver acesso de gravação à origem, enviarei um email ao autor do projeto para solicitar uma solicitação. Ele fará um controle remoto chamado gideon, que será um URL para o meu clone local, e ele poderá puxar, certo?

— Gideon

1

Se você deseja contribuir com suas alterações em um projeto, você pode salvá-las em arquivos, por exemplo, usando o git format-patch e anexá-las a um e-mail a alguém que tenha acesso de gravação, ou você pode obter sua própria hospedagem, enviando seu trabalho para isso e envie a URL em um email, por exemplo, usando o comando git request-pull. Os repositórios nas estações de trabalho geralmente não são acessíveis diretamente diretamente.

— precisa saber é

Mas sim, se a sua estação de trabalho estiver acessível pela Internet ao autor do projeto, você pode simplesmente enviar o URL para eles e eles podem adicioná-lo como um controle remoto e retirá-lo.

— bdsl

1

Re: angústia, a única coisa para mim é que não há nenhum link ou botão para clicar para criar um botão de puxar do meu repo em que o GitHub diz que você está com 50 comprometidos. Não é nada demais agora que sei que eles estão usando o termo "Solicitação de recebimento" para incluir também solicitações de extração do montante para o seu fork do GitHub. Git é difícil.

— William T. Mallard

80

Sim, o garfo é um clone. Surgiu porque, você não pode enviar cópias de outras pessoas sem a permissão delas . Eles fazem uma cópia para você ( bifurcação ), onde você também terá permissão de gravação.

No futuro, se o proprietário real ou outros usuários com uma bifurcação como as suas alterações, poderão recuperá-la para seu próprio repositório. Como alternativa, você pode enviar a eles uma "solicitação de recebimento".

— ssapkota
fonte

Posso simplesmente clonar o repositório na minha máquina local, criar uma ramificação e enviar uma solicitação de recebimento ao proprietário original? Parece redundante ter várias cópias de repositórios hospedados em todo o GitHub, apenas para facilitar as atualizações de código.

— Casey

4

@Casey Você só pode enviar uma solicitação pull através do GitHub a partir do próprio GitHub e só pode enviar uma solicitação pull do GitHub a partir de uma ramificação existente no GitHub. Se você não é um colaborador do Repositório em questão, não há como criar uma ramificação a partir da qual você pode iniciar uma solicitação de recebimento do GitHub. Nada o impede de fazê-lo por e-mail da maneira antiga, mas o GitHub não faz parte disso.

— Beau Simensen

2

@ Casey, um motivo é que normalmente outras pessoas não têm acesso a URL na sua estação de trabalho. O GitHub forksignifica que há uma cópia do seu trabalho no servidor GitHub, à qual você pode pushe para quem outras pessoas têm acesso à URL, para que possam pull. Essa pull requesté apenas uma maneira padrão de obter o URL da sua cópia (no GitHub) para eles, para que eles possam facilmente inseri-lo no repositório.

— Jesse Chisholm

Essa deve ser a resposta correta / aceita, acredito. Imagine uma bagunça em uma cena em que uma equipe de 15 a 20 desenvolvedores cria ramificações e avança para a origem, versus 15 a 20 desenvolvedores que possuem sua própria cópia do mesmo repositório e fazem tantas ramificações e realizam alterações e enviam novamente. Em seguida, o autor do repositório original pode obter apenas as alterações que ele / ela deseja.

— Kishor Pawar

37

"Fork" neste contexto significa "Faça uma cópia do código deles para que eu possa adicionar minhas próprias modificações". Não há muito mais a dizer. Todo clone é essencialmente um garfo, e cabe ao original decidir se deve retirar as alterações do garfo.

— Daenyth
fonte

2

Especificamente: "Faça uma cópia do código deles on the GitHub serverpara que eu possa adicionar minhas próprias modificações and others can have URL access to my version". A maioria das estações de trabalho locais não oferece acesso à URL para que ninguém possa receber. Mas se você enviar para o seu fork no servidor, eles poderão ter o URL para o pull.

— Jesse Chisholm

A questão não é sobre a bifurcação é em geral, mas sobre a bifurcação do GitHub especificamente.

— reinierpost

26

A clonagem envolve fazer uma cópia do repositório git em uma máquina local, enquanto a bifurcação está clonando o repositório em outro repositório. A clonagem é apenas para uso pessoal (embora futuras fusões possam ocorrer), mas com a bifurcação você está copiando e abrindo um novo caminho possível do projeto

— Sam Johnson
fonte

11

A bifurcação é feita quando você decide contribuir para algum projeto. Você faria uma cópia de todo o projeto, juntamente com seus registros de histórico. Essa cópia é feita inteiramente em seu repositório e, depois que você faz essas alterações, emite uma solicitação de recebimento. Agora cabe ao proprietário da fonte aceitar sua solicitação de recebimento e incorporar as alterações no código original.

Git clone é um comando real que permite aos usuários obter uma cópia da fonte. git clone [URL] Isso deve criar uma cópia de [URL] em seu próprio repositório local.

— aliasav
fonte

10

Acho que fork é uma cópia de outro repositório, mas com a modificação da sua conta. por exemplo, se você clonar diretamente outro repositório localmente, a origem do objeto remoto ainda estará usando a conta da qual você clonou. Você não pode confirmar e contribuir com seu código. É apenas uma cópia pura dos códigos. Caso contrário, se você bifurcar um repositório, ele clonará o repositório com a atualização da configuração da sua conta na sua conta do github. E, em seguida, ao clonar o repositório no contexto da sua conta, você pode confirmar seus códigos.

— Daniel Shen
fonte

10

Há um mal-entendido aqui com relação ao que é um "garfo". Um fork é na verdade nada mais que um conjunto de ramificações por usuário. Quando você empurra para um fork, na verdade empurra para o repositório original, porque esse é o ÚNICO repositório.

Você pode tentar isso pressionando uma bifurcação, observando a confirmação e, em seguida, acessando o repositório original e usando o ID da confirmação, verá que a confirmação está "dentro" do repositório original.

Isso faz muito sentido, mas está longe de ser óbvio (só descobri isso acidentalmente recentemente).

Quando John bifurca o SuperProject no repositório, o que parece realmente acontecer é que todas as ramificações no repositório de origem são replicadas com um nome como "John.master", "John.new_gui_project" etc.

O GitHub "oculta" o "John". de nós e nos dá a ilusão de que temos nossa própria "cópia" do repositório no GitHub, mas não temos nem é necessário.

Portanto, o ramo "master" do meu fork é chamado "Korporal.master", mas a interface do usuário do GitHub nunca revela isso, mostrando apenas "mestre".

Isso é basicamente o que eu acho que acontece de qualquer maneira, com base nas coisas que venho fazendo recentemente e quando você pensa sobre isso, é um design muito bom.

Por esse motivo, acho que seria muito fácil para a Microsoft implementar os garfos Git em sua oferta do Visual Studio Team Services.

— Hugh
fonte

Caro Hugh, metade da sua resposta está realmente incorreta - um fork é um clone de um repositório inteiro de uma conta de usuário para outra conta de usuário, junto com todos os ramos e histórico. Quando você se compromete com o fork, nada muda no repositório original do qual você bifurcou. Mas, além desses poucos mal-entendidos da sua parte sobre o que é um "garfo", agora existem boas notícias: os serviços da equipe do Visual Studio incluem agora a funcionalidade "garfo". ;)

— Sorin Postelnicu

1

@SorinPostelnicu fonte? Estou inclinado a acreditar que Hugh aqui devido à experiência pessoal de garfos se comportando de maneiras que são inconstantes por serem um simples clone do repositório. Por exemplo, quando o upstream é excluído, os garfos são excluídos (como foi mencionado em um comentário sobre a pergunta do OP) e, às vezes, o upstream acabou mesclando coisas em ramificações dos meus garfos ao aceitar uma solicitação pull, sem que eu fizesse nada.

— potato

De fato, esse parece ser o caso. Afinal, seria incrivelmente estúpido para o GitHub literalmente git cloneum repositório totalmente novo (mesmo um "vazio") toda vez que alguém apertar o botão "fork" - isso seria um incrível desperdício de armazenamento e, provavelmente, um vetor de ataque .

— Greg A. Woods,

7

Além do fato de que a clonagem é do servidor para a sua máquina e o bifurcação está fazendo uma cópia no próprio servidor, uma diferença importante é que, quando clonamos, obtemos todas as ramificações, rótulos etc.

Mas quando bifurcamos, na verdade só obtemos os arquivos atuais no ramo mestre, nada além disso. Isso significa que não temos os outros ramos, etc.

Portanto, se você precisar mesclar algo de volta ao repositório original, é uma mesclagem entre repositórios e definitivamente precisará de privilégios mais altos.

Fork não é um comando no Git; é apenas um conceito que o GitHub implementa. Lembre-se de que o Git foi projetado para funcionar em ambiente ponto a ponto sem a necessidade de sincronizar coisas com qualquer cópia mestre. O servidor é apenas outro par, mas o vemos como uma cópia principal.

— Deepak GM
fonte

7

Hã? Um garfo obtém todos os galhos, embora você precise saber para onde procurar (dica:) git branch -a.

— Tripleee 16/01

3

Em termos mais simples,

Quando você diz que são bifurcação um repositório, você está basicamente criando uma cópia do repositório original sob seu GitHub ID em sua conta GitHub.

e

Quando você diz que está clonando um repositório, está criando uma cópia local do repositório original no seu sistema (PC / laptop) diretamente sem ter uma cópia na sua conta do GitHub.

— anoNewb
fonte