Question Quelle est la différence pratique entre un référentiel Bare et non-Bare?


J'ai lu des articles sur les référentiels nus et non-nus / par défaut dans Git. Je n'ai pas bien compris (théoriquement) les différences entre eux et pourquoi je devrais "pousser" vers un dépôt nu. Voici le deal:

Actuellement, je suis le seul à travailler sur un projet sur 3 ordinateurs différents, mais il y aura plus de personnes impliquées plus tard, donc j'utilise Git pour le contrôle de version. Je clone le nu repo sur tous les ordinateurs et quand je finis mes modifications sur l'un d'entre eux, je commets et repousse les modifications sur le nu repo. D'après ce que j'ai lu, le dépôt nu n'a pas d'arbre de travail, donc si je clone le nu repo, je n'aurai pas d'arbre de travail.

Je suppose que l'arborescence de travail stocke les informations de validation, les branches, etc. du projet. Cela n'apparaitrait pas dans le nu repo. Il me semble donc préférable de "pousser" les commits vers le repo avec l'arbre de travail.

Alors, pourquoi devrais-je utiliser le dépôt nu et pourquoi pas? Quelle est la différence pratique? Cela ne serait pas bénéfique pour plus de personnes travaillant sur un projet, je suppose.

Quelles sont vos méthodes pour ce type de travail? Suggestions?


135
2018-04-04 15:38


origine


Réponses:


Une autre différence entre un référentiel nu et non dépouillé réside dans le fait qu’un référentiel non hébergé n’a pas de télécommande par défaut origine dépôt:

derek@derek-OptiPlex-960:~/Projects$ git clone --bare test bare
Initialized empty Git repository in /home/derek/Projects/bare/
derek@derek-OptiPlex-960:~/Projects$ cd bare
derek@derek-OptiPlex-960:~/Projects/bare$ git branch -a
* master
derek@derek-OptiPlex-960:~/Projects/bare$ cd ..
derek@derek-OptiPlex-960:~/Projects$ git clone test non-bare
Initialized empty Git repository in /home/derek/Projects/non-bare/.git/
cd nonderek@derek-OptiPlex-960:~/Projects$ cd non-bare
derek@derek-OptiPlex-960:~/Projects/non-bare$ git branch -a
* master
  remotes/origin/HEAD -> origin/master
  remotes/origin/master

De la page de manuel pour git clone --bare:

Aussi la branche se dirige vers la télécommande   sont copiés directement dans   chefs de branche locaux, sans cartographie   eux à refs / télécommandes / origine /. Quand   cette option est utilisée, ni   branches de suivi à distance, ni le   les variables de configuration associées sont   créé.

Vraisemblablement, lorsqu'il crée un référentiel dénué, Git suppose que le référentiel dénudé servira de référentiel d'origine pour plusieurs utilisateurs distants. Par conséquent, il ne crée pas l'origine distante par défaut. Qu'est-ce que cela signifie est que base git pull et git push les opérations ne fonctionneront pas car Git suppose que sans espace de travail, vous n'avez pas l'intention de commettre de modifications sur le référentiel nu:

derek@derek-OptiPlex-960:~/Projects/bare$ git push
fatal: No destination configured to push to.
derek@derek-OptiPlex-960:~/Projects/bare$ git pull
fatal: /usr/lib/git-core/git-pull cannot be used without a working tree.
derek@derek-OptiPlex-960:~/Projects/bare$ 

69
2018-04-04 17:11



La distinction entre un référentiel Git nu et non nu est artificielle et trompeuse car un espace de travail ne fait pas partie du référentiel et un référentiel ne nécessite pas d'espace de travail. Strictement parlant, un référentiel Git comprend les objets qui décrivent l’état du référentiel. Ces objets peuvent exister dans n'importe quel répertoire, mais existent généralement dans le répertoire. .git répertoire dans le répertoire racine de l'espace de travail. L'espace de travail est une arborescence de répertoires qui représente un commit particulier dans le référentiel, mais il peut exister dans n'importe quel répertoire ou pas du tout. Variable d'environnement $GIT_DIR relie un espace de travail au référentiel d'où il provient.

