Was hat es mit Git und Subversion auf sich?

Question

Ich sehe viele Websites, die sich auf Git, Github, Svn, Subversion usw. beziehen, aber ich wusste nie wirklich, was all diese Dinge sind. Ich höre auch viele Begriffe wie "svn repo", "commit" und "push" - ich habe versucht zu googeln, aber es scheint, dass ich so wenig Wissen über das Thema habe, dass ich nicht einmal weiß, wo ich anfangen soll.

Könnte mir jemand den Anstoß geben, damit ich auf eigene Faust weiterforschen kann? Was hat es mit diesen Dingen auf sich?

Danke!

Leute: vielen Dank für all die wirklich langen und umfassenden Erklärungen. Ich wünschte, ich könnte mehr als eine Antwort wählen, aber leider lässt SO das nicht zu (sie sollten eine Funktion zur Abstimmung über Platz 1, 2 und 3 haben oder so). vielen Dank an alle!

Answer 1

Versionskontrolle (auch bekannt als Revisionskontrolle).

Betrachten Sie das folgende Problem. Sie arbeiten mit einer anderen Person an einem Projekt und tauschen Dateien aus. Sie müssen beide an, sagen wir, "WhateverController.java" arbeiten. Es ist eine große Datei und Sie müssen sie beide bearbeiten.

Die primitivste Art, damit umzugehen, ist, die Datei nicht gleichzeitig zu bearbeiten, aber dann müssen Sie beide auf der gleichen Seite sein. Wenn Sie ein Team haben, vor allem, wenn das Team Dutzende oder Hunderte oder Tausende von Mitgliedern hat (typisch für Open-Source-Projekte), wird dies völlig unmöglich.

Eine alte, primitive "Lösung" für dieses Problem war ein Checkout/Checkin-Mechanismus. Wenn Sie eine Datei bearbeiten müssen, "checken Sie sie aus", und die Datei wird gesperrt, so dass niemand sie bearbeiten kann, bis Sie sie durch "Einchecken" entsperren. Dies geschieht durch die entsprechende Software, zum Beispiel Microsofts atemberaubend dummes Stück Mist SourceSafe. Aber wenn man vergisst, die Datei "einzuchecken", kann niemand sonst diese Datei bearbeiten, solange sie in Gebrauch ist. Dann geht jemand in den Urlaub oder verlässt das Projekt aus einem anderen Grund und das Ergebnis ist ein nicht enden wollendes Chaos, Verwirrung und in der Regel eine ganze Menge verlorener Code. Das bedeutet einen enormen Verwaltungsaufwand.

Dann kam CVS und später Subversion, das die Autoren als "CVS done right" bezeichnen, CVS und Subversion sind also im Wesentlichen dasselbe. Bei diesen Systemen gibt es kein tatsächliches Auschecken. Sie bearbeiten einfach die Dateien, die Sie benötigen, und checken sie ein. Beachten Sie, dass die eigentlichen Dateien auf einem zentralen Server gespeichert werden und jeder Benutzer die Software auch auf seinen eigenen Workstations ausführt. Dieser Speicherort auf dem Server wird als Repository bezeichnet.

Was passiert nun, wenn zwei Personen an der gleichen Datei in CVS/Subversion arbeiten? Sie werden zusammengeführt, normalerweise mit GNU diff und patch. diff' ist ein Dienstprogramm, das den Unterschied zwischen zwei Dateien extrahiert. patch' benutzt solche 'diff'-Dateien, um andere Dateien zu patchen.

Wenn Sie also in einer Funktion an WhateverController.java arbeiten und ich in einer anderen Funktion an der gleichen Datei, dann checken Sie sie einfach ein, wenn Sie mit Ihrer Arbeit fertig sind, und die Änderungen werden auf die Datei auf dem Server angewendet. In der Zwischenzeit hat meine lokale Kopie keine Ahnung von Ihren Änderungen, so dass sich Ihre Änderungen überhaupt nicht auf meinen Code auswirken. Wenn ich mit meinen Änderungen fertig bin, checke ich die Datei ebenfalls ein. Aber jetzt haben wir dieses scheinbar komplizierte Szenario.

