wake-up-neo.net

Git: Wo genau ist das "Arbeitsverzeichnis"?

Ich gehe einige Git-Tutorials durch. Das Konzept eines "Arbeitsverzeichnisses" wird immer wieder erwähnt, jedoch zeigt keines der Tutorials oder Dokumente, die ich las, wo oder was dieses "Arbeitsverzeichnis" ist.

Ich habe geglaubt, dass es sich tatsächlich um das übergeordnete Verzeichnis von .git handelt, a.k.a das Verzeichnis, in dem ich git init ausgeführt habe. Aber das Video-Tutorial, das ich gerade anschaue, bespricht den Zustand von nothing, der festgeschrieben werden soll und "working directory clean":

Tatsächlich können Sie tatsächlich eine Kopie des Repositorys erstellen und diese Kopieren Sie es so, dass es kein Arbeitsverzeichnis hat. Dies ist eigentlich nannte den nackten Klon. Dies ist eigentlich was GitHub verwendet.

Wenn mein Verständnis von "Arbeitsverzeichnis" richtig ist, wie kann ein Repository kein "Arbeitsverzeichnis" haben? Und was bedeutet es, wenn es heißt, dass GitHub einen "bare clone" verwendet?

17
shenkwen

Dies sollte hoffentlich für uns klarer werden:

Was ist der Unterschied zwischen einem mit git init .__ erstellten Repository? Befehl und der Befehl git init --bare?

Repositorys, die mit dem Befehl git init erstellt wurden, werden als .__ bezeichnet. Verzeichnisse. Im obersten Ordner des Repositorys finden Sie Zwei Dinge:

A .git subfolder with all the git related revision history of your repo
A working tree, or checked out copies of your project files.

Repositorys, die mit git init --bare erstellt wurden, werden als Bare Repos bezeichnet. Sie sind etwas anders aufgebaut als Arbeitsverzeichnisse. Erst einmal, Sie enthalten keine funktionierende oder ausgecheckte Kopie Ihrer Quelldateien. Und Zweitens: Bare Repos speichern die Revisionshistorie Ihres Repos im Stammverzeichnis Ordner Ihres Repositorys statt in einem .git-Unterordner. Beachten Sie… bare Repositorys erhalten üblicherweise die Erweiterung .git.

Aus John Saints - Was ist ein nackter Git-Speicher?

Ein bloßer Git-Klon enthält also kein Arbeitsverzeichnis mit ausgechecktem Code.
Betrachten Sie es als nur das .git-Verzeichnis (die Git-Datenbank) ohne etwas anderes.

11
jacmoe

Es ist überall dort, wo Sie das Projekt ausgecheckt haben. Zum Beispiel das Verzeichnis, in dem Sie einen Zweig Ihres Projekts ausgecheckt haben. In der Regel ist dies der Ordner, der den Ordner .git enthält. Das ist das Arbeitsverzeichnis. Wenn Sie Änderungen an Dateien in Ihrem ausgecheckten Zweig vornehmen, nehmen Sie Änderungen am Arbeitsverzeichnis vor. Zu diesem Zeitpunkt hat das Arbeitsverzeichnis nicht festgeschriebene Änderungen. Wenn Sie also noch keine Commits gemacht haben, wird das Arbeitsverzeichnis sauber sein, da es keine Änderungen gibt.

5

Das Arbeitsverzeichnis ist einfach Ihr aktuelles lokales Verzeichnis, an dem Sie gerade arbeiten . Wenn Sie beispielsweise master, dev und yourname-dev als Remote-Zweigstellen verwenden, wenn Sie checkout from dev verwenden to yourname-dev , yourname-dev ist jetzt Ihr Arbeitsverzeichnis, wenn Sie aus diesem Arbeitsverzeichnis ( yourname-dev ) ein anderes sagen: dev , dev ist jetzt Ihr neues Arbeitsverzeichnis

3
Babajide Apata

Um die beiden anderen Antworten zu kombinieren:

Wie in der Git Documentation: angegeben

Das Arbeitsverzeichnis ist ein einzelnes Auschecken einer Version des Projekts.

Dies bedeutet im Wesentlichen, dass, wenn Sie einen Zweig auschecken (z. B. master) und sich in einem bestimmten Commit befinden (z. B. HEAD), Ihr Arbeitsverzeichnis der Überbegriff für alle Ihre Dateien und Ordner ist.

Es ist nicht ​​ein bestimmtes Verzeichnis/Ordner. Das Arbeitsverzeichnis umfasst alle Verzeichnisse, Dateien ... alles.
Ich erwähne dies, weil sich diese Dateien im Arbeitsverzeichnis befinden, wenn Sie einige Dateien festschreiben möchten, und Sie müssen stage (using git add) vor dem Festschreiben (mit git commit).

2
Harmelodic

Nach der Dokumentation :

Schließlich haben Sie Ihr Arbeitsverzeichnis. Die beiden anderen Bäume speichern ihren Inhalt auf effiziente, aber unbequeme Weise im .git-Ordner. Das Arbeitsverzeichnis entpackt sie in tatsächliche Dateien, wodurch Sie sie wesentlich einfacher bearbeiten können. Stellen Sie sich das Arbeitsverzeichnis als eine Sandbox vor, in der Sie Änderungen ausprobieren können, bevor Sie sie in Ihren Staging-Bereich (Index) und dann in den Verlauf übernehmen.

1
Michael Ma

Arbeiten Sie direkt in den lokalen Repos?

Wenn ich den Anweisungen von Microsoft folge [ref. https://docs.Microsoft.com/en-us/Azure/devops/repos/git/clone?view=Azure-devops&tabs=visual-studio ], dort öffne ich am Ende die. SLN-Lösungsdatei. Das erscheint mir falsch und bedauerlich, weil ich lieber auf meinem massiven D: -Laufwerk (D:\dev) als in C:\Users \\ source\repos am Code arbeite, wo die Repos standardmäßig aufbewahrt werden (I don Es ist nicht ideal, wenn die lokalen Repos dort aufbewahrt werden, solange ich in meinem D:\dev-Bereich arbeiten kann.

0
Zeek2