Quelle est la différence pratique entre un référentiel nu et non nu?

Question

J'ai lu des articles sur les dépôts nus et non-nus/par défaut dans Git. Je n'ai pas très bien compris (théoriquement) les différences qui les séparent et pourquoi je devrais "Pousser" vers un référentiel 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 référentiel nu sur tous les ordinateurs, et lorsque je finis mes modifications sur l'un d'entre eux, je valide et modifie les modifications dans le référentiel nu. D'après ce que j'ai lu, le référentiel nu n'a PAS un "arbre de travail", donc si je clone le référentiel nu, 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'apparaîtrait pas dans le compte-rendu simple. Il semble donc préférable pour moi de "Pousser" les commits au repo avec l’arbre de travail.

Alors, pourquoi devrais-je utiliser le référentiel 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 genre de travail? Suggestions?

Derek Mahar · Accepted Answer

Une autre différence entre un référentiel nu et non-nu est qu'un référentiel nu n'a pas de référentiel distant par défaut Origin:

~/Projects$ git clone --bare test bare Initialized empty Git repository in /home/derek/Projects/bare/ ~/Projects$ cd bare ~/Projects/bare$ git branch -a * master ~/Projects/bare$ cd .. ~/Projects$ git clone test non-bare Initialized empty Git repository in /home/derek/Projects/non-bare/.git/ ~/Projects$ cd non-bare ~/Projects/non-bare$ git branch -a * master remotes/Origin/HEAD -> Origin/master remotes/Origin/master

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

La branche se dirige également vers la télécommande sont copiés directement vers .__ correspondant. les chefs des agences locales, 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 nu, Git suppose que celui-ci servira de référentiel Origin pour plusieurs utilisateurs distants, de sorte qu'il ne crée pas l'Origine distant par défaut. Cela signifie que les opérations de base git pull et git Push ne fonctionneront pas, car Git suppose que sans espace de travail, vous n'avez pas l'intention de valider les modifications apportées au référentiel nu:

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

Derek Mahar · Answer

La distinction entre un référentiel Git nu et non nu est artificielle et trompeuse puisqu'un espace de travail ne fait pas partie du référentiel et qu'un référentiel ne nécessite pas d'espace de travail. À proprement parler, un référentiel Git comprend les objets qui décrivent son état. Ces objets peuvent exister dans n'importe quel répertoire, mais généralement dans le répertoire .git du répertoire de niveau supérieur de l'espace de travail. L'espace de travail est une arborescence de répertoires qui représente une validation particulière dans le référentiel, mais elle peut exister dans n'importe quel répertoire ou pas du tout. La variable d'environnement $GIT_DIR relie un espace de travail au référentiel d'où il provient.

Les commandes Git git clone et git init les deux ont les options --bare qui créent des référentiels sans espace de travail initial. Il est regrettable que Git associe les deux concepts d’espace de travail et de référentiel, distincts mais liés, puis utilise le terme déroutant bare pour séparer les deux idées.

Deepak Sharma · Answer

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

Utilisez un référentiel nu sur un serveur distant pour permettre à plusieurs contributeurs de pousser leur travail.
Non-nu - Celui qui a un arbre de travail est logique sur la machine locale de chaque contributeur de votre projet.

EML · Answer

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

Alors, pourquoi devrais-je utiliser le référentiel nu et pourquoi pas? Quel est 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 genre de travail? Suggestions?

Citation directe du livre Loeliger/MCullough (978-1-449-31638-9, p196/7):

Un référentiel nu peut sembler être 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 référentiel et Push le met à jour ... si vous configurez un référentiel dans les développeurs Push change, cela devrait être nu. En effet, c'est un cas particulier de la meilleure pratique plus générale qu’une publication le référentiel doit être nu.

mipadi · Answer

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, balises, etc.); au contraire, l’arbre de travail est juste une représentation des fichiers réels dans le référentiel, ce qui vous permet de travailler sur (éditer, etc.) les fichiers.

sehe · Answer

Un référentiel nu présente des avantages

utilisation réduite du disque
moins de problèmes liés au Push à distance (car aucun arbre de travail ne peut être désynchronisé ou avoir des modifications contradictoires)

Nitin · Answer

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 que par le transport des modifications d'autres référentiels.

BuvinJ · Answer

Je ne suis certainement pas un "expert" Git. J'ai utilisé TortoiseGit pendant un certain temps et je me suis demandé de quoi il parlait quand il m'a demandé si je voulais faire un dépôt «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 il aborde le problème, mais je ne comprenais toujours pas bien le concept . Celui-ci a beaucoup aidé: http://bitflop.com/tutorials/git-bare-vs-non-bare-repositories.html . Maintenant, le premier a également un sens!

Selon ces sources, en résumé, un dépôt "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 validez les validations de votre ordinateur local vers un référentiel nu sur un serveur distant et vous et/ou d'autres personnes extrayez ce référentiel nu vers votre ordinateur local. Ainsi, votre référentiel de stockage/distribution à distance GitHub, Assembla, etc. est un exemple de création d'un référentiel "nu". Vous en feriez un vous-même si vous établissiez votre propre "centre de partage" analogue.

Christoph · Answer

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/

Idem 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/

MichK · Answer

$ git help repository-layout

Un référentiel Git est disponible en deux versions:

un répertoire .git à la racine de l’arbre de travail;

un répertoire .git qui est un répertoire bare (c'est-à-dire sans son propre arbre de travail), généralement utilisé pour échanger des historiques avec d'autres personnes en y insérant et en les extrayant.