In unseren vorherigen Tutorials für die Git-Versionskontrollsoftware haben wir die wesentlichen grundlegenden Befehle für die Verwendung von git as gelernt sowie wie man mit Github.com zusammenarbeitet, um ein Repository einzurichten und unseren Projektcode auf die Website zu übertragen.
Jetzt ist es an der Zeit, tatsächlich mit GitHub (und git) so zu arbeiten, wie sie sein sollen verwendet: Änderungen im Projekt sicher auf einer Seite vornehmen und sie wieder in das ursprüngliche Projekt einfügen, sobald sie sich als richtig erwiesen haben. Oder zumindest nicht katastrophal.
Inzwischen verstehen Sie, dass git jede Version Ihres Projekts als Momentaufnahme des Codes genau so speichert, wie er zu dem Zeitpunkt war, als Sie ihn festgeschrieben haben. Erstellen Sie im Wesentlichen eine Zeitleiste mit Versionen eines Projekts im weiteren Verlauf, damit Sie im Katastrophenfall auf eine frühere Version zurücksetzen können.
Die Art und Weise, wie Git und GitHub diese Zeitleiste verwalten – insbesondere wenn mehr als eine Person im Projekt arbeitet und Änderungen vornimmt – ist durch die Verwendung von Zweigen. Ein Zweig ist im Wesentlichen ein eindeutiger Satz von Codeänderungen mit einem eindeutigen Namen. Jedes Repository kann einen oder mehrere Zweige haben. Der Hauptzweig – der, in dem alle Änderungen schließlich wieder zusammengeführt werden, wird als Master bezeichnet. Dies ist die offizielle Arbeitsversion Ihres Projekts und die, die Sie sehen, wenn Sie das Projekt-Repository unter github.com/yourname/projectname besuchen.
Leg dich nicht mit dem Master an. Wenn Sie Änderungen am Hauptzweig eines Gruppenprojekts vornehmen, während andere Personen ebenfalls daran arbeiten, wirken sich Ihre Änderungen im laufenden Betrieb auf alle anderen aus, und sehr schnell kommt es zu Zusammenführungskonflikten, Weinen und Zerreißen von Kleidungsstücken. und Heuschreckenplagen. Es ist so ernst.
Warum ist es so wichtig, dass der Meister sich nicht damit anlegt? Ein Wort: Der Hauptzweig kann bereitgestellt werden. Es ist Ihr Produktionscode, der bereit ist, in die Welt zu rollen. Der Master-Zweig soll stabil sein, und es ist der Gesellschaftsvertrag von Open Source-Software, niemals etwas zum Master zu pushen, das nicht getestet wurde oder das den Build bricht. Der gesamte Grund, warum GitHub funktioniert, ist, dass es immer sicher ist, vom Master aus zu arbeiten.
Verzweigen
Stattdessen verwendet jeder vom Master erstellte Zweige, um zu experimentieren, Änderungen vorzunehmen und Ergänzungen und Änderungen vorzunehmen , bevor dieser Zweig schließlich wieder in den Master gerollt wird, sobald er genehmigt wurde und bekanntermaßen funktioniert. Der Master wird dann aktualisiert, um alle neuen Inhalte zu enthalten.
Um mit der Arbeit an neuen Elementen in einem Projekt zu beginnen oder vorhandene Dinge zu ändern, erstellen Sie einen Zweig außerhalb des stabilen Master-Zweigs. Arbeiten wir weiter mit dem Beispielprojekt, das für unser vorheriges Tutorial erstellt wurde, good ol ’studious_octo_carnival. Öffnen Sie jetzt Ihre Version auf Ihrem Computer und speichern Sie sie im Verzeichnis.
Schritt 1: Bestandsaufnahme.
Bevor Sie neue Zweige erstellen, möchten wir nach anderen vorhandenen Zweigen suchen . Wir wissen über den Meister Bescheid, aber wer weiß, was unsere Projektmitarbeiter vorhaben, diese schelmischen Affen? Wir können also alle vorhandenen Zweige anzeigen, indem wir „git branch -a“ in das Terminal eingeben. Dadurch wird git mitgeteilt, dass ALLE Zweige in diesem Projekt angezeigt werden sollen, auch diejenigen, die sich nicht in unserem lokalen Arbeitsbereich befinden.
Dies gibt die Ausgabe zurück, die Sie im folgenden Codebeispiel sehen. Das Erscheinungsbild kann je nach Betriebssystem und Terminalanwendung etwas variieren, aber die Informationen sind letztendlich dieselben. Das Sternchen neben „master“ in der ersten Zeile der Ausgabe zeigt an, dass wir es sind derzeit in diesem Zweig. Die zweite Zeile sagt uns, dass es auf unserer entfernten, benannten Herkunft einen einzelnen Zweig gibt, der auch als Master bezeichnet wird. (Denken Sie daran, dass unsere Fernbedienung das GitHub-Repo für dieses Projekt ist.)
Schritt 2: Erstellen Sie einen neuen Zweig
Jetzt, da wir wissen, wie man Zweige anzeigt, machen wir einen! Denken Sie dabei daran, dass wir unsere Hauptniederlassung haben, unser ursprüngliches Projekt. Wir werden jetzt eine neue Version des Projekts erstellen, einen Zweig, mit dem wir herumspielen und lokal Änderungen auf unserem Computer vornehmen können – während die ursprüngliche Version des Projekts, der Master, dort oben auf GitHub sicher unbehelligt bleibt. Wir geben dem neuen Zweig einen beschreibenden Namen, um uns daran zu erinnern, was wir während der Arbeit daran tun wollen. In diesem Fall handelt es sich um ein einfaches „Hallo Welt“ -Ding. Nennen wir es also „hello_octo“.
Um diesen neuen Zweig zu erstellen, geben Sie „git checkout -b branchNameHere“ ein (in unserem Fall also) „git checkout -b hello_octo“).
Angenommen, niemand anderes hat bereits einen Zweig mit dem Namen „hello_octo“ erstellt, gibt git „Zu einem neuen Zweig ‚hello_octo‘ gewechselt“ zurück. (In dem Fall, in dem bereits ein Zweig mit diesem Namen existiert, würde git uns stattdessen sagen: „Schwerwiegend: Ein Zweig mit dem Namen ‚hello_octo‘ existiert bereits.“ Keine große Sache, machen Sie einfach git checkout -b erneut mit einer neuen Namensvariante.)
Wir können auch den Befehl git checkout verwenden, um zwischen unseren beiden Zweigen hin und her zu wechseln. Geben Sie „git checkout branchName“ ein, um zu diesem Zweig zu wechseln.“Git checkout master“ bringt Sie zum Master, während „git checkout hello_octo“ Sie zurück zum Zweig hello_octo bringt.
Wenn Sie versuchen, zu einem Zweig zu wechseln, der nicht vorhanden ist, z. B. „git checkout hello_kitty“, teilt git Ihnen mit, dass dies kein Problem ist:
Woher weiß Git, auf welchem Zweig Sie sich gerade befinden? Git beobachtet immer, was Sie tun, und behält einen speziellen Zeiger namens HEAD bei. Wie die Nadel auf einem Kompass immer nach Norden zeigt, zeigt HEAD immer das an lokaler Zweig, in dem Sie sich gerade befinden.
(Wir hätten unseren Zweig auch mit dem git-Befehl „git branch branchNameHere“ erstellen und dann mit git checkout zu ihm wechseln können. Allerdings die nette kleine Verknüpfung mit dem „-b“ in „git checkout -b branchNameHere“ erstellt sowohl den Zweig als auch wechselt zu ihm. Ich kann Ihnen nicht sagen, wie viele neue Git-Codierer Fehlermeldungen und Frustrationen erzeugen, weil sie einfach nicht daran gedacht haben, zu ihrem neuen Zweig zu wechseln nach dem Erstellen i t. Daher bleiben wir bei der Git-Kasse -b, mmmkay?)
Änderungen an unserem Arbeitszweig vornehmen
Jetzt, da wir mehrere Zweige haben – unseren Arbeitszweig, an dem Änderungen vorgenommen werden können, und Unsere Hauptniederlassung bleibt sicher unbehelligt – wir können uns an die Arbeit machen. In unserem Szenario werden wir unseren Zweig „hello_octo“ zum Vornehmen und Testen unserer Änderungen verwenden und diese dann wieder in den Hauptzweig von GitHub verschieben.
Denken Sie daran, sicherzustellen, dass Sie sich auf Ihrem befinden Arbeitszweig und nicht Master mit gutem alten Git-Zweig -a.
Schritt 3. Erstellen Sie eine neue leere Datei mit dem Namen „hello_octo_world“:
(Diese leere Datei dient nur zu Demonstrationszwecken. Sie müssen sich also keine Sorgen machen, dass es keinen Namen / Typ für die Dateierweiterung gibt.)
Da sie brandneu ist, richtig Jetzt befindet sich diese Datei nur noch in Ihrer Filiale. Verwenden Sie den Befehl „ls“, um ihn anzuzeigen:
Denken Sie jedoch daran, dass wir uns in unserem Arbeitszweig befinden, hello_octo, wo Wir haben dieses neue Ding erschaffen. Der Master weiß nichts über no hello_octo, weil es sicher gegen alle Änderungen isoliert ist, die wir hier auf dem Arbeitszweig vornehmen. Es ist immer noch derselbe gelassene Master, mit dem wir angefangen haben:
Schritt 4: Stellen Sie unsere neue Datei bereit und übergeben Sie sie an den Arbeitszweig.
Jetzt ist es Zeit um unsere neue Datei im Arbeitszweig zu inszenieren (hinzuzufügen) und festzuschreiben. (Kommt Ihnen das bekannt vor?). Dadurch wird diese neue Entität an den Arbeitszweig angehängt, um sie schließlich auf den Master zu verschieben. Diese Datei ist jetzt im Zweig hello_octo vorhanden. Wie wir oben gesehen haben, ist es derzeit nicht im Hauptzweig vorhanden.
Zu diesem Zeitpunkt haben Sie gerade eine genommen Momentaufnahme von Änderungen an der Branche. In einem realen Projekt gibt es wahrscheinlich mehr Änderungen und Arbeit getan werden. Jetzt würden Sie dies tun und an logischen Punkten Commits auf dem Weg machen. Denken Sie daran, dass Commits auf GitHub Ihre aufeinander folgenden Speicherungen darstellen. Jedem Commit ist eine Commit-Nachricht zugeordnet. In dieser Beschreibung wird speziell erläutert, was Sie dort getan haben und warum. Commit-Nachrichten erfassen den Verlauf Ihrer Änderungen, sodass Sie und andere Projektmitarbeiter in Zukunft verstehen können, was Sie getan haben und warum.
Zusammenführen von Code zwischen Zweigen
Sobald wir sind endlich fertig mit allen Änderungen und Ergänzungen – und alles funktioniert * – es ist Zeit zu verschmelzen. Der interessante Teil kommt, nachdem wir wieder zu unserer Hauptniederlassung gewechselt sind (was – sagen Sie es mir! – wir tun es mit „git checkout master“). „Hello_octo_world“ scheint zu fehlen, aber es ist nicht – derzeit existiert es in unserer Arbeit Niederlassung und wir sind in unserer Hauptniederlassung. Ich zeige Ihnen dies noch einmal, weil es das Herzstück des Verständnisses von Zweigen in Git ist:
Nun: in dieser Übung „hello_octo_world“ steht für jede Änderung an einer Datei (oder das Hinzufügen einer ganz neuen Datei), die alle Tests in unserem Entwicklungszweig bestanden hat und bereit ist, in Produktion zu gehen. Der Prozess des Verschiebens von Code zwischen Zweigen (häufig von der Entwicklung zu) Produktion) wird als Zusammenführen bezeichnet.
Sehr wichtig: Beim Zusammenführen müssen wir uns in dem Zweig befinden, zu dem wir zusammenführen möchten. Grundsätzlich werden wir git sagen: „Sehen Sie das Neue? Es ist in Ordnung, es jetzt hierher zu bringen. “
Schritt 5: Änderungen des Arbeitszweigs zusammenführen
In diesem Fall, da wir von unserem Arbeitszweig zusammenführen möchten, wo die“ hello_octo_world “ Datei existiert, zu unserem Master-Zweig müssen wir uns auf dem Master befinden.
Sobald wir uns im Master-Zweig befinden, müssen wir nur noch den Befehl merge ausführen. Der beste Weg, dies zu tun, ist die Eingabe von “ git merge –no-ff ”- Das zusätzliche“ –no-ff „teilt git mit, dass wir alle Commit-Nachrichten vor dem Zusammenführen beibehalten möchten. Dies erleichtert das Nachverfolgen von Änderungen in Zukunft:
Zurück zu GitHub
Das Letzte, was wir jetzt tun müssen, ist, GitHub wissen zu lassen, mit dem wir herumgespielt haben Beherrschen Sie hier unten unsere lokale Entwicklungsumgebung.
Mit anderen Worten, es ist Zeit für Git Push. Sie haben dies!
Die Git-Ausgabe bestätigt, dass die Zusammenführung von Ihrem Entwicklungszweig zum Hauptzweig in Ihrer lokalen Umgebung erfolgt. wurde jetzt auf den Remote-Server kopiert: „master → master“.
Und das war’s! Wir haben erfolgreich einen vom Master getrennten Arbeitszweig erstellt. Änderungen daran vorgenommen. Diese Änderungen wurden inszeniert und festgeschrieben. Anschließend wurden sie zusammengeführt Zurück zum Master in unserer lokalen Arbeitsumgebung. Schließlich wurde alles auf GitHub hochgeschoben, sodass alle Versionen unseres Projekts überall gleich sind!
Ein letzter Hinweis
Einige Aufräumarbeiten ist jetzt in Ordnung: Da wir unseren hello_octo-Zweig erfolgreich zusammengeführt haben, brauchen wir ihn nicht mehr. Um einen zusammengeführten Zweig zu löschen, geben Sie einfach „git branch -d branchName“ ein:
Keine Sorge: Wenn Sie versehentlich versuchen, einen Zweig zu löschen, der noch nicht zusammengeführt wurde, gibt git einen Fehler aus.
Also! Bisher haben wir ein extrem vereinfachtes Beispielprojekt verwendet, da es an dieser Stelle am wichtigsten ist, den Git-Workflow zu verstehen und zu assimilieren. Das Zusammenführen ist in der realen Welt viel mehr als das. Was passiert beispielsweise, wenn Sie Fehlermeldungen erhalten, weil beim Zusammenführen Konflikte auftreten? Keine Sorge, neuer Git-ster, wir werden es schaffen.
Ihre Hausaufgaben: Erstellen („berühren“) Sie weitere neue Dateien im Beispielprojekt und üben Sie, Änderungen vorzunehmen, sie zu inszenieren, festzuschreiben und schließlich zusammenzuführen Zurück. Achten Sie darauf, zu verstehen, wohin Ihr KOPF zeigt – dh was Ihr aktueller Zweig ist. Übernehmen Sie nur Änderungen an Ihrem Arbeitszweig.
Denn denken Sie daran: Nicht. Mess. Mit. The. Master .