Nennen wir das Original WhateverController.java, Datei A. Sie bearbeiten die Datei, und das Ergebnis ist Datei B. Ich bearbeite dieselbe Datei an einem anderen Ort, ohne Ihre Änderungen, und diese Datei ist Datei C.

Jetzt haben wir anscheinend ein Problem. Die Änderungen von Datei B und C sind beides Änderungen an Datei A. Also wird in einem lächerlich rückwärtsgewandten Junk wie SourceSafe oder Dreamweaver normalerweise die Änderung von Datei B überschrieben (weil sie zuerst eingecheckt wurde).

CVS/Subversion und vermutlich auch Git (über das ich so gut wie nichts weiß) erstellen Patches, anstatt Dateien einfach zu überschreiben.

Die Differenz zwischen den Dateien A und C wird erzeugt und zu Patch X. Die Differenz zwischen A und B wird erzeugt und zu Patch Y.

Dann werden die Patches X und Y auf die Datei A angewendet, so dass das Endergebnis die Datei A + die Änderungen an B und C auf unseren jeweiligen Arbeitsstationen ist.

Normalerweise funktioniert das einwandfrei. Manchmal arbeiten wir an der gleichen Funktion im gleichen Code. In diesem Fall wird CVS/Subversion den Programmierer auf ein Problem hinweisen und das Problem in der Datei selbst darstellen. Diese Probleme lassen sich in der Regel leicht beheben, zumindest hatte ich noch nie ein Problem mit ihnen. Grafische Hilfsprogramme wie Visual Studio, Project Builder (Mac OS X) und dergleichen zeigen in der Regel beide Dateien und die Konflikte an, so dass man auswählen kann, welche Zeilen man behalten und welche man wegwerfen möchte... und dann kann man die Datei auch manuell bearbeiten, wenn man den Konflikt manuell zusammenführen möchte.

Im Grunde genommen ist die Versionskontrolle also eine Lösung für das Problem, dass mehrere Personen an denselben Dateien arbeiten. Das ist im Grunde alles.

Ich hoffe, das erklärt alles.

EDIT: Es gibt noch viele andere Vorteile von vernünftigen Versionskontrollsystemen wie Subversion und vermutlich Git. Wenn es ein Problem gibt, kann man zu anderen Versionen zurückgehen, so dass man nicht alles manuell sichern muss. In der Tat, zumindest mit Subversion, wenn ich etwas vermassle oder einen Blick auf eine alte Version des Codes werfen will, kann ich das tun, ohne die Arbeit von jemand anderem zu stören.

Answer 2

Bei GIT, Subversion und Co. dreht sich alles um Versionskontrolle. Wenn Sie solche Technologien für ein Projekt verwenden, werden alle Ihre Quelldateien in einem sogenannten Repository (auch "Repo" genannt) gespeichert - mit Ausnahme der Dateien, die keine Versionierung benötigen (große Dateien, benutzerspezifische Dateien, ...).

Einige Vorteile der Versionskontrolle sind:

