Estrutura de um repositório Git

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.

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.

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)