Qual é a diferença - prática-entre um repositório nu e não-Nu?

5 anos atrasado, eu sei, mas ninguém respondeu à pergunta:

Então, porque devo usar o repositório e porque não? O que é? diferença prática? Isso não seria benéfico para mais pessoas. a trabalhar num projecto, suponho.

Quais são os seus métodos para este tipo de trabalho? Sugestões?

Para citar directamente o livro Loeliger / MCullough (978-1-449-31638-9, p196 / 7):

Um repositório pode parecer ser de pouco uso, mas seu papel é crucial: servir como ponto de referência para a colaboração desenvolvimento. Outros programadores clone e fetch do bare repositório e push atualizações para ele... se configurar um repositório para que programadores push muda, deve estar bare. Com efeito, isto é um caso especial das melhores práticas mais gerais publicadas o repositório deve estar vazio.

A distinção entre um repositório de Git bare e não-bare é artificial e enganosa, uma vez que um espaço de trabalho não faz parte do repositório e um repositório não requer um espaço de trabalho. Estritamente falando, um repositório Git inclui os objetos que descrevem o estado do repositório. Estes objetos podem existir em qualquer diretório, mas normalmente existem no diretório .git no diretório de nível superior do espaço de trabalho. O espaço de trabalho é uma árvore de diretórios que representa um commit particular no repositório, mas pode existir em qualquer diretório ou não. A variável de ambiente $GIT_DIR Liga um espaço de trabalho ao repositório de onde provém.

Comandos Gitgit clone e git init ambas têm opções --bare que criam repositórios sem um espaço de trabalho inicial. É lamentável que o Git conforte os dois conceitos separados, mas relacionados de espaço de trabalho e repositório e, em seguida, usa o termo confuso bare para separar as duas ideias.

Um repositório não é nada além do .git pasta em si, ou seja, o conteúdo de um repositório é o mesmo que o conteúdo de .pasta git dentro do seu repositório de trabalho local.

• Use o repositório bare num servidor remoto para permitir que vários contribuidores empurrem o seu trabalho.
• não-nua - a que tem árvore de trabalho faz sentido na máquina local de cada contribuinte do seu projecto.

Um repositório não-bare simplesmente tem uma árvore de trabalho. A árvore de trabalho não armazena nenhuma informação sobre o estado do repositório (branches, tags, etc.); em vez disso, a árvore de trabalho é apenas uma representação dos arquivos reais no repo, que lhe permite trabalhar (editar, etc.) arquivo.

Um repositório simples tem benefícios em

• redução da utilização do disco
• menos problemas relacionados com o remote push (uma vez que não existe nenhuma árvore de trabalho para sair de sincronia ou ter alterações contraditórias)

Um acordo de recompra por omissão/não-bare git contém duas partes de estado:

1. a instantâneo de todos os ficheiros no repositório (isto é o que "Árvore de trabalho" significa no jargão Git)
2. a history of all changes made to all the files that have ever been in the repository (there doesn't seem to be a concise piece of Git jargon that includes all of this)

O instantâneo é o que provavelmente pensa como o seu projecto: os seus ficheiros de código, compilar arquivos, guiões auxiliares, e qualquer outra coisa que você Versão com Git.

O histórico é o estado que lhe permite verificar um commit diferente e obter uma imagem completa de como os ficheiros no seu repositório se pareciam quando esse commit foi adicionado. Consiste de um monte de estruturas de dados que são internas ao Git com que você provavelmente nunca interagiu diretamente. O importante é que o histórico não armazena apenas metadados (por exemplo, " o Usuário U adicionou estas muitas linhas para o arquivo F No Tempo T como parte de Commit C"), também armazena dados (por exemplo, "User U added these exact lines to File F").

A ideia chave de um repositório é que você realmente não precisa ter o instantâneo. O Git mantém a snapshot por perto porque é conveniente para humanos e outros processos não-Git que querem interagir com o seu código, mas a snapshot está apenas duplicando estado que já está na história.

A bare repository é um repositório Git que não tem uma imagem. Ele apenas guarda a história.

Porque queres isto? Bem, se você só vai interagir com seus arquivos usando Git (ou seja, você não vai editar seus arquivos diretamente ou usá-los para construir um executável), você pode economizar espaço, não mantendo em torno da foto. Em particular, se você está mantendo uma versão centralizada de seu repo em algum lugar do servidor (ou seja, você está basicamente hospedando seu próprio GitHub), esse servidor provavelmente deve ter um repo bare (você ainda usaria um repo não-bare) no entanto, em sua máquina local, uma vez que você presumivelmente vai querer editar o seu instantâneo).

