Der Hauptunterschied besteht darin, dass CVS (wie bereits in anderen Antworten erwähnt) ein (altes) zentrales Versionskontrollsystem ist, während Git verteilt wird.
Aber selbst wenn Sie die Versionskontrolle für einzelne Entwickler auf einem einzelnen Computer (einzelnes Konto) verwenden, gibt es einige Unterschiede zwischen Git und CVS:
Repository einrichten . Git speichert das Repository im .gitVerzeichnis im obersten Verzeichnis Ihres Projekts. Für CVS muss CVSROOT eingerichtet werden, ein zentraler Ort zum Speichern von Versionskontrollinformationen für verschiedene Projekte (Module). Die Konsequenz dieses Entwurfs für den Benutzer ist, dass das Importieren vorhandener Quellen in die Versionskontrolle so einfach wie "git init && git add. && git commit" in Git ist, während es in CVS komplizierter ist .
Atomoperationen . Da CVS zu Beginn eine Reihe von Skripten für das RCS-Versionskontrollsystem pro Datei war, sind Commits (und andere Vorgänge) in CVS nicht atomar. Wenn eine Operation im Repository in der Mitte unterbrochen wird, kann das Repository in einem inkonsistenten Zustand belassen werden. In Git sind alle Operationen atomar: Entweder sind sie als Ganzes erfolgreich oder sie schlagen ohne Änderungen fehl.
Änderungssätze . Änderungen in CVS erfolgen pro Datei, während sich Änderungen (Commits) in Git immer auf das gesamte Projekt beziehen. Dies ist ein sehr wichtiger Paradigmenwechsel . Eine der Konsequenzen davon ist, dass es in Git sehr einfach ist, die gesamte Änderung rückgängig zu machen (eine Änderung zu erstellen, die rückgängig macht) oder rückgängig zu machen . Eine andere Konsequenz ist, dass es in CVS einfach ist, teilweise auszuchecken, während es in Git derzeit so gut wie unmöglich ist. Die Tatsache, dass die Änderungen pro Datei zusammengefasst sind, führte zur Erfindung des GNU-Changelog-Formats für Commit-Nachrichten in CVS. Git-Benutzer verwenden (und einige Git-Tools erwarten dies) unterschiedliche Konventionen, wobei eine einzelne Zeile die Änderung beschreibt (zusammenfasst), gefolgt von einer leeren Zeile, gefolgt von einer detaillierteren Beschreibung der Änderungen.
Namensrevisionen / Versionsnummern . Es gibt ein weiteres Problem im Zusammenhang mit der Tatsache, dass Änderungen in CVS pro Datei vorgenommen werden: Versionsnummern (wie Sie manchmal in der Keyword-Erweiterung sehen können , siehe unten) wie 1.4 geben an, wie oft eine bestimmte Datei geändert wurde. In Git hat jede Version eines Projekts als Ganzes (jedes Commit) einen eindeutigen Namen, der durch die SHA-1-ID angegeben wird. Normalerweise reichen die ersten 7 bis 8 Zeichen aus, um ein Commit zu identifizieren (Sie können kein einfaches Nummerierungsschema für Versionen im verteilten Versionskontrollsystem verwenden - dies erfordert eine zentrale Nummerierungsautorität). In CVS verwenden Sie Tags, um eine Versionsnummer oder einen symbolischen Namen zu erhalten, die sich auf den Gesamtstatus des Projekts beziehen;; Das gleiche gilt für Git, wenn Sie für eine Version eines Projekts einen Namen wie 'v1.5.6-rc2' verwenden möchten ... Tags in Git sind jedoch viel einfacher zu verwenden.
Einfache Verzweigung . Branchen in CVS sind meiner Meinung nach zu kompliziert und schwer zu behandeln. Sie müssen Zweige markieren, um einen Namen für einen gesamten Repository-Zweig zu erhalten (und selbst das kann in einigen Fällen fehlschlagen, wenn ich mich richtig erinnere, aufgrund der Behandlung pro Datei). Hinzu kommt, dass CVS keine Zusammenführungsverfolgung hat. Sie müssen sich also entweder merken oder Zusammenführungen und Verzweigungspunkte manuell markieren und manuell die richtigen Informationen für "cvs update -j" angeben, um Verzweigungen zusammenzuführen, und dies führt zur Verzweigung unnötig schwer zu bedienen sein. In Git ist das Erstellen und Zusammenführen von Zweigen sehr einfach. Git merkt sich alle erforderlichen Informationen selbst (das Zusammenführen eines Zweigs ist also so einfach wie "git merge branchname ") ... das musste es, da verteilte Entwicklung natürlich zu mehreren Zweigen führt.
Dies bedeutet , dass Sie in der Lage zu verwenden Thema Zweige , dh ein separates Merkmal in mehreren Schritten in getrennten Funktionszweig entwickeln.
Tracking umbenennen (und kopieren) . Das Umbenennen von Dateien wird in CVS nicht unterstützt, und das manuelle Umbenennen kann den Verlauf in zwei Teile teilen oder zu einem ungültigen Verlauf führen, bei dem Sie den Status eines Projekts vor dem Umbenennen nicht korrekt wiederherstellen können. Git verwendet die heuristische Umbenennungserkennung, basierend auf der Ähnlichkeit von Inhalt und Dateiname (diese Lösung funktioniert in der Praxis gut). Sie können auch die Erkennung des Kopierens von Dateien anfordern. Dies bedeutet, dass:
- Wenn Sie das angegebene Commit untersuchen, erhalten Sie Informationen darüber, dass eine Datei umbenannt wurde.
- Beim korrekten Zusammenführen werden Umbenennungen berücksichtigt (z. B. wenn die Datei nur in einem Zweig umbenannt wurde).
- "git tad", das (bessere) Äquivalent von "cvs annotate", einem Tool zum Anzeigen des zeilenweisen Verlaufs eines Dateiinhalts, kann die Codebewegung auch über Umbenennungen hinweg verfolgen
Binärdateien . CVS bietet nur eine sehr eingeschränkte Unterstützung für Binärdateien (z. B. Bilder). Benutzer müssen Binärdateien beim Hinzufügen explizit markieren (oder später mithilfe von "cvs admin" oder über Wrapper, um dies automatisch basierend auf dem Dateinamen zu tun), um ein Verfälschen von zu vermeiden Binärdatei über End-of-Line-Konvertierung und Keyword-Erweiterung. Git erkennt Binärdateien basierend auf Inhalten automatisch auf dieselbe Weise wie CNU Diff und andere Tools. Sie können diese Erkennung mithilfe des Gitattributes-Mechanismus überschreiben. Darüber hinaus sind Binärdateien dank der Standardeinstellung 'safecrlf' (und der Tatsache, dass Sie die Konvertierung am Zeilenende anfordern müssen, obwohl dies je nach Verteilung standardmäßig aktiviert sein kann) und dieses (eingeschränkten) Schlüsselworts vor nicht behebbarem Mangeln geschützt Erweiterung ist ein striktes "Opt-In" in Git.
Keyword-Erweiterung . Git bietet im Vergleich zu CVS (standardmäßig) eine sehr, sehr begrenzte Anzahl von Schlüsselwörtern. Dies liegt an zwei Tatsachen: Änderungen in Git erfolgen pro Repository und nicht pro Datei, und Git vermeidet das Ändern von Dateien, die sich beim Wechsel zu einem anderen Zweig oder beim Zurückspulen zu einem anderen Punkt im Verlauf nicht geändert haben. Wenn Sie die Revisionsnummer mit Git einbetten möchten, sollten Sie dies mit Ihrem Build-System tun, z. B. anhand des Beispiels eines GIT-VERSION-GEN-Skripts in Linux-Kernelquellen und in Git-Quellen.
Commits ändern . Da in verteilten VCS wie Git das Veröffentlichen von einem Commit getrennt ist, kann ein unveröffentlichter Teil des Verlaufs geändert (bearbeitet, neu geschrieben) werden, ohne andere Benutzer zu belästigen. Insbesondere wenn Sie Tippfehler (oder andere Fehler) in der Festschreibungsnachricht oder einen Fehler beim Festschreiben bemerken, können Sie einfach "git commit --amend" verwenden. Dies ist in CVS nicht möglich (zumindest nicht ohne große Hackerangriffe).
Weitere Tools . Git bietet viel mehr Tools als CVS. Eines der wichtigsten ist " git bisect ", mit dem ein Commit (eine Revision) gefunden werden kann, das einen Fehler verursacht hat. Wenn Ihre Commits klein und in sich geschlossen sind, sollte es ziemlich einfach sein, herauszufinden, wo der Fehler liegt.
Wenn Sie mit mindestens einem anderen Entwickler zusammenarbeiten, werden Sie auch die folgenden Unterschiede zwischen Git und CVS feststellen:
Vor dem Zusammenführen festschreiben Git verwendet Commit-before-Merge und nicht wie CVS Merge-before-Commit (oder Update-then-Commit ). Wenn Sie während der Bearbeitung von Dateien, der Vorbereitung auf das Erstellen eines neuen Commits (neue Revision) von einem anderen Benutzer ein neues Commit für denselben Zweig erstellt haben und sich jetzt im Repository befinden, werden Sie von CVS gezwungen, zuerst Ihr Arbeitsverzeichnis zu aktualisieren und Konflikte zu lösen, bevor Sie das Commit zulassen. Dies ist bei Git nicht der Fall. Sie schreiben zuerst fest, speichern Ihren Status in der Versionskontrolle und führen dann andere Entwickleränderungen zusammen. Sie können auch den anderen Entwickler bitten, die Zusammenführung durchzuführen und Konflikte zu lösen.
Wenn Sie einen linearen Verlauf bevorzugen und Zusammenführungen vermeiden möchten, können Sie den Commit-Merge-Commit- Workflow jederzeit über "git rebase" (und "git pull --rebase") verwenden. Dies ähnelt CVS, da Sie Ihre Änderungen oben wiedergeben des aktualisierten Zustands. Aber Sie verpflichten sich immer zuerst.
Keine Notwendigkeit für ein zentrales Repository Mit Git ist es nicht erforderlich, einen einzigen zentralen Ort zu haben, an dem Sie Ihre Änderungen festschreiben. Jeder Entwickler kann über ein eigenes Repository verfügen (oder über bessere Repositorys: ein privates Repository, in dem er / sie die Entwicklung durchführt, und ein öffentliches Repository, in dem er / sie den Teil veröffentlicht, der bereit ist), und sie können voneinander Repositorys abrufen / abrufen symmetrische Mode. Auf der anderen Seite ist es üblich, dass größere Projekte ein sozial definiertes / nominiertes zentrales Repository haben, aus dem jeder zieht (Änderungen von).
Schließlich bietet Git viel mehr Möglichkeiten, wenn die Zusammenarbeit mit einer großen Anzahl von Entwicklern erforderlich ist. Nachfolgend gibt es Unterschiede zwischen CVS in Git für verschiedene Phasen von Interesse und Position in einem Projekt (unter Versionskontrolle mit CVS oder Git):
Lurker . Wenn Sie nur daran interessiert sind, die neuesten Änderungen aus einem Projekt zu erhalten ( keine Weitergabe Ihrer Änderungen ) oder eine private Entwicklung durchzuführen (ohne einen Beitrag zu den ursprünglichen Projekten zu leisten); oder Sie verwenden ausländische Projekte als Grundlage für Ihr eigenes Projekt (Änderungen sind lokal und es ist nicht sinnvoll, sie zu veröffentlichen).
Git unterstützt hier anonymen nicht authentifizierten schreibgeschützten Zugriff über ein benutzerdefiniertes effizientes git://Protokoll. Wenn Sie sich hinter einer Firewall-Blockierung DEFAULT_GIT_PORT(9418) befinden, können Sie einfaches HTTP verwenden.
Für CVS gängigste Lösung (wie ich es verstehe) für Nur - Lese-Zugriff ist Gastkonto für ‚pserver‘ Protokoll auf CVS_AUTH_PORT(2401), in der Regel „anonymous“ genannt und mit leerem Passwort. Anmeldeinformationen werden standardmäßig in einer $HOME/.cvspassDatei gespeichert, sodass Sie sie nur einmal angeben müssen. Dies ist jedoch ein kleines Hindernis (Sie müssen den Namen des Gastkontos kennen oder auf CVS-Servernachrichten achten) und Ärger.
Randentwickler (Blattbeitrag) . Eine Möglichkeit, Ihre Änderungen in OSS weiterzugeben, besteht darin , Patches per E-Mail zu senden . Dies ist die häufigste Lösung, wenn Sie (mehr oder weniger) versehentlich Entwickler sind und eine einzelne Änderung oder einen einzelnen Bugfix senden. Übrigens. Das Senden von Patches kann über das Review Board (Patch Review System) oder auf ähnliche Weise erfolgen, nicht nur per E-Mail.
Git bietet hier Tools an, die bei diesem Weitergabemechanismus sowohl für Absender (Client) als auch für Betreuer (Server) helfen. Für Personen, die ihre Änderungen per E-Mail senden möchten, gibt es das Tool " git rebase " (oder "git pull --rebase"), mit dem Sie Ihre eigenen Änderungen über der aktuellen Upstream-Version wiedergeben können, sodass Ihre Änderungen über der aktuellen Version liegen (frisch sind) ) und " Git-Format-Patch " zum Erstellen von E-Mails mit Commit-Nachricht (und Autorschaft) ändern sich in Form des (erweiterten) einheitlichen Diff-Formats (plus Diffstat zur einfacheren Überprüfung). Der Maintainer kann solche E-Mails mit " git am " direkt in ein Commit umwandeln und alle Informationen (einschließlich der Commit-Nachricht) beibehalten .
CVS bietet keine solchen Tools: Sie können "cvs diff" / "cvs rdiff" verwenden, um Änderungen zu generieren, und den GNU-Patch verwenden, um Änderungen zu übernehmen. Soweit ich weiß, gibt es jedoch keine Möglichkeit, das Anwenden von Commit-Nachrichten zu automatisieren. CVS sollte auf Client- <-> Server-Art verwendet werden ...
Leutnant . Wenn Sie einen separaten Teil eines Projekts (Subsystems) verwalten oder wenn die Entwicklung Ihres Projekts dem Workflow "Netzwerk des Vertrauens" folgt, der bei der Entwicklung des Linux-Kernels verwendet wird ... oder wenn Sie nur über ein eigenes öffentliches Repository verfügen und die Änderungen, die Sie vornehmen Wenn Sie veröffentlichen möchten, die zu groß sind, um sie als Patch-Serie per E-Mail zu senden , können Sie eine Pull-Anfrage an den (Haupt-) Betreuer des Projekts senden .
Dies ist eine Lösung, die für verteilte Versionskontrollsysteme spezifisch ist. Daher unterstützt CVS diese Art der Zusammenarbeit natürlich nicht. Es gibt sogar ein Tool namens "git request-pull", mit dem Sie E-Mails vorbereiten können, die an den Betreuer gesendet werden sollen, wenn Sie aufgefordert werden, sie aus Ihrem Repository abzurufen. Dank "git bundle" können Sie diesen Mechanismus auch ohne öffentliches Repository verwenden, indem Sie ein Bündel von Änderungen per E-Mail oder Sneakernet senden. Einige Git-Hosting-Sites wie GitHub unterstützen die Benachrichtigung, dass jemand an Ihrem Projekt arbeitet (einige Arbeiten veröffentlicht hat) (vorausgesetzt, er / sie verwendet dieselbe Git-Hosting-Site), und das PM-Senden einer Art Pull-Anfrage.
Hauptentwickler , dh jemand, der seine Änderungen direkt veröffentlicht (im Haupt- / kanonischen Repository). Diese Kategorie ist weiter für die verteilte Versionskontrollsysteme, wie mit Schreibzugriff auf zentrale Repository mehrere Entwickler, die nicht nur möglich , Workflow (Sie einzelne Maintainer, haben drückt Änderungen kanonische Repository, eine Reihe von Leutnants / Subsystem - Maintainer , aus dem er / sie Pulls und eine breite Palette von Blattentwicklern, die Patches per E-Mail entweder an die Betreuer- / Projekt-Mailingliste oder an einen der Leutnants / Sub-Betreuer senden.
Mit Git haben Sie die Wahl, das SSH-Protokoll (in SSH eingeschlossenes Git-Protokoll) zum Veröffentlichen von Änderungen zu verwenden, mit Tools wie "Git-Shell" (um die Sicherheit zu verbessern , den Zugriff auf Shell-Konten zu beschränken) oder Gitosis (um den Zugriff zu verwalten, ohne separate Shell-Konten zu benötigen) ) und HTTPS mit WebDAV mit normaler HTTP-Authentifizierung.
Bei CVS haben Sie die Wahl zwischen einem benutzerdefinierten unverschlüsselten ( Nur- Text-) Pserver- Protokoll oder der Verwendung einer Remote-Shell (wo Sie wirklich SSH verwenden sollten ), um Ihre Änderungen zu veröffentlichen. Für ein zentrales Versionskontrollsystem bedeutet dies, dass Sie Ihre Änderungen festschreiben (Commits erstellen). Nun, Sie können das 'pserver'-Protokoll auch mit SSH tunneln, und es gibt drei Party-Tools, die dies automatisieren ... aber ich denke nicht, dass dies so einfach ist wie z. B. Gitosis.
Im Allgemeinen bieten verteilte Versionskontrollsysteme wie Git eine viel größere Auswahl möglicher Workflows. Bei zentralisierten Versionskontrollsystemen wie CVS müssen Sie zwangsläufig zwischen Personen mit festgeschriebenem Zugriff auf das Repository und Personen ohne ... unterscheiden. CVS bietet keine Tools, mit denen Beiträge (über Patches) von Personen ohne akzeptiert werden können Zugriff festschreiben.