Quelle est la différence entre "git init" et "git init --bare"?
Quelle est la différence entre git init et git init --bare? J'ai trouvé que beaucoup d'articles de blog nécessitent --bare pour leur serveur Git?
De la page de manuel , il était écrit:
--bareCréez un référentiel nu. Si l'environnement GIT_DIR n'est pas défini, il est défini sur le répertoire de travail actuel.
Mais qu'est-ce que cela signifie réellement? Est-il nécessaire d'avoir --bare pour la configuration du serveur Git?
Repo Git non nu
Cette variante crée un référentiel avec un répertoire de travail afin que vous puissiez réellement travailler (git clone). Après l'avoir créé, vous verrez que le répertoire contient un dossier .git où se trouvent l'historique et toute la plomberie de git. Vous travaillez au niveau où se trouve le dossier .git.
Bare Git Repo
L’autre variante crée un référentiel sans répertoire de travail (git clone --bare). Vous n'obtenez pas un répertoire où vous pouvez travailler. Tout ce qui se trouve dans le répertoire correspond maintenant à ce qui était contenu dans le dossier .git dans le cas ci-dessus.
Pourquoi utiliser l'un ou l'autre
Le besoin de git repos sans répertoire de travail réside dans le fait que vous pouvez y envoyer des branches et que cela ne gère pas le travail de quelqu'un. Vous pouvez toujours envoyer vers un référentiel non nu, mais vous serez rejeté car vous pouvez potentiellement déplacer une branche sur laquelle une personne travaille dans ce répertoire de travail.
Ainsi, dans un projet sans dossier de travail, vous ne pouvez voir que les objets tels que git les stocke. Ils sont compressés, sérialisés et stockés sous le SHA1 (un hachage) de leur contenu. Pour obtenir un objet dans un référentiel nu, vous devez git show puis spécifiez le sha1 de l'objet que vous voulez voir. Vous ne verrez pas une structure semblable à celle de votre projet.
Les dépôts nus sont généralement des dépôts centraux où chacun déplace son travail. Il n'est pas nécessaire de manipuler le travail réel. C'est un moyen de synchroniser les efforts entre plusieurs personnes. Vous ne pourrez pas voir directement les fichiers de votre projet.
Vous n'avez peut-être pas besoin de référentiels nus si vous êtes le seul à travailler sur le projet ou si vous ne souhaitez pas/n'avez pas besoin d'un référentiel "logiquement central". On préférerait git pullfrom les autres référentiels dans ce cas. Cela évite les objections que git a lors du transfert vers des référentiels non nus.
J'espère que cela t'aides
Réponse courte
Un référentiel nu est un référentiel git sans copie de travail. Par conséquent, le contenu de .git est de niveau supérieur pour ce répertoire.
Utilisez un référentiel non-nu pour travailler localement et un référentiel nu en tant que serveur/concentrateur central pour partager vos modifications avec d'autres personnes. Par exemple, lorsque vous créez un référentiel sur github.com, il est créé en tant que référentiel nu.
Donc, dans votre ordinateur:
git init
touch README
git add README
git commit -m "initial commit"
sur le serveur:
cd /srv/git/project
git init --bare
Ensuite sur le client, vous appuyez sur:
git Push username@server:/srv/git/project master
Vous pouvez ensuite enregistrer vous-même la saisie en l'ajoutant comme télécommande.
Le référentiel côté serveur va recevoir des validations via pull et push, et non pas en modifiant des fichiers puis en les validant sur la machine du serveur. Il s'agit donc d'un référentiel nu.
Détails
Vous pouvez transférer vers un référentiel qui n'est pas un référentiel nu, et git découvrira qu'il existe un référentiel .git, mais comme la plupart des référentiels "hub" n'ont pas besoin d'une copie de travail, il est normal d'utiliser un référentiel nu pour il est recommandé car il est inutile de disposer d’une copie de travail dans ce type de référentiels.
Cependant, si vous appuyez sur un référentiel non nu, vous rendez la copie de travail incohérente et git vous préviendra:
remote: error: refusing to update checked out branch: refs/heads/master
remote: error: By default, updating the current branch in a non-bare repository
remote: error: is denied, because it will make the index and work tree inconsistent
remote: error: with what you pushed, and will require 'git reset --hard' to match
remote: error: the work tree to HEAD.
remote: error:
remote: error: You can set 'receive.denyCurrentBranch' configuration variable to
remote: error: 'ignore' or 'warn' in the remote repository to allow pushing into
remote: error: its current branch; however, this is not recommended unless you
remote: error: arranged to update its work tree to match what you pushed in some
remote: error: other way.
remote: error:
remote: error: To squelch this message and still keep the default behaviour, set
remote: error: 'receive.denyCurrentBranch' configuration variable to 'refuse'.
Vous pouvez ignorer cet avertissement. Toutefois, la configuration recommandée est la suivante: utilisez un référentiel non-nu pour travailler localement et un référentiel nu en tant que concentrateur ou serveur central vers lequel pousser et extraire.
Si vous souhaitez partager le travail directement avec la copie de travail d'un autre développeur, vous pouvez extraire les autres dépôts plutôt que de les pousser.
Quand j'ai lu cette question il y a quelque temps, tout me déroutait. Je viens juste de commencer à utiliser git et il y a ces copies de travail (ce qui ne voulait rien dire à cette époque). Je vais essayer d’expliquer cela du point de vue du gars, qui vient de commencer git sans aucune idée de la terminologie.
Un bel exemple des différences peut être décrit de la manière suivante :
--bare vous donne juste un lieu de stockage (vous ne pouvez pas y développer). Sans pour autant --bare il vous donne la possibilité de vous y développer (et d’avoir un lieu de stockage).
git init crée un référentiel Git à partir de votre répertoire actuel. Il ajoute un dossier .git à l’intérieur de celui-ci et permet de démarrer votre historique de révision.
git init --bare crée également un référentiel, mais il n’a pas le répertoire de travail. Cela signifie que vous ne pouvez pas éditer de fichiers, valider vos modifications, ajouter de nouveaux fichiers dans ce référentiel.
Quand --bare _ peut être utile? Vous et quelques autres personnes travaillez sur le projet et utilisez git. Vous avez hébergé le projet sur un serveur (Amazon ec2). Chacun de vous a sa propre machine et vous poussez votre code sur ec2. Aucun de vous ne développe réellement quelque chose sur ec2 _ (vous utilisez vos machines) - vous venez de pousser votre code. Donc, votre ec2 est juste un stockage pour tout votre code et devrait être créé en tant que --bare et toutes vos machines sans --bare _ (probablement un seul, et les autres vont tout simplement cloner). Le flux de travail ressemble à ceci:
Un référentiel Git par défaut suppose que vous l'utiliserez comme répertoire de travail. Généralement, lorsque vous êtes sur un serveur, vous n'avez pas besoin d'un répertoire de travail. Juste le référentiel. Dans ce cas, vous devriez utiliser le --bare option.
Un référentiel non-nu est la valeur par défaut. C'est ce qui est créé lorsque vous exécutez git init, ou ce que vous obtenez lorsque vous clonez (sans l'option bare) à partir d'un serveur.
Lorsque vous travaillez avec un référentiel comme celui-ci, vous pouvez voir et éditer tous les fichiers qui se trouvent dans le référentiel. Lorsque vous interagissez avec le référentiel - par exemple en validant une modification - Git stocke vos modifications dans un répertoire caché appelé .git.
Lorsque vous avez un serveur git, il n’est pas nécessaire de disposer de copies de travail des fichiers. Tout ce dont vous avez besoin, ce sont les données Git qui sont stockées dans .git. Un référentiel nu est exactement le .git répertoire, sans zone de travail pour modifier et valider des fichiers.
Lorsque vous clonez sur un serveur, Git dispose de toutes les informations nécessaires dans le .git répertoire pour créer votre copie de travail.