• Zweige. Sie können z.B. für jeden Fehler, an dem Sie arbeiten, einen neuen Zweig erstellen, ohne den Code anderer Entwickler zu manipulieren. Die meisten Versionskontrollsysteme erstellen billige Kopien, d.h. ein neuer Zweig nimmt (fast) keinen zusätzlichen Platz in Anspruch.
• Versionierung. Sie können jederzeit zu alten Versionen zurückkehren, auf neue Versionen aktualisieren oder sich das Übergabeprotokoll ansehen, um zu sehen, was am Code passiert ist. GUI-Tools wie TortoiseSVN bieten sogar Diff-Programme, die Ihnen die Unterschiede grafisch anzeigen. Der Begriff "Übertragen" Grundsätzlich bedeutet, neue Versionen von Dateien in das Repository zu stellen (oder Dateien hinzuzufügen/löschen). Versionskontrollsysteme unterstützen auch das "Zusammenführen", d. h. das automatische Zusammenführen von Änderungen an einer Datei, die von mehreren Personen (oft zeilenweise) geändert wurde.
• Gleichzeitige Entwicklung. Mehrere Entwickler können ihre eigene "Arbeitskopie" (auch "Checkout" genannt) haben. Das bedeutet, dass - auch wenn Sie keine Zweige verwenden - Ihre lokale Code-Kopie kompiliert wird, auch wenn andere gerade an dem Projekt arbeiten (weil sie eigene Arbeitskopien haben). Wenn Sie das Gefühl haben, dass der aktuelle Code für andere nützlich sein kann, können Sie Ihre Änderungen übertragen, und andere können ihre Kopie aktualisieren.
• Zentrale Speicherung und Sicherung. Dies gilt für CVS/Subversion/..., nicht für GIT. Es ist ein Vorteil, weil es einen zentralen Ort gibt, an den Änderungen übertragen werden können und an dem Änderungen von anderen Entwicklern gezogen werden können.
• Vertrieb. Dies gilt jedoch nur für GIT (nicht für Subversion). Es bedeutet, dass es mehrere Repositories für ein Projekt geben kann, die voneinander unabhängig sind. Der Linux-Kernel zum Beispiel hat dies. Leute können ihr eigenes Repository, an dem sie arbeiten, "herunterziehen" - es verhält sich wie ein vollständiges Repository, d.h. Commits werden lokal und nicht an einen Server gemacht. Wenn Sie Patches aus den Repositories anderer Leute einbinden wollen (oder aus öffentlichen Repositories wie kernel.org ), "ziehen" Sie diese Änderungen einfach in Ihr lokales Repository. Wenn Sie jemand anderem Ihren Patch zur Verfügung stellen wollen, "pushen" Sie Ihre Änderungen in ein entferntes Repository (wenn Sie die Rechte dazu haben).

Ich hoffe, das erklärt die von Ihnen genannten Begriffe. Ich denke, ein guter Einstieg in die Versionskontrolle ist Subversion, mit TortoiseSVN für Windows wenn möglich. Es gibt sogar ein kostenloses Buch darüber - Versionskontrolle mit Subversion .

Answer 3

Es handelt sich um verschiedene Versionen der Versionskontrolle:

http://en.wikipedia.org/wiki/Revision_control

Answer 4

" Die Git-Parabel " von Tom Preston-Warner (mojombo), einem der Köpfe hinter GitHub, beschreibt, wie Versionskontrollsysteme wie Git, könnte gemacht worden sind... und gleichzeitig beschreiben, warum man ein (verteiltes) Versionskontrollsystem will und braucht.

Siehe auch " Ein visueller Leitfaden zur Versionskontrolle " Artikel bei Better Explained.

---

Die Verwendung eines Versionskontrollsystems hat viele Vorteile. Führen wir sie grob in der Reihenfolge zunehmender Komplexität auf: zunehmende Anzahl von Entwicklern, zunehmende Projektgröße/Projektverlaufsgröße, komplexere Arbeitsabläufe usw.

Ein Entwickler, eine Branche

Selbst wenn Sie der einzige Entwickler Ihres Projekts sind und (zumindest vorläufig) nicht vorhaben, es zu ändern, ist ein Versionskontrollsystem dennoch nützlich. Sie erlaubt es:

• Zu einer funktionierenden Version zurückkehren . Wenn Sie an Ihrem Projekt arbeiten und feststellen, dass Sie es komplett vermasselt haben, der Ansatz, den Sie ausprobiert haben, nicht funktioniert und Sie nicht wissen, wie Sie es zum Laufen bringen können, ist es schön, wenn Sie einfach zur letzten funktionierenden Version zurückgehen und neu beginnen können.

  Das bedeutet, dass Sie einen Commit durchführen sollten, d.h. einen Schnappschuss Ihrer Änderungen machen sollten, wenn Sie eine funktionierende Version haben (es gibt allerdings Ausnahmen, siehe unten). Um nicht zu viel Arbeit zu verlieren, sollten Sie relativ oft committen, am besten (siehe unten) wenn Sie ein einzelnes Feature, ein einzelnes Problem oder einen einzelnen Teil eines Features oder Problems fertiggestellt haben.

  Sie würden auch gerne wissen, was Sie getan haben und woran Sie in letzter Zeit gearbeitet haben. Das bedeutet, dass Sie jeden Änderungssatz (jede Übertragung) beschreiben sollten.

