Git ist ein verteiltes Versionskontrollsystem. Git ist eine von Linus Torvalds entwickelte Open-Source-Software zur verteilten Versionskontrolle zur Verwaltung der Linux-Kernel-Entwicklung. Sie wird für die effektive und schnelle Versionsverwaltung von Projekten von kleinen bis hin zu sehr großen Projekten verwendet.
Die Betriebsumgebung dieses Tutorials: Windows7-System, MySQL8.0.22-Version, Dell G3-Computer.
Zu welchem Versionskontrollsystem gehört Git?
Git ist ein verteiltes Versionskontrollsystem.
Git hat die folgenden Eigenschaften:
Das Repository jedes Klons in Git ist gleich. Sie können Ihr eigenes Repository aus einem Klon eines beliebigen Repositorys erstellen und Ihr Repository kann bei Bedarf auch als Quelle für andere verwendet werden.
Jeder Extraktionsvorgang von Git ist eigentlich eine vollständige Sicherung des Code-Repositorys.
Die Übermittlung erfolgt vollständig lokal, niemand sonst muss Ihnen die Genehmigung erteilen, Sie sind der Herr Ihres Repositorys und die Übermittlung wird immer erfolgreich sein.
Sogar Änderungen, die auf der alten Version basieren, können erfolgreich übermittelt werden, und durch die Übermittlung wird ein neuer Zweig basierend auf der alten Version erstellt.
Git-Übermittlungen werden nicht unterbrochen, bis Sie mit Ihrer Arbeit vollständig zufrieden sind oder andere zum PULL-Vorgang in Ihr Repository gelangen. Konflikte, die nicht automatisch gelöst werden können, werden angezeigt von Hand.
Konfliktlösung ist nicht mehr wie ein Einreichungswettbewerb wie SVN, sondern Zusammenführung und Konfliktlösung nur bei Bedarf.
Git kann auch einen zentralisierten Arbeitsmodus simulieren.
Das Git-Repository wird auf dem Server platziert.
Sie können das Git-Repository autorisieren: Wer kann das Repository erstellen, wer kann es in das Repository pushen, wer kann lesen (klonen) Sie das Repository?
Teammitglieder klonen zunächst das Repository des Servers und ziehen (PULL) häufig die neuesten Updates aus dem Repository des Servers.
Teammitglieder übertragen (PUSH) Ihre eigenen Änderungen Repository, und wenn andere mit dem Repository synchronisieren (PULL), erhalten sie automatisch die Änderungen. Der zentralisierte Arbeitsmodus von Git ist sehr flexibel B. bei der Arbeit unterwegs/auf einer Geschäftsreise, können Sie die Codebibliothek weiterhin wie gewohnt nutzen
Sie müssen nur PULL und PUSH verwenden, um die Synchronisierung mit dem Server abzuschließen und zu übermitteln, wann Sie auf das Netzwerk zugreifen können Der Git-Server befindet sich
Git stellt den Rebase-Befehl bereit, mit dem Ihre Änderungen so aussehen können, als ob sie auf den neuesten Codeänderungen basieren
Git bietet mehr Arbeitsmodi zur Auswahl, weit mehr, als Subversion mithalten kann
-
Was ist „Versionskontrolle“?
Versionskontrolle ist ein System, das Änderungen im Inhalt einer oder mehrerer Dateien aufzeichnet, sodass Sie den Revisionsstatus einer bestimmten Version überprüfen und in Zukunft zurückverfolgen können. Jeder Dateityp kann einer Versionskontrolle unterliegen.
Damit können Sie eine Datei auf den vorherigen Zustand zurücksetzen oder sogar das gesamte Projekt auf den Zustand zu einem bestimmten Zeitpunkt in der Vergangenheit zurücksetzen. Sie können die Änderungsdetails der Dateien vergleichen und herausfinden, wer welche Änderungen vorgenommen hat Am Ende erfahren Sie, was seltsame Probleme verursacht hat, wer wann einen Funktionsfehler gemeldet hat und vieles mehr. Die Verwendung eines Versionskontrollsystems bedeutet in der Regel auch, dass Sie selbst dann, wenn Sie Dateien im gesamten Projekt durcheinander bringen und löschen, sie problemlos in ihrem ursprünglichen Aussehen wiederherstellen können. Der zusätzliche Arbeitsaufwand ist jedoch minimal.
Lokales Versionskontrollsystem
Viele Leute sind es gewohnt, das gesamte Projektverzeichnis zu kopieren, um verschiedene Versionen zu speichern, und ändern möglicherweise auch den Namen und fügen die Sicherungszeit hinzu, um den Unterschied anzuzeigen. Der einzige Vorteil dabei ist, dass es einfach ist, aber es ist auch sehr leicht, Fehler zu machen. Manchmal ist das Arbeitsverzeichnis verwirrt und versehentlich wird die falsche Datei geschrieben oder eine unerwartete Datei wird überschrieben.
Um dieses Problem zu lösen, wurden vor langer Zeit viele lokale Versionskontrollsysteme entwickelt, von denen die meisten eine Art einfache Datenbank verwenden, um die Unterschiede in früheren Dateiaktualisierungen aufzuzeichnen.
Abbildung 1. Lokale Versionskontrolle.
Das beliebteste heißt RCS und ist auch heute noch auf vielen Computersystemen zu sehen. Der Befehl rcs kann auch nach der Installation des Developer Toolkits auf gängigen Mac OS X-Systemen verwendet werden. Es funktioniert durch das Speichern einer Reihe von Patches (ein Patch ist eine Änderung vor und nach der Überarbeitung einer Datei) auf der Festplatte. Durch Anwenden aller Patches kann der Inhalt jeder Version der Datei neu berechnet werden.
Zentralisiertes Versionskontrollsystem
Als nächstes stoßen die Leute auf ein weiteres Problem: Wie können Entwickler auf verschiedenen Systemen zusammenarbeiten?
Daher entstanden zentralisierte Versionskontrollsysteme (Centralized Version Control Systems, kurz CVCS). Solche Systeme wie CVS, Subversion und Perforce verfügen über einen einzigen zentral verwalteten Server, der Revisionen aller Dateien speichert, und zusammenarbeitende Personen stellen über Clients eine Verbindung zu diesem Server her, um die neuesten Dateien abzurufen oder Erneuerungen vorzunehmen. Dies ist im Laufe der Jahre zur Standardpraxis für Versionskontrollsysteme geworden.
Abbildung 2. Zentralisierte Versionskontrolle.
Dieser Ansatz bringt viele Vorteile mit sich, insbesondere im Vergleich zum altmodischen lokalen VCS. Jetzt kann jeder einigermaßen sehen, woran andere im Projekt arbeiten. Administratoren können außerdem problemlos die Berechtigungen jedes Entwicklers steuern, und die Verwaltung eines CVCS ist weitaus einfacher als die Verwaltung lokaler Datenbanken auf jedem Client.
Es gibt zwei Seiten der Dinge, gute und schlechte. Der offensichtlichste Nachteil dieser Vorgehensweise besteht darin, dass der zentrale Server ein Single Point of Failure ist. Wenn es eine Stunde lang nicht verfügbar ist, kann in dieser Stunde niemand Updates einreichen und niemand kann zusammenarbeiten. Wenn die Festplatte, auf der sich die zentrale Datenbank befindet, beschädigt wird und Sie sie nicht ordnungsgemäß sichern, verlieren Sie zweifellos alle Daten – einschließlich des gesamten Änderungsverlaufs des Projekts, sodass nur die einzelnen Snapshots übrig bleiben, die die Benutzer auf ihren jeweiligen Computern aufbewahren. Ein ähnliches Problem besteht bei lokalen Versionskontrollsystemen. Solange der gesamte Projektverlauf an einem einzigen Ort gespeichert wird, besteht die Gefahr, dass alle historischen Aktualisierungsdatensätze verloren gehen.
Distributed Version Control System
So wurde das Distributed Version Control System (DVCS) geboren. In solchen Systemen wie Git, Mercurial, Bazaar und Darcs extrahiert der Client nicht nur die neueste Version des Datei-Snapshots, sondern spiegelt das Code-Repository vollständig wider. Auf diese Weise kann bei einem Ausfall eines für die Zusammenarbeit genutzten Servers anschließend jedes gespiegelte lokale Warehouse zur Wiederherstellung genutzt werden. Denn jeder Klonvorgang ist eigentlich eine vollständige Sicherung des Code-Repositorys.
Abbildung 3. Verteilte Versionskontrolle
Darüber hinaus können viele dieser Systeme für die Interaktion mit mehreren verschiedenen Remote-Code-Repositorys spezifiziert werden. Auf diese Weise können Sie mit Personen aus verschiedenen Arbeitsgruppen am selben Projekt zusammenarbeiten. Sie können je nach Bedarf unterschiedliche Kollaborationsprozesse einrichten, beispielsweise hierarchische, modellbasierte Arbeitsabläufe, was in früheren zentralisierten Systemen nicht möglich war.
Das obige ist der detaillierte Inhalt vonZu welchem Versionskontrollsystem gehört Git?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!
