Estrutura de um repositório Git

15

Desculpe se isso é uma duplicata, eu olhei.

Estamos nos mudando para o Git. No Subversion, eu estou acostumado a ter as pastas \ trunk, \ branches e \ tags.

Com o Git, a alternância entre as ramificações substituirá o conteúdo do diretório de trabalho. Por isso, estou certo de que a maneira como costumávamos trabalhar não se aplica ao Git?

Meu palpite é que eu teria uma pasta de repositório com talvez um gitignore e um readme.txt, depois as pastas dos projetos que compõem o repositório, e é isso.

Luke Puplett
fonte

Respostas:

15

Você terá "trunk", agora chamado de "master", terá "branches", agora chamados de "heads", e terá "tags", ainda chamadas de "tags", mas não serão pastas , serão " refs ", rótulos para revisões que residem em um espaço para nome separado dentro do repositório.

O Subversion e o Git têm maneiras diferentes de fazer ramificações. O modelo básico de subversão é ter uma árvore de diretórios com uma linha do tempo global única e, se você quiser ramificar, copie uma subárvore em outro diretório.

Por outro lado, o Git tem uma árvore de diretórios com revisões que definem seus pais, mas cada revisão pode ter vários pais (uma mesclagem) e vários filhos (filiais). Portanto, em vez de ter diretórios para ramificações, você obtém revisões criadas independentemente. Os "refs" são apenas nomes associados à revisão mais recente de determinado "branch".

Essa diferença é fundamental para o controle de versão distribuído. O Git (e outros sistemas distribuídos) não tem nenhuma autoridade central para manter o histórico linear, portanto, as revisões podem ser criadas independentemente em vários repositórios sem conhecer um ao outro e o sistema precisa acomodá-los. Acontece que a generalização facilita muito a ramificação e a fusão.

Observe que, no Git, as revisões não estão em nenhum ramo. Eles são e galhos os contêm. Porém, uma vez que a ramificação seja mesclada ou se mostre um beco sem saída, você pode simplesmente excluir o "ref" que aponta para ela e esquecê-la completamente (se você descartar testes antigos, eles serão coletados com o lixo git gc). Isso ajuda você a evitar ser inundado em experimentos antigos. Ninguém se lembra mais do que se tratava.

Jan Hudec
fonte
Legal. Não são necessárias tags, ramificações e outras bobagens de pasta. Adorável.
Luke Puplett
2
@LukePuplett: O método de ramificação do Subversion é único. Ele vem do Perforce e acredito que esse é o único outro sistema de controle de versão que o possui. O fato de o subversion não fazer distinção clara do que é um ramo complica muito o algoritmo de mesclagem. Ele oferece alguma flexibilidade, mas essa flexibilidade não é realmente suportável pela mesclagem de três vias, levando a muitos casos de canto difíceis de entender.
Jan Hudec
Até o CVS (que é o antecessor espiritual dos SVNs) não usou essa abordagem (bastante estranha) de ramos e tags, na verdade são diretórios. Não estou dizendo que o CVS fez ramificações bem, mas pelo menos elas apresentavam um conceito "adequado" em vez de apenas um diretório.
Joachim Sauer
@JoachimSauer: Não tenho certeza se o CVS é ​​o antecessor espiritual do Subversion . Eles estabeleceram uma missão para criar "CVS melhor", mas usaram conceitos do Perforce.
Jan Hudec
@JanHudec: isso pode muito bem ser, não sei muito sobre o Perforce. O que eu quis dizer é exatamente essa missão: ser um bom sucessor do CVS.
Joachim Sauer
3

Pense no Git como uma visualização 3D dos mesmos dados que você vê em 2D no SVN - ou seja, com o SVN, você ramifica sua raiz e ela aparece como uma cópia mostrada como uma nova pasta na árvore. Com o Git, quando você ramifica, ele aparece como uma cópia mostrada como uma "camada" na parte superior da sua árvore existente. Depois de perceber que é muito fácil conceituar a diferença.

Com o SVN, você ainda pode trabalhar da mesma maneira que o Git - switch entre ramificações substituirá a visualização única da base de código pela ramificada, isso se aplica se você usar o svn switch ou o git checkout.

Obviamente, você pode obter uma cópia de uma ramificação no SVN verificando a ramificação no local da pasta, o mesmo que clonar um repositório git para um local diferente no seu disco.

O mesmo se aplica às tags - você pode rotular uma revisão git ou criar uma ramificação para uma liberação. As tags SVN são iguais às ramificações, sua única convenção é que elas são chamadas de 'tags'. Você pode rotular (bem, registrar o número da revisão) de um repositório SVN para obter um instantâneo de uma liberação também.

As diferenças entre git e svn têm mais a ver com o modo como o check-in e o check-out acontecem, não com os fundamentos do controle de origem. A visualização do código pode ser diferente (você nunca verá uma única visualização da árvore de código que inclua ramificações no git e poderá ramificar um repositório parcial no SVN, mas essas são, em última instância, pequenas diferenças)

gbjbaanb
fonte