Se você quiser uma explicação mais profunda dos repos bare e outro exemplo de caso de uso, eu escrevi um post no blog aqui: https://stegosaurusdormant.com/bare-git-repo/

O repositório não-bare permite-lhe (na sua árvore de trabalho) capturar as alterações através da criação de novos commits.

Repositórios nus só são alterados mediante o transporte de alterações de outros repositórios.

De certeza que não sou um "perito". Eu usei TortoiseGit por um tempo, e me perguntei sobre o que estava falando quando ele me perguntou se eu queria fazer um "bare" repo sempre que eu criei um. Eu estava lendo este tutorial: https://www.atlassian.com/git/tutorials/setting-up-a-repository/git-init e aborda a questão, mas ainda não estava a compreender bem o conceito. Este ajudou muito. http://bitflop.com/tutorials/git-bare-vs-non-bare-repositories.html Agora, o primeiro também faz sentido!

De acordo com estas fontes, em poucas palavras, um repo "bare" é usado num servidor onde você quer configurar um ponto de distribuição. Não está destinado a ser usado na sua máquina local. Você geralmente empurra commits de sua máquina local para um repo bare em um servidor remoto, e você e/ou outros puxam desse repo bare para a sua máquina local. Então seu GitHub, Assemblla, etc. remote storage / distribution repo é um exemplo onde um" bare " repo é criado. Você faria um se você estivesse montando seu próprio "centro de compartilhamento" análogo.

Esta não é uma nova resposta, mas me ajudou a entender os diferentes aspectos das respostas acima (e é demais para um comentário).

Usando o Git Bash tente apenas:

me@pc MINGW64 /c/Test
$ ls -al
total 16
drwxr-xr-x 1 myid 1049089 0 Apr  1 11:35 ./
drwxr-xr-x 1 myid 1049089 0 Apr  1 11:11 ../

me@pc MINGW64 /c/Test
$ git init
Initialized empty Git repository in C:/Test/.git/

me@pc MINGW64 /c/Test (master)
$ ls -al
total 20
drwxr-xr-x 1 myid 1049089 0 Apr  1 11:35 ./
drwxr-xr-x 1 myid 1049089 0 Apr  1 11:11 ../
drwxr-xr-x 1 myid 1049089 0 Apr  1 11:35 .git/

me@pc MINGW64 /c/Test (master)
$ cd .git

me@pc MINGW64 /c/Test/.git (GIT_DIR!)
$ ls -al
total 15
drwxr-xr-x 1 myid 1049089   0 Apr  1 11:35 ./
drwxr-xr-x 1 myid 1049089   0 Apr  1 11:35 ../
-rw-r--r-- 1 myid 1049089 130 Apr  1 11:35 config
-rw-r--r-- 1 myid 1049089  73 Apr  1 11:35 description
-rw-r--r-- 1 myid 1049089  23 Apr  1 11:35 HEAD
drwxr-xr-x 1 myid 1049089   0 Apr  1 11:35 hooks/
drwxr-xr-x 1 myid 1049089   0 Apr  1 11:35 info/
drwxr-xr-x 1 myid 1049089   0 Apr  1 11:35 objects/
drwxr-xr-x 1 myid 1049089   0 Apr  1 11:35 refs/

O mesmo com git --bare:

me@pc MINGW64 /c/Test
$ ls -al
total 16
drwxr-xr-x 1 myid 1049089 0 Apr  1 11:36 ./
drwxr-xr-x 1 myid 1049089 0 Apr  1 11:11 ../

me@pc MINGW64 /c/Test
$ git init --bare
Initialized empty Git repository in C:/Test/

me@pc MINGW64 /c/Test (BARE:master)
$ ls -al
total 23
drwxr-xr-x 1 myid 1049089   0 Apr  1 11:36 ./
drwxr-xr-x 1 myid 1049089   0 Apr  1 11:11 ../
-rw-r--r-- 1 myid 1049089 104 Apr  1 11:36 config
-rw-r--r-- 1 myid 1049089  73 Apr  1 11:36 description
-rw-r--r-- 1 myid 1049089  23 Apr  1 11:36 HEAD
drwxr-xr-x 1 myid 1049089   0 Apr  1 11:36 hooks/
drwxr-xr-x 1 myid 1049089   0 Apr  1 11:36 info/
drwxr-xr-x 1 myid 1049089   0 Apr  1 11:36 objects/

$ git help repository-layout

Um repositório Git vem em dois sabores diferentes:

• a.pasta git na raiz da árvore de trabalho;
• a.o diretório git que é um repositório bare (isto é, SEM SUA própria árvore de trabalho), que é tipicamente usado para trocar histórias com outros, empurrando-o para dentro e obtendo-o.