Commandes Git git clone et git init les deux ont des options --bare qui créent des référentiels sans espace de travail initial. Il est malheureux que Git confonde les deux concepts distincts mais liés de l'espace de travail et du référentiel, puis utilise le terme confus nu séparer les deux idées.


50
2018-04-04 19:23



Un dépôt nu n’est rien d’autre que le .git dossier lui-même, c’est-à-dire que le contenu d’un dépôt nu est identique à celui de .git dossier dans votre référentiel de travail local.

  • Utilisez le dépôt nu sur un serveur distant pour permettre à plusieurs contributeurs de faire avancer leur travail.
  • Non-nu - Celui qui a un arbre de travail a un sens sur la machine locale de chaque contributeur de votre projet.

35
2018-02-10 09:58



5 ans trop tard, je sais, mais personne n'a répondu à la question:

Alors, pourquoi devrais-je utiliser le dépôt nu et pourquoi pas? Qu'est ce que le   différence pratique? Cela ne serait pas bénéfique pour plus de gens   travailler sur un projet, je suppose.

Quelles sont vos méthodes pour ce type de travail? Suggestions?

Pour citer directement le livre Loeliger / MCullough (978-1-449-31638-9, p196 / 7):

Un dépôt nu peut sembler peu utile, mais son rôle est   crucial: servir de point focal faisant autorité pour la collaboration   développement. Autres développeurs clone et fetch du nu   dépôt et push mises à jour à elle ... si vous configurez un référentiel dans   quels développeurs push changements, il devrait être nu. En effet, c'est   un cas particulier de la meilleure pratique plus générale   le dépôt doit être nu.


23
2018-03-20 10:04



Un référentiel non nu a simplement un arbre de travail extrait. L'arbre de travail ne stocke aucune information sur l'état du référentiel (branches, tags, etc.); l'arborescence de travail est plutôt une représentation des fichiers réels du dépôt, ce qui vous permet de travailler sur (éditer, etc.) les fichiers.


17
2018-04-04 15:41



Un dépôt nu a des avantages dans

  • utilisation réduite du disque
  • moins de problèmes liés à la diffusion à distance (car aucun arbre de travail n'est là pour se synchroniser ou présenter des modifications contradictoires)

11
2018-04-04 15:48



Le référentiel non nu vous permet (dans votre arbre de travail) de capturer les modifications en créant de nouveaux commits.

Les référentiels nus ne sont modifiés qu'en transportant les modifications des autres référentiels.


9
2018-06-02 09:24



Je ne suis certainement pas un "expert" Git. J'ai utilisé TortoiseGit pendant un moment et je me demandais de quoi il parlait quand il m'a demandé si je voulais faire un repo "nu" chaque fois que j'en créais un. Je lisais ce tutoriel: https://www.atlassian.com/git/tutorials/setting-up-a-repository/git-init et cela résout le problème, mais je ne comprenais toujours pas le concept. Celui-ci a beaucoup aidé: http://bitflop.com/tutorials/git-bare-vs-non-bare-repositories.html. Maintenant, le premier a aussi du sens!

Selon ces sources, un repo «nu» est utilisé sur un serveur sur lequel vous souhaitez configurer un point de distribution. Il n'est pas destiné à être utilisé sur votre ordinateur local. En règle générale, vous transférez les validations de votre ordinateur local vers un serveur distant, et vous et / ou les autres utilisateurs pouvez les transférer sur votre ordinateur local. Ainsi, votre référentiel de stockage / distribution à distance GitHub, Assembla, etc. est un exemple où un dépôt «nu» est créé. Vous en feriez un vous-même si vous créiez votre propre "centre de partage" analogue.


6
2017-08-11 14:21



Ce n'est pas une nouvelle réponse, mais cela m'a aidé à comprendre les différents aspects des réponses ci-dessus (et c'est trop pour un commentaire).

En utilisant Git Bash, essayez simplement:

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/

Même avec 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/

0
2018-04-03 09:52