it-swarm.com.de

Was ist der praktische Unterschied zwischen einem nackten und einem nicht-nackten Repository?

Ich habe über die nackten und nicht-nackten/Standard-Repositores in Git gelesen. Ich konnte (theoretisch) nicht recht gut verstehen, was die Unterschiede zwischen ihnen sind und warum ich in ein nacktes Repository "pushen" sollte. Das ist der Deal:

Momentan bin ich der einzige, der an einem Projekt auf drei verschiedenen Computern arbeitet. Später werden jedoch noch mehr Personen daran beteiligt sein, daher verwende ich Git für die Versionskontrolle. Ich klone das nackte Repo auf allen Computern, und wenn ich meine Änderungen an einem von ihnen vorgenommen habe, dann verpflichte ich mich und pusche die Änderungen auf das nackte Repo. Nach dem, was ich gelesen habe, hat das nackte Repository KEINEN "Arbeitsbaum". Wenn ich also das nackte Repo klone, habe ich keinen "Arbeitsbaum".

Ich vermute, dass der Arbeitsbaum die Commit-Informationen, Verzweigungen usw. aus dem Projekt speichert. Das würde nicht im nackten Repo erscheinen. Es scheint also besser für mich, die Commits zum Repo mit dem Arbeitsbaum zu "pushen".

Dann, warum sollte ich das nackte Repository verwenden und warum nicht? Was ist der praktische Unterschied? Das würde wohl nicht mehr Leuten nützen, die an einem Projekt arbeiten, nehme ich an.

Was sind Ihre Methoden für diese Art von Arbeit? Vorschläge?

161
AeroCross

Ein weiterer Unterschied zwischen einem bloßen und einem nicht-leeren Repository besteht darin, dass ein blankes Repository kein standardmäßiges Origin - Repository hat:

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

Auf der Handbuchseite für git clone --bare :

Auch der Zweig steht an der Fernbedienung werden direkt in das entsprechende .__ kopiert. lokale Zweigstellen, ohne Zuordnung sie zu refs/remotes/Origin /. Wann Diese Option wird weder verwendet Fernverfolgungszweige noch der verwandte Konfigurationsvariablen sind erstellt.

Vermutlich nimmt Git beim Erstellen eines Bare-Repositorys an, dass das Bare-Repository für mehrere entfernte Benutzer als Origin-Repository dient, und erstellt daher nicht das standardmäßige Remote-Origin. Dies bedeutet, dass grundlegende git pull- und git Push-Vorgänge nicht funktionieren, da Git davon ausgeht, dass Sie ohne einen Arbeitsbereich keine Änderungen am bloßen Repository vornehmen möchten:

~/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$ 
80
Derek Mahar

Die Unterscheidung zwischen einem bloßen und einem nicht-bloßen Git-Repository ist künstlich und irreführend, da ein Arbeitsbereich nicht zum Repository gehört und ein Repository keinen Arbeitsbereich benötigt. Genau genommen umfasst ein Git-Repository die Objekte, die den Status des Repositorys beschreiben. Diese Objekte können in einem beliebigen Verzeichnis vorhanden sein, normalerweise jedoch im Verzeichnis .git im Verzeichnis der obersten Ebene des Arbeitsbereichs. Der Arbeitsbereich ist eine Verzeichnisstruktur, die ein bestimmtes Commit im Repository darstellt. Sie kann jedoch in einem beliebigen Verzeichnis vorhanden sein oder überhaupt nicht. Die Umgebungsvariable $GIT_DIR verknüpft einen Arbeitsbereich mit dem Repository, aus dem er stammt.

Git-Befehle git clone und git init haben beide Optionen --bare, mit denen Repositorys ohne anfänglichen Arbeitsbereich erstellt werden. Es ist bedauerlich, dass Git die zwei getrennten, aber verwandten Konzepte von Arbeitsbereich und Repository zusammenführt und dann den verwirrenden Begriff bare verwendet, um die beiden Ideen zu trennen.

52
Derek Mahar

Ein bloßes Repository ist nichts anderes als der Ordner .git selbst, d. H. Der Inhalt eines leeren Repositorys entspricht dem Inhalt des .git - Ordners in Ihrem lokalen Arbeitsrepository.

  • Verwenden Sie ein leeres Repository auf einem Remote-Server, damit mehrere Mitarbeiter ihre Arbeit pushen können.
  • Nicht bloß - Der Baum, für den ein Arbeitsbaum verwendet wird, ist auf dem lokalen Computer jedes Teilnehmers Ihres Projekts sinnvoll.
46
Deepak Sharma

