O que essas palavras significam no Git: Repositório, fork, branch, clone, track?

130

Sinceramente, não sou claro sobre a semântica aqui. Eles são todos sobre cópias / variantes de uma unidade de código + histórico, mas além disso, não sei ao certo o que dizer. Essa estrutura lógica é explicada em algum lugar?

git branch clone

— Eric Anderson
fonte

5

Eu recomendaria a leitura dos primeiros capítulos do livro Pro Git ( progit.org/book ).

— Ewall

61

+1. Muitos tutoriais do git mostram como executar determinadas tarefas sem explicar o que certas palavras significam ou como o git funciona. Pedir um recurso que aborde esses tópicos é uma pergunta legítima.

— Daniel Stutzbach

14

Gostaria de poder marcar o comentário de Daniel com mais +1. Embora o significado de alguns dos termos (por exemplo, repositório) deva ser óbvio, seu relacionamento nem sempre é (ramificação x forquilha), e o significado real é facilmente mal interpretado por alguém acostumado a um VCS centralizado. Além disso, veja o que é um ramo do Pro Git? seção - um usuário básico realmente quer saber sobre bolhas e árvores ou apenas quer saber qualitativamente o que é um ramo?

— Cascabel 27/05

1

@DanielStutzbach, é possível enviar comentários sobre coisas que não estão claras no livro. (Não sei a terminologia correta para dizer isso.) Fiz isso, afirmei que o livro precisa definir o que é um repositório. Concordo que é muito difícil obter material conceitual de pessoas que entendem algo muito bem. Esse livro (atualmente) fala sobre bancos de dados sem definir o que são nesse contexto e não diz nada sobre o que são repositórios.

— user34660

146

Um repositório é simplesmente um local onde o histórico do seu trabalho é armazenado. Geralmente, ele .gitfica em um subdiretório da sua cópia de trabalho - uma cópia do estado mais recente dos arquivos nos quais você está trabalhando.

Para bifurcar um projeto (pegue a fonte do repositório de alguém em determinado momento e aplique suas próprias alterações divergentes), você clonaria o repositório remoto para criar uma cópia dele e, em seguida, faria seu próprio trabalho no repositório local e confirmar alterações.

Dentro de um repositório, você tem ramificações, que são efetivamente bifurcadas em seu próprio repositório. Seus ramos terão um commit ancestral em seu repositório e divergirão desse commit com suas alterações. Mais tarde, você pode mesclar suas alterações de ramificação. As ramificações permitem trabalhar em vários recursos diferentes de uma só vez.

Você também pode rastrear ramificações individuais em repositórios remotos. Isso permite extrair alterações dos ramos de outra pessoa e mesclá-las em um ramo próprio. Isso pode ser útil se você e um amigo estiverem trabalhando juntos em um novo recurso.

Existem muitos livros on-line excelentes. Dê uma olhada no ProGit e no Git Magic para começar, bem como nos tutoriais oficiais e no livro da comunidade.

— nfm
fonte

Claro que a leitura dos manuais e tutoriais F é fundamental. Mas isso me parece um ótimo resumo de tudo isso. Muito apreciado!

— Brasofilo

Observe que você pode alternar seu diretório de trabalho local para uma nova ramificação ("git checkout <novo_branch>"). Nesse caso, os arquivos do seu diretório de trabalho local são SUBSTITUÍDOS pelo conteúdo da ramificação para a qual você está alternando. Mas você não perde seu trabalho: o Git armazena todas as alterações confirmadas ("git commit") que você fez na ramificação anterior no "banco de dados" do Git (pasta oculta .git) e permitirá que você retorne seus arquivos.

— KrisWebDev

3

Eu acho que requer menção especial que, historicamente, independentemente de quais VCS você usou, bifurcação e ramificação foram consideradas duas coisas distintas. A ramificação foi considerada um acordo favorável e implícito entre os desenvolvedores. A bifurcação era mais séria, pois implicava que os desenvolvedores que trabalhavam em um projeto não concordavam em algumas coisas e decidiram se separar. Os garfos bem-sucedidos eram tipicamente reunidos novamente em um projeto depois que os dois lados chegaram a um acordo. Desde então, o Git (e o GitHub) obscureceram esses termos e ambos representam basicamente a mesma ideia, mas de maneiras diferentes.

— precisa saber é o seguinte

Então, um repositório não possui os arquivos para o projeto? Você diz um local onde está armazenado o histórico do seu trabalho . Isso é tudo? Apenas o histórico dos arquivos, mas não os próprios arquivos?

— user34660

13

Vou responder minha própria pergunta com um RTFM.

Mas, leia este manual fino. Como o autor coloca:

“A conclusão que tirei disso é que você só pode realmente usar o Git se entender como o Git funciona. Apenas memorizando quais comandos você deve executar a que horas funcionará no curto prazo, mas é apenas uma questão de tempo antes de você ficar preso ou, pior ainda, quebrar alguma coisa.

“Metade dos recursos existentes no Git, infelizmente, adotam exatamente essa abordagem: eles orientam você sobre os comandos a serem executados quando e esperam que você deva se sair bem se apenas imitar esses comandos. A outra metade passa por todos os conceitos, mas pelo que vi, eles explicam o Git de uma maneira que assume que você já entende como o Git funciona. ”

— Eric Anderson
fonte

Esta introdução parece ter sido movida para sbf5.com/~cduan/technical/git . O URL original ainda funciona por enquanto.

— Eric Anderson

1

Isso é verdade dentro do contexto. Se você precisa ser produtivo imediatamente ou realmente apenas verificar o código, não há problema em ter um profundo entendimento de como o git funciona. Os tutoriais estão bem. Foi assim que entrei no git. No entanto, se ou quando você precisar ser mais avançado, como criar ramificações, bifurcação, rebase e outras tarefas mais avançadas, precisará saber como o git funciona, especialmente se o seu plano de fundo estiver em um controle de fonte centralizado.

— Phil

3

Este GoogleTechTalk é uma introdução fantástica ao Git para aprender o que realmente está acontecendo nos bastidores e ao mesmo tempo aprender o idioma. Foi dado por um colaborador muito antigo do Git e ele deu essa palestra em 2007 como uma forma de introdução ao Git. Se você assistir a essa conversa, não apenas saberá o que cada palavra é, como repositório, fork, ramificação etc., mas também saberá o que está acontecendo nos bastidores quando cada uma delas é criada, mesclada etc.

O endereço é longo, mas muito informativo. Ele também contrasta o Git com outros sistemas de controle de versão, para que você possa entender por que o Git foi criado do jeito que era e quais são as vantagens comparativas dele em relação a outros sistemas de controle. Embora a conversa seja antiga, é muito útil começar a trabalhar. Eu assistia isso antes de pular para os manuais. As coisas farão muito mais sentido, como resultado, acredito.

— Matt
fonte