• Datei mit Anmerkungen versehen / Verlauf durchsuchen . Wenn Sie nicht über ein perfektes Gedächtnis verfügen, möchten Sie manchmal wissen, warum (und wann, und wenn es mehrere Entwickler gibt, auch wer) Sie eine bestimmte Reihe von Zeilen geschrieben haben. Kommentare sind nicht immer genug. Dafür können Sie (wenn Ihr Versionskontrollsystem dies anbietet) zeilenweise Dateiverlaufsanmerkungen verwenden ( scm annotate o scm blame ), oder andere ähnliche Werkzeuge wie die so genannte "Pickel"-Suche in Git, bei der man die Historie nach Commits durchsucht, die einen bestimmten String hinzugefügt oder gelöscht haben.

  Damit dies nützlich ist, müssen Sie gute Commit-Nachrichten schreiben, die die Änderung und die Absicht der Änderung beschreiben, damit Sie wissen, warum die Änderung vorgenommen wurde.

• Geschichte halbieren, um Fehler zu finden . Moderne Versionskontrollsysteme bieten eine Alternative (zum Einfügen von Druckanweisungen oder Debugger), um Fehler zu finden... zumindest in einigen Fällen. Wenn Sie einen Fehler bemerken, oder einen Fehlerbericht erhalten, und der Fehler nicht das Ergebnis der letzten Änderung ist, können Sie das Versionskontrollsystem ( csm bisect ), um automatisch den Commit zu finden, der den Fehler eingeführt hat (der erste Commit, der den Fehler enthält). Das Versionskontrollsystem findet einen solchen Commit, indem es die Projekthistorie halbiert und Versionen, die Sie als gut (ohne Fehler) oder schlecht markieren, abruft (auscheckt), bis es die Commits findet, die den Fehler eingeführt haben.

  Deshalb sollte man immer sicherstellen, dass die Version funktioniert (oder zumindest kompiliert), bevor man sie überträgt, sonst kann man nicht entscheiden, ob die Übertragung einen Fehler hat oder nicht. Sie sollten Commits klein halten (mit nicht vielen Änderungen), so dass Sie, wenn Sie einen Commit finden, der einen Fehler enthält, nur eine kleine Anzahl von Zeilen überprüfen müssen, die von der Änderung betroffen sind. Sie bräuchten auch gute Commit-Meldungen, damit Sie wissen warum die Änderung vorgenommen wurde (und entscheiden, ob die Änderung korrekt ist oder nicht).

Mehrere Zweigstellen

Später werden Sie eine weitere Funktion eines Versionskontrollsystems benötigen: die Möglichkeit, parallel an verschiedenen Entwicklungslinien (Flavors) Ihres Projekts zu arbeiten, die so genannte Zweigstellen . Dazu gehören unter anderem:

• Taging-Freigaben . Wenn Sie eine neue Version Ihres Projekts für ein größeres Publikum freigeben, sollten Sie die freigegebene Version kennzeichnen (markieren). Wenn Ihnen jemand mitteilt, dass Version X.Y Ihres Projekts einen Fehler hat, können Sie auf diese Weise diese Version überprüfen und feststellen, ob Sie diesen Fehler reproduzieren können (und vielleicht einen Fehler durch Bisektion finden, siehe oben). Dies könnte auch dann von Nutzen sein, wenn Sie Ihr Projekt nicht veröffentlichen, wenn Sie möglicherweise verschiedene Versionen an verschiedenen Orten einsetzen.

  Zu diesem Zweck müssen die Tags natürlich unveränderlich sein.

