Share
Einfach gesagt, ein Remote-Repository gehört nicht Ihnen. Es kann sich dabei um einen zentralen Server, einen Personal Computer eines anderen Entwicklers oder sogar um Ihr Dateisystem handeln. Solange Sie über ein Netzwerkprotokoll darauf zugreifen können, ist es für Git unglaublich einfach, Beiträge mit anderen Repositorys zu teilen.
Die Hauptaufgabe von Remote-Repositorys besteht darin, andere Entwickler in Ihrem eigenen Repository zu vertreten. Niederlassungen hingegen sollten sich nur mit der Projektentwicklung befassen. Versuchen Sie also nicht, jedem Entwickler seine eigene Niederlassung zu geben, damit jeder daran arbeiten kann. Geben Sie jedem ein komplettes Repository und reservieren Sie Niederlassungen für die Entwicklung von Features.
In diesem Kapitel werden zunächst die Mechanismen von Remotes erläutert. Anschließend werden die beiden am häufigsten verwendeten Workflows der Git-basierten Zusammenarbeit vorgestellt: der zentralisierte Workflow und der Integrator-Workflow.
Ähnlich zu Git-Zweig, das git remote Der Befehl dient zum Verwalten von Verbindungen zu anderen Repositorys. Remotes sind nichts weiter als Lesezeichen für andere Repositorys. Statt den vollständigen Pfad einzugeben, können Sie ihn mit einem benutzerfreundlichen Namen referenzieren. Wir werden lernen, wie wir diese Lesezeichen in Git Below verwenden können.
Sie können Ihre vorhandenen Fernbedienungen anzeigen, indem Sie die git remote Befehl ohne Argumente:
git remote
Wenn Sie keine Fernbedienung haben, gibt dieser Befehl keine Informationen aus. Wenn du benutzt hast Git Klon Um Ihr Repository zu erhalten, sehen Sie eine Ursprung fernbedienung. Git fügt diese Verbindung automatisch hinzu, unter der Annahme, dass Sie wahrscheinlich mit der Verbindung auf der Straße interagieren möchten.
Mit der können Sie ein wenig mehr Informationen zu Ihren Fernbedienungen anfordern -v Flagge:
git remote -v
Dies zeigt den vollständigen Pfad zum Repository an. Das Angeben von Remote-Pfaden wird im nächsten Abschnitt beschrieben.
Das Git Remote hinzufügen Befehl erstellt eine neue Verbindung zu einem Remote-Repository.
Git Remote hinzufügen
Nachdem Sie diesen Befehl ausgeführt haben, können Sie das Git-Repository unter erreichen
Git akzeptiert viele Netzwerkprotokolle, um den Speicherort eines Remote-Repositorys anzugeben, einschließlich Datei://, ssh: //, http: //, und seine Gewohnheit git: // Protokoll. Zum Beispiel:
git remote fügt einige Benutzer ssh hinzu: //[email protected]/some-user/some-repo.git
Nachdem Sie diesen Befehl ausgeführt haben, können Sie unter auf das Repository zugreifen github.com/some-user/some-repo.git nur verwenden einige Benutzer. Da haben wir gebraucht ssh: // Als Protokoll werden Sie wahrscheinlich zur Eingabe eines SSH-Kennworts aufgefordert, bevor Sie etwas mit dem Konto tun dürfen. Dies macht SSH zu einer guten Wahl, um Entwicklern Schreibzugriff zu gewähren, während HTTP-Pfade im Allgemeinen nur für den Lesezugriff verwendet werden. Wie wir bald feststellen werden, ist dies als Sicherheitsfunktion für verteilte Umgebungen konzipiert.
Schließlich können Sie eine Remote-Verbindung mit dem folgenden Befehl löschen:
git remote rm
Commits können die atomare Einheit der Git-basierten Versionskontrolle sein, aber Geäst sind das Medium, in dem Remote-Repositorys kommunizieren. Ferne Niederlassungen verhalten Sie sich genauso wie die lokalen Zweigstellen, die wir bisher behandelt haben, es sei denn, sie repräsentieren einen Zweig in einem anderen Repository.
Nachdem Sie einen Remote-Zweig heruntergeladen haben, können Sie ihn wie jeden anderen Zweig prüfen, zusammenführen und erweitern. Dies führt zu einer sehr kurzen Lernkurve, wenn Sie die lokale Verwendung von Verzweigungen verstehen.
Das Herunterladen von Zweigen aus einem anderen Repository wird aufgerufen abholen. Um einen entfernten Zweig abzurufen, können Sie das Repository und den gewünschten Zweig angeben:
git holen
Oder, wenn Sie herunterladen möchten jeden verzweigen in -r Option zu Git-Zweig:
Git-Zweig -r
Dadurch erhalten Sie eine Zweigliste, die ungefähr so aussieht:
Ursprung / Masterursprung / Ursprungsort eines anderen Features / ein anderes Feature
Remote-Zweigen wird immer der Remote-Name vorangestellt (Ursprung/) um sie von den lokalen Niederlassungen zu unterscheiden.
Denken Sie daran, Git verwendet Remote-Repositorys als Lesezeichen-keine Echtzeitverbindungen mit anderen Repositorys. Remote-Zweige sind Kopien der lokalen Niederlassungen eines anderen Repositorys. Repositorys sind außerhalb des eigentlichen Abrufs vollständig isolierte Entwicklungsumgebungen. Dies bedeutet auch, dass Git niemals automatisch Zweige abruft, um auf aktualisierte Informationen zuzugreifen. Sie müssen dies manuell tun.
Dies ist jedoch eine gute Sache, da dies bedeutet, dass Sie sich nicht ständig darum kümmern müssen, was alle anderen bei Ihrer Arbeit leisten. Dies ist nur aufgrund des nicht-linearen Workflows möglich, der von Git-Zweigen aktiviert wird.
In jeder Hinsicht verhalten sich entfernte Zweige wie schreibgeschützte Zweige. Sie können ihre Geschichte sicher überprüfen und deren Commits über sehen git checkout, Sie können sie jedoch nicht weiter entwickeln, bevor Sie sie in Ihr lokales Repository integrieren. Dies ist sinnvoll, wenn Sie die Tatsache berücksichtigen, dass entfernte Zweige sind Kopien der Verpflichtungen anderer Benutzer.
Das … Syntax ist sehr nützlich zum Filtern des Protokollverlaufs. Der folgende Befehl zeigt beispielsweise alle neuen Updates von an Herkunft / Meister das sind nicht in deinem lokalen Meister Ast. Im Allgemeinen ist es eine gute Idee, dies vor dem Zusammenführen der Änderungen auszuführen, damit Sie genau wissen, was Sie integrieren:
Git Log Master… Herkunft / Master
Wenn dies Commits auslöst, bedeutet dies, dass Sie hinter dem offiziellen Projekt stehen und wahrscheinlich Ihr Repository aktualisieren sollten. Dies wird im nächsten Abschnitt beschrieben.
Es ist möglich, entfernte Zweigstellen zu überprüfen, aber Sie befinden sich in einem separaten Zweig KOPF Zustand. Dies ist sicher, um die Änderungen anderer Benutzer anzuzeigen, bevor sie integriert werden. Alle Änderungen, die Sie hinzufügen, gehen jedoch verloren, es sei denn, Sie erstellen einen neuen lokalen Zweigzweig, um auf sie zu verweisen.
Natürlich ist es das Wichtigste beim Abrufen, die resultierenden Remote-Zweige in Ihr lokales Projekt zu integrieren. Angenommen, Sie arbeiten an einem Open-Source-Projekt mit und haben an einer Funktion mit dem Namen "Arbeit" gearbeitet einige funktion. Als "offizielles" Projekt (typisch von) Ursprung) Wenn Sie sich vorwärts bewegen, möchten Sie möglicherweise die neuen Commits in Ihr Repository integrieren. Dies würde sicherstellen, dass Ihr Feature auch in Zukunft mit den neuesten Entwicklungen funktioniert.
Glücklicherweise können Sie genau das gleiche verwenden git merge Befehl zum Einfügen von Änderungen von Herkunft / Meister in deinen Funktionszweig:
git checkout einige Funktionen git holen Ursprung git zusammenführen Ursprung / Master
Da Ihre Geschichte auseinandergegangen ist, führt dies zu einer 3-Wege-Verschmelzung, nach der Ihre einige funktion Niederlassung hat Zugriff auf die aktuellste Version des offiziellen Projekts.
Accentsconagua
Meister in einen Feature-Zweig Jedoch häufig mit Herkunft / Meister Nur durch das Einspielen von Aktualisierungen wird schließlich eine mit bedeutungslosen Merge-Commits übersetzte Historie erzeugt. Je nachdem, wie genau Ihre Funktion den Rest der Codebasis nachverfolgen muss, kann eine Umbasierung eine bessere Möglichkeit sein, Änderungen zu integrieren:
git checkout einige Funktionen git holen Ursprung git rebase ursprung / master
Wie bei der lokalen Umbasierung entsteht eine perfekt lineare Geschichte ohne überflüssige Merge-Commits:
Meister Das erneute Laden / Zusammenführen von entfernten Zweigstellen hat genau die gleichen Kompromisse wie im Kapitel über lokale Zweigstellen beschrieben.
Da die Abruf- / Zusammenführungssequenz ein so häufiges Vorkommnis in der verteilten Entwicklung ist, bietet Git a ziehen Befehl als praktische Abkürzung:
Git ziehen Ursprung / Meister
Dadurch wird der Hauptzweig des Ursprungs abgerufen und in einem Schritt mit dem aktuellen Zweig verbunden. Sie können auch das übergeben --rebase Option zu verwenden Git Rebase anstatt git merge.
Um das zu ergänzen git holen Befehl, Git bietet auch eine drücken Befehl. Schieben ist fast Das Gegenteil von Abrufen ist das Abrufen von Verzweigungen, während die Verzweigungen in ein anderes Repository verschoben werden.
git Push
Der obige Befehl sendet das lokale git Push schafft ein lokal Ast. Zum Beispiel ausführen git Push Mary mein Feature in Ihrem lokalen Repository sieht aus Marys Perspektive wie folgt aus (Ihr Repository wird vom Push nicht beeinflusst).
Beachte das mein-Feature ist ein lokal Zweig in Marys Repository, während es eine wäre fernbedienung Branch hatte sie selbst geholt.
Dies macht das Drücken zu einer gefährlichen Operation. Stellen Sie sich vor, Sie entwickeln in Ihrem eigenen lokalen Repository, wenn plötzlich ein neuer Zweig vor Ort auftaucht. Repositorys sollten jedoch als vollständig isolierte Entwicklungsumgebungen dienen. Warum also? git Push sogar existieren? Wie wir in Kürze erfahren werden, ist Pushing ein notwendiges Werkzeug für die Verwaltung öffentlicher Git-Repositorys.
Nachdem wir eine grundlegende Vorstellung davon haben, wie Git mit anderen Repositorys interagiert, können wir die realen Workflows diskutieren, die von diesen Befehlen unterstützt werden. Die zwei am häufigsten verwendeten Modelle für die Zusammenarbeit sind: der zentralisierte Workflow und der Integrator-Workflow. SVN- und CVS-Benutzer sollten sich durchaus mit Gits Variante der zentralen Entwicklung auskennen. Wenn Sie jedoch Git verwenden, können Sie auch die hocheffizienten Merge-Funktionen nutzen. Der Integrator-Workflow ist ein typisches verteiltes Collaboration-Modell und ist in rein zentralisierten Systemen nicht möglich.
Beachten Sie beim Durchlesen dieser Workflows, dass Git alle Repositories als gleichwertig behandelt. Es gibt kein "Master" -Repository nach Git wie bei SVN oder CVS. Die "offizielle" Codebasis ist lediglich eine Projektkonvention. Der einzige Grund für das offizielle Repository besteht darin, dass sich hier jeder befindet Ursprung entfernte Punkte.
Jedes Kollaborationsmodell umfasst mindestens eines Öffentlichkeit Repository, das als Einstiegspunkt für mehrere Entwickler dient. Öffentliche Repositories haben die einzigartige Einschränkung des Seins nackt-Sie dürfen kein Arbeitsverzeichnis haben. Dadurch wird verhindert, dass Entwickler versehentlich die Arbeit der anderen überschreiben git Push. Sie können ein bloßes Repository erstellen, indem Sie das --nackt Option zu git init:
git init --bare
Öffentliche Repositorys sollten nur als funktionieren Lagerhäuser-keine Entwicklungsumgebungen. Dies wird durch Hinzufügen von a vermittelt .git Erweiterung des Dateipfads des Repositorys, da sich die interne Repository - Datenbank im Projektstamm und nicht im .git Unterverzeichnis. Ein vollständiges Beispiel könnte also so aussehen:
git init --bare some-repo.git
Abgesehen von einem fehlenden Arbeitsverzeichnis ist ein bloßes Repository nichts Besonderes. Sie können Remote-Verbindungen hinzufügen, darauf drücken und auf die übliche Weise abziehen.
Der zentralisierte Workflow eignet sich am besten für kleine Teams, in denen jeder Entwickler Schreibzugriff auf das Repository hat. Es ermöglicht die Zusammenarbeit über ein zentrales Repository, ähnlich dem SVN- oder CVS-Workflow. In diesem Modell, alles Änderungen müssen über das zentrale Repository gemeinsam genutzt werden, das normalerweise auf einem Server gespeichert wird, um eine internetbasierte Zusammenarbeit zu ermöglichen.
Entwickler arbeiten individuell in ihrem eigenen lokalen Repository, das von allen anderen völlig isoliert ist. Wenn sie eine Funktion abgeschlossen haben und ihren Code freigeben können, bereinigen sie ihn und integrieren ihn in ihren lokalen Code Meister, und schieben Sie es in das zentrale Repository (z., Ursprung). Dies bedeutet auch, dass jeder Entwickler SSH-Zugriff auf das zentrale Repository benötigt.
Dann können alle anderen die neuen Commits abrufen und sie in ihre lokalen Projekte integrieren. Dies kann je nach den Konventionen Ihres Teams entweder mit einer Zusammenführung oder einer Rebase durchgeführt werden.
Dies ist der Kernprozess hinter zentralisierten Workflows, der jedoch einen Schlag bekommt, wenn mehrere Benutzer gleichzeitig versuchen, das zentrale Repository zu aktualisieren. Stellen Sie sich ein Szenario vor, in dem zwei Entwickler ein Feature fertiggestellt und es mit ihrem lokalen zusammengeführt haben Meister, und hat versucht, es gleichzeitig zu veröffentlichen (oder in der Nähe).
Wer zuerst auf den Server kommt, kann seine Commits wie gewohnt pushen, aber der zweite Entwickler bleibt mit einer abweichenden Historie hängen und Git kann keine Zusammenführung mit schnellem Vorlauf durchführen. Wenn beispielsweise ein Entwickler namens John seine Änderungen direkt vor Mary pushen würde, würden wir einen Konflikt in Marys Repository sehen:
Der einzige Weg das zu machen Ursprung's Master (aktualisiert von John) passt zu Mary' s Meister ist zu überschreiben Johns Verpflichtung Natürlich wäre dies sehr schlecht, daher bricht Git den Push ab und gibt eine Fehlermeldung aus:
! [Abgelehnt] Master -> Master-Fehler (Nicht-Schnellvorlauf): Einige Refs konnten nicht in "some-repo.git" verschoben werden.
Um dieser Situation abzuhelfen, muss Mary mit dem zentralen Repository synchronisiert werden. Dann kann sie ihre Änderungen wie üblich vorantreiben.
git fetch ursprung master git rebase ursprung / master git push ursprungsmaster
Abgesehen davon ist der zentralisierte Workflow relativ einfach. Jeder Entwickler bleibt in seinem eigenen lokalen Repository und zieht regelmäßig in das zentrale Repository, um alles auf dem neuesten Stand zu halten. Es ist ein bequemer Workflow, der eingerichtet werden muss, da nur ein Server erforderlich ist und vorhandene SSH-Funktionen genutzt werden.
Der Integrator-Workflow ist ein verteiltes Entwicklungsmodell, bei dem alle Benutzer ihr eigenes beibehalten Öffentlichkeit Repository zusätzlich zu ihrem privaten. Es ist eine Lösung für die Sicherheits- und Skalierbarkeitsprobleme des zentralisierten Workflows.
Der Hauptnachteil des zentralisierten Workflows besteht darin jeden Entwickler benötigt Push-Zugriff auf das gesamte Projekt. Dies ist in Ordnung, wenn Sie mit einem kleinen Team vertrauenswürdiger Entwickler zusammenarbeiten. Stellen Sie sich jedoch ein Szenario vor, in dem Sie an einem Open-Source-Softwareprojekt arbeiten und ein Fremder einen Fehler gefunden, ihn behoben und das Update in das Hauptprojekt. Sie möchten ihm wahrscheinlich keinen Push-Zugriff auf das zentrale Repository gewähren, da er oder sie alle möglichen zufälligen Commits einsetzen könnte und Sie die Kontrolle über das Projekt verlieren würden.
Was Sie jedoch tun können, ist dem Mitwirkenden mitzuteilen, die Änderungen zu verschieben sein oder ihr eigenes öffentliches Repository. Anschließend können Sie seinen Bugfix in Ihr privates Repository ziehen, um sicherzustellen, dass er keinen nicht deklarierten Code enthält. Wenn Sie seine Beiträge genehmigen, müssen Sie sie lediglich in einer lokalen Zweigstelle zusammenführen und wie üblich in das Haupt-Repository verschieben. Du bist ein geworden Integrator, zusätzlich zu einem gewöhnlichen Entwickler:
In diesem Workflow muss jeder Entwickler nur auf Push zugreifen sein oder ihr eigenes öffentliches Repository. Der Beitragende verwendet SSH, um zu seinem öffentlichen Repository zu pushen, der Integrator kann die Änderungen jedoch über HTTP (ein schreibgeschütztes Protokoll) abrufen. Dies sorgt für eine sicherere Umgebung für alle, auch wenn Sie weitere Mitarbeiter hinzufügen:
Beachten Sie, dass das Team sich immer noch auf ein einziges "offizielles" Repository einigen muss, um die Daten abzurufen. Andernfalls würden Änderungen außerhalb der Reihenfolge vorgenommen, und alle würden sehr schnell außer Betrieb geraten. Im obigen Diagramm ist "Your Public Repo" das offizielle Projekt.
Als Integrator müssen Sie mehr Fernbedienungen nachverfolgen, als Sie dies im zentralen Workflow tun würden. Dies gibt Ihnen jedoch die Freiheit und Sicherheit, Änderungen von jedem Entwickler zu übernehmen, ohne die Stabilität des Projekts zu gefährden.
Darüber hinaus verfügt der Integrator-Workflow nicht über einen einzelnen Zugriffspunkt, der als Choke-Punkt für die Zusammenarbeit dient. Bei zentralisierten Workflows muss jeder vor dem Veröffentlichen von Änderungen vollständig auf dem neuesten Stand sein. Dies ist bei verteilten Workflows jedoch nicht der Fall. Dies ist wiederum ein direktes Ergebnis des nichtlinearen Entwicklungsstils, der durch die Implementierung von Gits Zweig implementiert wird.
Dies sind enorme Vorteile für große Open Source-Projekte. Die Organisation von Hunderten von Entwicklern für die Arbeit an einem einzelnen Projekt wäre ohne die Sicherheit und Skalierbarkeit der verteilten Zusammenarbeit nicht möglich.
Die Unterstützung dieser zentralisierten und verteilten Kollaborationsmodelle war alles, was Git jemals tun sollte. Das Arbeitsverzeichnis, die Bühne, Commits, Verzweigungen und Fernbedienungen wurden speziell für diese Workflows entwickelt, und praktisch alles in Git dreht sich um diese Komponenten.
Getreu der UNIX-Philosophie wurde Git als eine Suite interoperabler Tools und nicht als ein einziges monolithisches Programm konzipiert. Wenn Sie sich mit den zahlreichen Funktionen von GIT beschäftigen, werden Sie feststellen, dass es sehr einfach ist, einzelne Befehle an völlig neuartige Workflows anzupassen.
Ich überlasse es Ihnen nun, diese Konzepte auf reale Projekte anzuwenden. Wenn Sie jedoch damit beginnen, Git in Ihren täglichen Arbeitsablauf einzubeziehen, denken Sie daran, dass dies kein Vorzug für das Projektmanagement ist. Es ist lediglich ein Werkzeug zum Nachverfolgen Ihrer Dateien. Kein intimes Git-Wissen kann eine Reihe von Konventionen innerhalb eines Entwicklerteams wettmachen.
Diese Lektion repräsentiert ein Kapitel aus Git Erfolgreich, ein kostenloses eBook aus dem Team von Syncfusion.
