Unterschied zwischen GIT und CVS

Question

Was ist der Unterschied zwischen GIT- und CVS -Versionskontrollsystemen?

Ich benutze seit über 10 Jahren glücklich CVS, und jetzt wurde mir gesagt, dass Git viel besser ist. Könnte jemand bitte erklären, was der Unterschied zwischen den beiden ist und warum einer besser ist als der andere?

Answer 1

Der Hauptunterschied besteht darin, dass CVS (wie bereits in anderen Antworten gesagt wurde) CVS (alt) zentralisiertes Versionskontrollsystem, während Git verteilt ist.

Aber selbst wenn Sie die Versionskontrolle für Einzelentwickler auf einer einzelnen Maschine (Einzelkonto) verwenden, gibt es einige Unterschiede zwischen GIT und CVS:

• Einrichten von Repository. Git speichert Repository in .git Verzeichnis im Top -Verzeichnis Ihres Projekts; CVS erfordern die Einrichtung von CVSroot, einem zentralen Ort zum Speichern von Versionen für verschiedene Projekte (Module). Die Folge dieses Designs für den Benutzer ist, dass das Importieren vorhandener Quellen in die Versionskontrolle so einfach ist wie "Git init && git add. && git Commit in Git, während es ist komplizierter In CVS.

• Atomare Operationen. Da CVS zu Beginn eine Reihe von Skripten rund um das RCS-Versionskontrollsystem pro Datei waren, sind Commits (und andere Operationen) in CVS nicht atomar. Wenn eine Operation im Repository in der Mitte unterbrochen wird, kann das Repository in einem inkonsistenten Zustand gelassen werden. In Git sind alle Operationen atomar: Entweder gelten sie als Ganzes oder sie scheitern ohne Änderungen.

• Änderungen. Änderungen in CVs sind pro Datei, während Änderungen (Commits) in Git immer auf das gesamte Projekt verweisen. Dies ist sehr wichtig Paradigmenverschiebung. Eine der Konsequenzen davon ist, dass es sehr einfach ist, Git zurückzukehren (eine Änderung zu erzeugen, die es rückgängig machen) oder rückgängig machen) oder rückgängig machen) oder rückgängig machen ganz Rückgeld; Eine andere Konsequenz ist, dass in CVS einfach zu teilweise zu untersuchen ist, während es derzeit so gut wie unmöglich in Git ist. Die Tatsache, dass Änderungen pro Datei sind, die zusammengefasst wurden, führte zu einer Erfindung des GNU-Changelog-Formats für Bekanntheitsnachrichten in Lebensläufen. GIT -Benutzer verwenden (und einige Git -Tools erwarten) eine andere Konvention, wobei eine einzelne Zeile (zusammenfassende Änderung) gefolgt von einer leeren Zeile, gefolgt von einer detaillierteren Beschreibung der Änderungen.

• Benennung von Revisionen / Versionsnummern. Es gibt ein weiteres Problem mit der Tatsache, dass in CVS Änderungen pro Dateien sind: Versionsnummern (wie Sie manchmal in sehen können Keyword -Erweiterung, siehe unten) wie 1.4 spiegelt die geänderte Datei wider. In Git hat jede Version eines Projekts als Ganzes (jedes Commit) ihren eindeutigen Namen von SHA-1 ID angegeben; Normalerweise reichen die ersten 7-8 Zeichen aus, um ein Commit zu identifizieren (Sie können nicht einfaches Nummerierungsschema für Versionen im verteilten Versionskontrollsystem verwenden-für das die zentrale Nummerierungsbehörde erforderlich ist). In CVS, um die Versionsnummer oder einen symbolischen Namen zu haben, der sich auf den Stand des Projekts als Ganzes bezieht, verwenden Sie Stichworte; Gleiches gilt für Git, wenn Sie den Namen wie 'v1.5.6-RC2' für eine Version eines Projekts verwenden möchten ... aber Tags in Git sind viel einfacher zu bedienen.

