Struktur eines Git-Repositorys

Entschuldigung, wenn dies ein Duplikat ist, habe ich gesucht.

Wir ziehen nach Git um. In Subversion bin ich es gewohnt, Ordner \ trunk, \ branches und \ tags zu haben.

Bei Git ersetzt das Wechseln zwischen Zweigen den Inhalt des Arbeitsverzeichnisses. Darf ich also annehmen, dass die Art und Weise, wie wir früher gearbeitet haben, bei Git nicht zutrifft?

Ich vermute, ich hätte einen Repo-Ordner mit vielleicht einem Gitignore und readme.txt, dann die Ordner für die Projekte, aus denen das Repo besteht, und das war's.

Sie werden "trunk" haben, jetzt "master" genannt, Sie werden "branches" haben, jetzt "heads" genannt und Sie werden "tags" haben, immer noch "tags" genannt, aber sie werden keine Ordner sein , sie werden " refs "bezeichnet Revisionen, die in einem separaten Namespace im Repository gespeichert sind.

Subversion und Git haben verschiedene Möglichkeiten, Verzweigungen durchzuführen. Das grundlegende Subversion-Modell besteht darin, einen Verzeichnisbaum mit einer einzigen globalen Zeitachse zu haben. Wenn Sie verzweigen möchten, kopieren Sie einen Teilbaum in ein anderes Verzeichnis.

Andererseits hat Git einen Verzeichnisbaum mit Revisionen, die jeweils die Eltern definieren, aber jede Revision kann mehrere Eltern (eine Zusammenführung) und mehrere Kinder (Zweige) haben. Anstatt Verzeichnisse für Zweige zu haben, erhalten Sie unabhängig erstellte Revisionen. Die "refs" sind nur Namen, die mit der neuesten Revision für einen bestimmten "Zweig" verbunden sind.

Dieser Unterschied ist für die verteilte Versionskontrolle von grundlegender Bedeutung. Git (und andere verteilte Systeme) haben keine zentrale Berechtigung, um den Verlauf linear zu halten. Daher können Revisionen unabhängig voneinander auf mehreren Repositorys erstellt werden, ohne voneinander Bescheid zu wissen, und das System muss sie berücksichtigen. Es stellt sich heraus, dass die Verallgemeinerung das Verzweigen und Zusammenführen im Allgemeinen viel einfacher macht.

Beachten Sie, dass sich Revisionen in Git in keinem Zweig befinden. Sie sind einfach und Zweige enthalten sie. Sobald der Zweig zusammengeführt wurde oder sich als tote Gasse herausstellt, können Sie einfach den "ref" löschen, der darauf verweist, und ihn ganz vergessen (wenn Sie alte Versuche verwerfen, werden sie irgendwann mit Müll gesammelt git gc). Auf diese Weise vermeiden Sie, dass alte Experimente überfüllt werden, an die sich niemand mehr erinnert.

Stellen Sie sich Git als eine 3D-Ansicht der gleichen Daten vor, die Sie in 2D in SVN sehen - dh mit SVN verzweigen Sie Ihr Stammverzeichnis und es wird als Kopie als neuer Ordner im Baum angezeigt. Wenn Sie mit Git verzweigen, wird es als Kopie angezeigt, die als "Ebene" auf Ihrem vorhandenen Baum angezeigt wird. Sobald Sie feststellen, dass es ziemlich einfach ist, den Unterschied zu konzipieren.

Mit SVN können Sie immer noch genauso arbeiten wie mit Git - switch between branches wird die einzelne Ansicht der Codebasis durch die verzweigte Ansicht ersetzt. Dies gilt unabhängig davon, ob Sie svn switch oder git checkout verwenden.

Offensichtlich können Sie eine Kopie eines Zweigs in SVN erhalten, indem Sie den Zweig in den entsprechenden Ordner auschecken. Dies entspricht dem Klonen eines Git-Repos an einen anderen Speicherort auf Ihrer Festplatte.

Gleiches gilt für Tags - Sie können eine Git-Revision beschriften oder einen Zweig für eine Veröffentlichung erstellen. SVN-Tags sind die gleichen wie Verzweigungen, die einzige Konvention, die sie als "Tags" bezeichnen. Sie können auch die Revisionsnummer eines SVN-Repos beschriften (und notieren), um eine Momentaufnahme eines Releases zu erhalten.

Die Unterschiede zwischen git und svn hängen eher mit dem Ein- und Auschecken zusammen, nicht mit den Grundlagen der Quellcodeverwaltung. Die Ansicht des Codes kann unterschiedlich sein (Sie werden nie eine einzige Ansicht des Codebaums sehen, der Verzweigungen in Git enthält, und Sie können ein partielles Repository in SVN verzweigen, aber dies sind letztendlich geringfügige Unterschiede).