5 Jahre zu spät, weiß ich, aber eigentlich hat niemand die Frage beantwortet:

Warum sollte ich dann das nackte Repository verwenden und warum nicht? Was ist das praktischer Unterschied? Das wäre nicht für mehr Menschen von Vorteil Ich nehme an, ich arbeite an einem Projekt.

Was sind Ihre Methoden für diese Art von Arbeit? Vorschläge?

Um direkt aus dem Loeliger/MCullough-Buch (978-1-449-31638-9, S. 196/7) zu zitieren:

Ein nacktes Repository mag wenig nützlich sein, aber seine Rolle ist Entscheidend: als maßgebliche Anlaufstelle für die Zusammenarbeit zu dienen Entwicklung. Andere Entwickler clone und fetch vom bloßen Repository und Push werden darauf aktualisiert ... wenn Sie ein Repository in .__ einrichten. welche Entwickler Push ändert, sollte es nackt sein. In der Tat ist das ein spezieller Fall der allgemeineren besten Praxis, die ein veröffentlichtes Repository sollte leer sein.

33
EML

Ein nicht blankes Repository hat lediglich einen ausgecheckten Funktionsbaum. Der Arbeitsbaum speichert keine Informationen zum Status des Repositorys (Zweige, Tags usw.). Der Arbeitsbaum ist lediglich eine Darstellung der tatsächlichen Dateien im Repo, mit denen Sie die Dateien bearbeiten (bearbeiten usw.) können.

17
mipadi

Ein nacktes Repository hat Vorteile in 

  • reduzierte Festplattennutzung 
  • weniger Probleme im Zusammenhang mit Remote-Push (da kein Arbeitsbaum vorhanden ist, um die Synchronisierung zu beenden oder in Konflikt stehende Änderungen zu haben)
12
sehe

Mit dem Non-Bare-Repository können Sie (in Ihrem Arbeitsbaum) Änderungen erfassen, indem Sie neue Commits erstellen. 

Bare Repositorys werden nur durch den Transport von Änderungen aus anderen Repositorys geändert.

10
Nitin

Ich bin sicher kein Git "Experte". Ich habe TortoiseGit für eine Weile benutzt und habe mich gefragt, worüber er redete, als ich gefragt wurde, ob ich ein "nacktes" Repo machen wollte, wann immer ich eines erstellte. Ich habe dieses Tutorial gelesen: https://www.atlassian.com/git/tutorials/setting-up-a-repository/git-init und es geht das Problem an, aber ich verstand das Konzept noch nicht ganz . Dieser hat sehr geholfen: http://bitflop.com/tutorials/git-bare-vs-non-bare-repositories.html . Nun macht auch der erste Sinn!

Nach diesen Quellen wird in Kürze ein "nacktes" Repo auf einem Server verwendet, auf dem Sie einen Verteilungspunkt einrichten möchten. Es ist nicht für die Verwendung auf Ihrem lokalen Computer vorgesehen. Im Allgemeinen Push-Commits von einem lokalen Computer zu einem Bare-Repo auf einem Remote-Server, und Sie und/oder andere Benutzer ziehen von diesem Bare-Repo auf Ihren lokalen Computer. Ihr Repository für GitHub, Assembla usw. ist ein Beispiel, bei dem ein "nacktes" Repo erstellt wird. Sie würden sich selbst eine machen, wenn Sie Ihr eigenes analoges "Sharing Center" einrichten würden. 

6
BuvinJ

Dies ist keine neue Antwort, aber es hat mir geholfen, die verschiedenen Aspekte der obigen Antworten zu verstehen (und es ist zu viel für einen Kommentar). 

Verwenden Sie Git Bash einfach:

[email protected] 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 ../

[email protected] MINGW64 /c/Test
$ git init
Initialized empty Git repository in C:/Test/.git/

[email protected] 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/

[email protected] MINGW64 /c/Test (master)
$ cd .git

[email protected] 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/

Gleiches mit git --bare:

[email protected] 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 ../

[email protected] MINGW64 /c/Test
$ git init --bare
Initialized empty Git repository in C:/Test/

[email protected] 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/
1
Christoph

$ git help repository-layout

Ein Git-Repository gibt es in zwei verschiedenen Varianten:

  • ein .git-Verzeichnis an der Wurzel des Arbeitsbaums;
  • ein .git-Verzeichnis, bei dem es sich um ein bare - Repository handelt (d. h. ohne seinen eigenen Arbeitsbaum), das normalerweise für den Austausch von Historien mit anderen verwendet wird, indem es hinein verschoben und daraus abgerufen wird.
0
MichK