• Langlebige Zweige . Nehmen wir an, Sie haben Ihr Projekt veröffentlicht, und jemand hat einen Fehler gefunden. Sie würden wahrscheinlich wollen ebale zu setzen (Release) behobenen Version ohne Unterbrechung der Arbeit an neuen Funktionen, und ohne Versand Version aus der Entwicklung, die instabil sein könnte und mehrere andere Fehler enthalten. Auch würden Sie wollen, dass der Bugfix auch in der Version, an der Sie arbeiten, enthalten ist (wenn er nicht unabhängig behoben wurde).

  Hierfür würden Sie langlebige Zweige verwenden: Wartung Zweig, in dem Sie nur Fehlerbehebungen vornehmen würden, und Entwicklung Zweig (oder Kofferraum ), wo Sie neue Arbeiten durchführen, neue Funktionen einführen usw. Es kann mehrere Zweige mit unterschiedlicher Stabilität geben. Ein Git Projekt hat zum Beispiel vier solcher Zweige: "maint" für Fehlerbehebungen, "master" für Änderungen, die recht stabil sind, "next" für Entwicklungsarbeiten und "pu" oder "proposed updates"-Zweig. In anderen Arbeitsabläufen gibt es für jede Version einen eigenen Wartungszweig (Bugfix).

  Um Joel Spolsky zu zitieren: "Die Trennung von stabilem und Entwicklungscode ist genau das, was die Quellcodekontrolle ermöglichen soll.

• Thema (Funktion) Zweige . Wenn Sie parallel an mehreren Themen arbeiten wollen, bei denen jedes Feature mehrere Commits benötigt, um fertig zu werden, würden Sie wahrscheinlich jedes Feature (jedes Tipic) in einem separaten Zweig entwickeln wollen. Auf diese Weise könnten Sie von der Arbeit an einer Funktion zur Arbeit an einer anderen Funktion (zu einem anderen Thema) wechseln.

  Dieser Arbeitsablauf ist besonders wichtig, wenn Sie mit mehreren Entwicklern zusammenarbeiten (siehe unten).

Mehrere Entwickler

Eine der wichtigsten Eigenschaften eines Versionskontrollsystems ist, dass es Folgendes ermöglicht Zusammenarbeit zwischen verschiedenen Entwicklern, so dass mehrere Personen an demselben Projekt arbeiten können, ohne sich gegenseitig in die Quere zu kommen. Diese Funktion ist in anderen Antworten gut beschrieben, so dass ich nicht näher darauf eingehen werde.

Siehe auch " Verständnis der Versionskontrolle ", in Arbeit befindliches Werk von Eric S. Raymond (Autor von u.a. "The Catedral and the Bazaar" und "The Art of Unix Programming") zur Beschreibung verschiedener Methoden, die Versionskontrollsysteme für die Zusammenarbeit verwenden.

Answer 5

Git und Subversion (auch bekannt als svn) sind beides Systeme zur Versionskontrolle oder Revisionskontrolle. Sie helfen Ihnen bei der Verwaltung von Quellcode und zeichnen den Verlauf der Änderungen an jeder vom System verwalteten Datei auf. Der Wikipedia-Artikel metismo links könnte hilfreich sein.

github ist ein Dienst zum Hosten und Verwalten von Git-Repositories. Im Grunde stellt er das Repository online, um es mehreren Personen zu erleichtern, mit dem Repository zu interagieren.

Der Commit-Befehl speichert in der Regel einen Satz von Änderungen im Repository der Versionsverwaltung. Dadurch wird eine neue Revision im Repository erstellt.

Der Befehl push gilt nur für verteilte Versionskontrollsysteme wie git oder mercurial (auch bekannt als hg). Mit Push können Änderungen von einem Repository in ein anderes verschoben werden. Das Konzept verteilter Versionskontrollsysteme ist, dass jeder Benutzer sein eigenes Repository hat. Wenn ein Benutzer Änderungen vornimmt, verschiebt er sie in andere Repositories (vielleicht in ein zentrales Projekt-Repository oder als Patch für das Repository eines anderen Benutzers).

Das Ziel dieser Systeme ist es

• eine Geschichte des Entwicklungsprozesses speichern
• Verbesserung der Zusammenarbeit zwischen mehreren Entwicklern
• alte Versionen von Code wiederherstellen und korrigieren zu können
• Quellcodeänderungen mit bestimmten Funktionen oder Fehlern verknüpfen (siehe fogbugz und kiln)
• Varianten des Codes (Zweige) für Experimente oder parallele Entwicklung erstellen