• Einfache Verzweigung. Zweige in Lebensläufen sind meiner Meinung nach zu kompliziert und schwer zu bewältigen. Sie müssen Filialen markieren, um einen Namen für einen ganzen Repository-Zweig zu haben (und selbst das kann in einigen Fällen aufgrund des Handlings pro Datei scheitern). Fügen Sie dazu hinzu, dass CVS nicht hat Verfolgung verschmelzen, Sie müssen sich also entweder daran erinnern oder manuell mit verschmolzenen und verzweigten Punkten markieren und manuell korrekte Informationen für "CVS -Update -j" zur Zusammenführung von Filialen liefern, und es sorgt dafür, dass Verzweigungen unnötig schwer zu bedienen sind. In Git ist das Erstellen und Zusammenführen von Zweigen sehr einfach; Git erinnert sich an alle erforderlichen Informationen an sich (daher ist das Verschmelzen einer Niederlassung so einfach wie "Git" Zweigname") ... es musste, weil verteilte Entwicklung natürlich zu mehreren Zweigen führt.

  Dies bedeutet, dass Sie verwenden können Themenzweige, IE entwickeln eine separate Funktion in mehreren Schritten in separaten Feature -Zweig.

• Verfolgung umbenennen (und kopieren). Die Umbenennungen der Datei werden in Lebensläufen nicht unterstützt, und die manuelle Umbenennung kann den Verlauf in zwei Jahren brechen oder zu einem ungültigen Verlauf führen, in dem Sie den Status eines Projekts vor dem Umbenennen nicht korrekt wiederherstellen können. Git verwendet die heuristische Umbenennungserkennung, basierend auf Ähnlichkeit von Inhalten und Dateinamen (diese Lösung funktioniert in der Praxis gut). Sie können auch das Erkennen des Kopierens von Dateien anfordern. Das bedeutet, dass:

  • Bei der Prüfung des festgelegten Commit erhalten Sie Informationen, dass eine Datei umbenannt wurde.
  • Das korrekte Zusammenführen berücksichtigt (z. B. wenn die Datei nur in einer Filiale umbenannt wurde)
  • "Git Schuld", das (bessere) Äquivalent von "CVS-kommentieren", einem Tool, um die Zeilenverlauf eines Dateiinhalts anzuzeigen

• Binärdateien. CVS hat nur sehr begrenzte Unterstützung für binäre Dateien (z. B. Bilder), bei der Benutzer Binärdateien beim Hinzufügen (oder später "CVS -Administrator" oder über Wrapper explizit markieren müssen, um dies automatisch auf der Basis von Dateinamen zu tun), um die Manging von zu vermeiden Binärdatei über die Konvertierung und Keyword-Erweiterung am Ende der Leitung. Git erkennt die Binärdatei automatisch basierend auf Inhalten auf die gleiche Weise, wie CNU Diff und andere Tools dies tun. Sie können diese Erkennung mit dem GitatTtributes -Mechanismus überschreiben. Darüber hinaus sind Binärdateien dank des Standards bei "SafeCRLF" (und der Tatsache, dass Sie je nach Verteilung standardmäßig standardmäßig aktiviert werden können) und (begrenzte) Schlüsselwort dank des Standards von "safeclf" (und der Tatsache, dass Sie standardmäßig standardmäßig aktiviert werden müssen) sicher sind (und die Tatsache, dass Sie die Konvertierung am Ende der Leitung beantragen müssen. Die Expansion ist ein strenger "Opt-In" in Git.

• Keyword -Erweiterung. Git bietet im Vergleich zu CVS (standardmäßig) sehr begrenzte Schlüsselwörter im Vergleich zu CVS. Dies liegt an zwei Fakten: Änderungen im Git sind pro Repository und nicht pro Datei, und Git vermeidet es, Dateien zu ändern, die sich beim Wechsel zu einer anderen Filiale nicht geändert haben oder sich auf einen anderen Punkt in der Geschichte zurückspulen. Wenn Sie die Revisionsnummer mit Git einbetten möchten, sollten Sie dies mit Ihrem Build-System tun, z. B. nach dem Beispiel eines Git-Version-Skripts in Linux-Kernelquellen und in Git-Quellen.

• Änderung von Commits. Weil in verteilten VCs wie Git Act of Veröffentlichung ist vom Erstellen eines Commits getrennt. Man kann unveröffentlichten Teil der Geschichte ändern (bearbeiten, neu schreiben), ohne andere Benutzer zu belasten. Insbesondere wenn Sie Tippfehler (oder andere Fehler) in der Commit -Nachricht oder einen Fehler in Commit bemerken, können Sie einfach "Git Commit -AMEND" verwenden. Dies ist in CVS nicht möglich (zumindest nicht ohne schwere Hackerie).

• Mehr Werkzeuge. Git bietet viel mehr Werkzeuge als Lebensläufe. Einer von wichtigeren ist "Git halb"Das kann verwendet werden, um ein Commit (Revision) zu finden, das einen Fehler eingeführt hat. Wenn Ihre Commits klein und in sich geschlossen sind, sollte es ziemlich einfach sein, dann zu entdecken, wo sich der Fehler befindet.

---

Wenn Sie mit mindestens einem anderen Entwickler zusammenarbeiten, finden Sie auch die folgenden Unterschiede zwischen Git und CVS:

• Vor dem Zusammenführen verpflichten Git verwendet Commit-vor-Merge eher als wie CVs, merge-vor-commit (oder UPDATE-Then-Commit). Wenn während Sie Dateien bearbeitet haben, sich auf die Erstellung neuer Commits (neue Revision) vorbereiten, hat jemand, der ein anderes Komit in derselben Filiale erstellt hat, und es jetzt im Repository ist, Sie zwingen Sie dazu, zuerst Ihr Arbeitsverzeichnis zu aktualisieren und Konflikte zu lösen, bevor Sie sich zum Verpfingen ermöglichen. Dies ist bei Git nicht der Fall. Sie verpflichten sich zuerst, retten Ihren Staat in der Versionskontrolle und fusionieren dann andere Entwickleränderungen. Sie können den anderen Entwickler auch bitten, die Zusammenführungen zu machen und Konflikte zu lösen.

  Wenn Sie es vorziehen, eine lineare Anamnese zu haben und Zusammenführungen zu vermeiden, können Sie jederzeit verwenden Commit-Merge-Recommit Workflow über "Git Rebase" (und "Git Pull -Rebase"), das dem Lebenslauf ähnlich ist, als Sie Ihre Änderungen auf dem aktualisierten Zustand wiederholen. Aber Sie verpflichten sich immer zuerst.

• Keine Notwendigkeit für zentrales Repository Bei Git besteht kein einzelner zentraler Ort, an dem Sie Ihre Änderungen begehen. Jeder Entwickler kann ein eigenes Repository haben (oder bessere Repositories: privates, in dem er/sie entwickelt wird, und öffentlich nackt, wo sie/er diesen Teil veröffentlichen, der bereit ist), und sie können sich gegenseitig von Repositories ziehen/holen Symmetrische Mode. Andererseits ist es üblich, dass ein größeres Projekt hat sozial Definiert/nominiertes zentrales Repository, aus dem alle ziehen (Änderungen abrufen).

---

Schließlich bietet Git viel mehr Möglichkeiten, wenn die Zusammenarbeit mit einer großen Anzahl von Entwicklern erforderlich ist. Unten gibt es Unterschiede zwischen CVs in Git für verschiedene Interessenstadien und Position in einem Projekt (unter Versionskontrolle unter Verwendung von CVS oder GIT):

• Lurker. Wenn Sie nur daran interessiert sind, die neuesten Änderungen aus einem Projekt zu erhalten ((Keine Verbreitung Ihrer Änderungen) oder tun Privatgelände Entwicklung (ohne dazu beitragen zu Originalprojekten); Oder Sie verwenden ausländische Projekte als Grundlage für Ihr eigenes Projekt (Änderungen sind lokal und sind nicht sinnvoll, sie zu veröffentlichen).

  Git unterstützt hier Anonymous nicht authentifiziert schreibgeschützter Zugriff über benutzerdefinierte effiziente git://Protokoll oder wenn Sie hinter der Blockierung der Firewall stehen DEFAULT_GIT_PORT (9418) Sie können einfach HTTP verwenden.

  Für Lebensläufe (wie ich es verstehe) für den schreibgeschützten Zugriff ist Gästekonto Für das 'PSERVER' -Protokoll auf CVS_AUTH_PORT (2401), normalerweise als "anonym" und mit leerem Passwort bezeichnet. Die Anmeldeinformationen werden standardmäßig in gespeichert $HOME/.cvspass Datei, also müssen Sie sie nur einmal bereitstellen. Trotzdem ist dies ein bisschen Barriere (Sie müssen den Namen des Gastkontos kennen oder auf CVS -Servermeldungen achten) und Ärger.

• Randentwickler (Leaf -Mitarbeiter). Eine Möglichkeit, Ihre Änderungen in OSS zu verbreiten, ist Patches per E -Mail senden. Dies ist die häufigste Lösung, wenn Sie (mehr oder weniger) versehentlicher Entwickler sind und einzelne Änderungen oder Einzelfehler senden. Übrigens. Das Senden von Patches kann nicht nur per E -Mail über das Überprüfungsausschuss (Patch Review System) oder ähnliche Mittel erfolgen.

  Git bietet hier Tools an, die sowohl für den Sender (Client) als auch für den Betreuer (Server) bei diesem Ausbreitungsmechanismus (Veröffentlichungsmechanismus) helfen. Für Personen, die ihre Änderungen per E -Mail senden möchten, gibt es "Git -Rebase"(oder" Git Pull -Rebase ") Tool, um Ihre eigenen Änderungen auf der aktuellen Upstream -Version wiederzugeben, sodass Ihre Änderungen auf der aktuellen Version (sind frisch) und" und "und frisch) und"GIT-Formatpatch"Um E -Mails mit Commit -Nachricht (und Urheberschaft) zu erstellen, ändern Sie sich in Form eines (erweiterten) einheitlichen Diff -Formats (plus Diffstat für eine leichtere Überprüfung). Der Betreuer kann diese E -Mail direkt in die Aufrechterhaltung aller Informationen (einschließlich der Commit -Nachricht) verwandeln."Git am".

  CVS bieten keine solchen Tools an: Sie können "CVS Diff" / "CVS RDIFF" verwenden, um Änderungen zu generieren und GNU -Patch zu verwenden, um Änderungen anzuwenden. Soweit ich weiß, gibt es keine Möglichkeit, die Anwendung von Commit -Nachricht zu automatisieren. CVS sollte in Client <--> Server-Mode verwendet werden ...

• Leutnant. Wenn Sie einen getrennten Teil eines Projekts (Subsystem) sind oder wenn die Entwicklung Ihres Projekts "Netzwerk des Vertrauens" folgt, die bei der Entwicklung von Linux -Kernel verwendet werden ... oder nur, wenn Sie Ihr eigenes öffentliches Repository haben, und die Änderungen Sie Ich möchte veröffentlichen, dass sie zu groß sind, um per E -Mail zu senden als Patch -Serie, Du kannst senden Anfrage ziehen an (Haupt-) Projektbetreuer.

  Dies ist Lösung spezifisch für verteilt Versionskontrollsysteme, sodass CVS natürlich keine solche Art der Zusammenarbeit unterstützt. Es gibt sogar ein Tool namens "Git Request-Pull", das dazu beiträgt, E-Mails zum Senden an die Wartung mit der Anfrage zum Abziehen Ihres Repositorys vorzubereiten. Dank "Git Bundle" können Sie diesen Mechanismus auch ohne öffentliches Repository verwenden, indem Sie Bündel von Änderungen per E -Mail oder Sneakernet senden. Einige von Git -Hosting -Websites mögen Github Halten Sie Unterstützung dafür, dass jemand an Ihrem Projekt arbeitet (vorausgesetzt, er/sie verwendet dieselbe Git-Hosting-Site) und für eine Art Pull-Anfrage.

• Hauptentwickler, dh jemand, der direkt veröffentlichen seine/ihre Änderungen (zum Haupt-/Kanonischen Repository). Diese Kategorie ist für verteilte Versionskontrollsysteme breiter, da mehrere Entwickler mit Schreibzugriff auf zentrales Repository nicht nur möglich sind (Sie können einen einzelnen Betreuer haben, der wer drückt Änderungen des kanonischen Repositorys, einer Reihe von Leutnants/Subsystem -Betreuern, aus denen er/sie zieht, und eine breite Palette von Blattentwicklern, die Patches per E -Mail an die Liste der Betreuer-/Projekt -Mailing -Liste oder an einen von Leutnants/Untermainern senden).

  Mit Git haben Sie die Wahl SSH -Protokoll (GIT -Protokoll, eingewickelt in SSH), um Änderungen mit Tools wie "Git Shell" zu veröffentlichen (um die Sicherheit zu unterstützen, den Zugriff von Shell -Konten zu begrenzen) oder) oder Gitose (Um Zugriff zu verwalten, ohne separate Shell -Konten zu erfordern) und Https mit WebDAV, mit gewöhnlicher HTTP -Authentifizierung.

  Mit CVS gibt es eine Wahl zwischen den benutzerdefinierten unverschlüsselter (einfacher Text) PERVER Protokoll oder Verwendung Fernschale (wo Sie wirklich verwenden sollten Ssh) um Ihre Änderungen zu veröffentlichen, welche für zentralisiert Das Versionskontrollsystem bedeutet, Ihre Änderungen zu verpflichten (Schaffung von Commits). Nun, Sie können auch das 'PSERVER' -Protokoll mit SSH abtunnieren, und es gibt drei Party -Tools, die dies automatisieren ... aber ich denke nicht, dass dies so einfach ist wie z. B. Gitose.

Im Allgemeinen bieten verteilte Versionskontrollsysteme wie Git eine viel größere Auswahl möglicher Workflows. Mit zentralisierten Versionskontrollsystemen wie CVS müssen Sie zwangsläufig zwischen Menschen mit dem Bekenntniszugang zu Repository und denjenigen ohne ... und CVS unterscheiden Zugang begehen.

Karl Fogel in Open -Source -Software produzieren In Abschnitt über die Versionskontrolle besagt, dass es besser ist, nicht zu strenge, strenge und strenge Steuerelemente für Bereiche zu liefern, in denen man Änderungen am öffentlichen Repository vornehmen darf. Es ist viel besser, sich auf soziale Beschränkungen (wie die Codeüberprüfung) (z. B. Code -Überprüfung) zu verlassen, als auf technische Einschränkungen. Verteilte Versionskontrollsysteme reduzieren diese IMHO noch weiter ...

HTH (Ich hoffe, das hilft)

Answer 2

Git ist a DVCs, im Gegensatz zu CVs als zentraler. Eine simple Beschreibung ist: Sie erhalten alle Vorteile der Versionskontrolle, wenn Sie nicht miteinander verbunden sind irgendein von mehreren möglichen Repositorys sowie den Betrieb sind schneller.

Answer 3

Die Git -Website erklärt das wahrscheinlich am besten.

Meine Haustierfunktion ist es, sich bei offline zu verpflichten. Und die Geschwindigkeit, die schiere lodernde Geschwindigkeit, mit der alles außer Druck und Ziehen passiert. (Und diese Operationen sind entworfen, sodass Sie beim Kaffee einen Kaffee schnappen/ziehen können, wenn Ihr zentrales Repo zurückbleibt.) Eine weitere schöne Sache ist, dass es inklusive Batterien kommt: The Buildin gitk ist ein gut genug Geschichtszuschauer; git gui ist ein gut genug Commit -Tool; mit Ausgangskolorisierung, git add -i, git add -p, git rebase -i sind gut genug interaktive Schnittstellen; git daemon und git instaweb sind gut genug für die Ad-hoc-Zusammenarbeit, wenn Sie nicht mit Ihrem zentralen Repo fassen möchten / können.

Answer 4

Ich bin auch ein über 10 Jahre hauptsächlich glücklicher Benutzer von Lebensläufen, obwohl ich auch Git mag und mit der Zeit es bevorzugen, obwohl die meisten Projekte, an denen ich gerade arbeite, CVS oder SVN, und wir können nicht scheinen Um die Büro zu bekommen, in der ich überzeugt bin, uns über die Firewall zu überzeugen.

Ein paar Dinge, die Lebensläufe schöner machen als sonst, sind CVSPs, und ein anderer sind entweder Andrew Mortons Patch -Skripte oder Quilt. Mit CVSPs können Sie die Mehrfachdateien eines Commits in einem einzelnen Patch (und so "Änderungen" aus CVS extrahieren), während Quilt oder Andrew Mortons Patch -Skripte es ermöglichen, vernünftige "Änderungen" ziemlich einfach und bequem in CVS zu begehen, um Ihnen zu ermöglichen, um Ihnen zu CVS zu begehen, um Ihnen zu ermöglichen, und Sie dazu ermöglichen Arbeiten Sie gleichzeitig an Mutliple -Dingen, während Sie sie vor dem Vergehen weiter getrennt halten. CVS hat seine Macken, aber ich bin an die meisten von ihnen gewöhnt.

Answer 5

"Ich benutze CVS über x Jahre glücklich", ist eine interessante Idee :-) Es ist ein großer Schritt, viele Kopien zu behalten, aber ...

Ich vermute, Sie haben sich an alles gewöhnt, dass es sich um Macken handelt oder nicht viel Verzweigungen und Verschmelzung. Es gibt eine schlechtere Möglichkeit;

Die Menschen in Ihrer Organisation haben sich an Lebensläufe gewöhnt, und Ihre Arbeitspraktiken haben sich entsprechend angepasst.

Zum Beispiel wird nie mehr als ein Entwickler gleichzeitig an einem Paket arbeiten, nur mit Verzweigungen in Notfällen usw.

Das Grundprinzip ist, je schwieriger etwas ist, desto weniger Menschen tun es.