advanced git commands
In diesem Tutorial werden nützliche Git-Befehle wie Git Stash, Git Reset, Git Cherry Pick, Git Bisect und die Integration von GitHub in Jira erläutert:
In unseren vorherigen Tutorials in dieser Reihe haben wir die meisten Funktionen von GitHub gesehen.
In diesem Tutorial werden wir uns Folgendes ansehen:
- Releases erstellen
- Integration mit Atlassian Jira
- Am häufigsten verwendete Git-Befehle für Entwickler
- Git Stash
- Git Cherry Pick
- Git Reset
- Git Bisect
=> Schauen Sie sich hier den GitHub-Leitfaden an.
was dbms läuft auf einem pc
Was du lernen wirst:
- Releases erstellen
- GitHub-Integration mit Jira
- Erweiterte Git-Befehle für Entwickler
- Fazit
- Literatur-Empfehlungen
Releases erstellen
Releases in GitHub werden verwendet, um Ihre Software zu bündeln, Versionshinweise und Binärdateien (WAR-, EAR-, JAR-Dateien) hinzuzufügen, damit Kunden und Benutzer diese verwenden können.
Um ein Release zu erstellen, rufen Sie die Hauptseite des Repositorys auf und klicken Sie auf Veröffentlichungen Registerkarte unter Themen verwalten.
Klicke auf Erstellen Sie eine neue Version.
Geben Sie einen Tag und einen Release-Titel an. Die Binärdateien werden ebenfalls zur Version hinzugefügt. Sobald Sie fertig sind, klicken Sie auf Release veröffentlichen.
Die Version ist jetzt mit dem Quellcode und den Binärdateien fertig.
GitHub-Integration mit Jira
Einer der wichtigen Aspekte der Rückverfolgbarkeit besteht darin, das Jira-Problem mit den Commits in GitHub zu referenzieren. GitHub kann in Jira integriert werden, um nicht nur auf das Problem zu verweisen, sondern auch um Zweige und Pull Request aus Jira heraus zu erstellen.
Sobald der Entwickler mit der Arbeit an der Aufgabe oder den Fehlern beginnt, wird in der Regel ein Zweig von ihm erstellt. Nach der Entwicklung oder Behebung der Fehler kann eine Pull-Anfrage von Jira erstellt werden, um sie mit der Hauptanforderung zusammenzuführen Meister Ast. Der vom Entwickler erstellte Zweig kann dann gelöscht werden.
Um die Integration einzurichten, haben wir ein Plugin verwendet Git-Integration für Jira. Dies ist ein kommerzielles Plugin. Das Plugin kann von heruntergeladen werden Hier
Installieren Sie das Plugin in Jira von Admin -> Add-Ons.
Sobald das Plugin installiert ist, gehen Sie zu Anwendung -> Git Repositories und verbinde dich mit GitHub.
Geben Sie den GitHub-Benutzernamen und das Passwort ein. Klicken Verbinden .
Die für das Benutzerkonto genannten Repositorys werden angezeigt. Klicke auf Repositorys importieren um das Integrations-Setup abzuschließen.
GitHub Commit mit Jira-Problem
Geben Sie als Teil der Festschreibungsnachricht wie unten gezeigt ein. Klicke auf Änderungen festschreiben .
Beispiel 1: Unten ist ein Beispiel von Smart Commit Dadurch können die Entwickler über die Festschreibungsnachricht Aktionen für die Jira-Probleme ausführen. Ein solcher Befehl ist der #Kommentar zusammen mit dem Issue-Schlüssel, der den Kommentar zum Jira-Problem hinzufügt, wie unten gezeigt.
Kommentarbereich aktualisiert.
Beispiel 2: Weisen Sie einem Benutzer zu und aktualisieren Sie die aufgewendete Zeit auf 4 Stunden.
Verwenden Sie die #zuordnen und #Zeit Befehl smart commit in der Festschreibungsnachricht.
Beide Aktionen wurden abgeschlossen.
Beispiel 3: Ändern Sie den Status des Problems in In Bearbeitung .
Erstellen Sie einen Zweig
Da Entwicklern Aufgaben und Fehler zugewiesen werden, müssen sie mit der Entwicklung beginnen. Zu diesem Zweck erstellen sie einen Zweig für das Problem, an dem sie arbeiten, führen die Entwicklungsaktivitäten durch und lösen eine Pull-Anforderung aus, um in den Hauptzweig zu verschmelzen.
Klicken Sie in der Jira-Ausgabe unten auf Zweig erstellen.
Klicke auf Zweig erstellen.
Nehmen Sie in GitHub eine Änderung an der Datei im oben erstellten Zweig vor und schreiben Sie diese fest.
Nach Abschluss der Entwicklung kann der Benutzer eine Pull-Anfrage von Jira stellen.
Klicken Sie unten in der Ausgabe auf Pull-Anfrage erstellen.
Klicke auf Erstellen. Die Pull-Anfrage wird als offen angezeigt.
Der nächste Schritt ist das Zusammenführen der Pull-Anforderung in GitHub.
Der Status wird in Jira entsprechend aktualisiert.
Erweiterte Git-Befehle für Entwickler
In diesem letzten Abschnitt werden einige der häufig verwendeten Git-Befehle für Entwickler vorgestellt. Nichts mit GitHub zu tun, aber es wird den Entwicklern helfen, bevor sie die Änderungen an GitHub übertragen.
Git Stash
In den meisten Projektszenarien, in denen Sie an einer neuen Funktion oder Erweiterung arbeiten, müssen Sie plötzlich an einem dringenden Fehler arbeiten, der gemeldet wurde und ein Show-Stopper ist. Da Sie sich in der Mitte Ihrer neuen Arbeit befinden und diese noch nicht abgeschlossen haben, macht es keinen Sinn, die Änderungen vorzunehmen, die zur Hälfte durchgeführt wurden.
Es ist daher besser, die halbfertige Arbeit vorübergehend auszusetzen oder zu speichern, den Fehler zu beheben und wieder an der neuen Funktion oder Verbesserung zu arbeiten. Git Stash bietet eine Lösung dafür. Sie können den Kontext für Änderungen schnell ändern.
Beispiel 1 ::Angenommen, Sie arbeiten an einer Ihnen zugewiesenen Aufgabe, und wenn Sie sich den Status ansehen, wird angezeigt, dass er ab sofort nicht mehr verfolgt wird.
Plötzlich wird Ihnen ein Fehler mit hoher Priorität zugewiesen. Daher müssen wir die Arbeit, an der gerade gearbeitet wird, vorübergehend speichern oder aufbewahren.
Führen Sie den folgenden Befehl aus.
git stash save 'Nachricht'
In diesem Moment ist das Arbeitsverzeichnis sauber. Es können neue Commits vorgenommen werden. Wenn es Fehler gibt, können Sie den Zweig wechseln, um daran zu arbeiten usw.
Wenn Sie die Änderungen an der Stelle, an der Sie sie hinterlassen haben, erneut anwenden möchten, verwenden Sie den Befehl.
Git Stash Pop
Der obige Befehl entfernt den Stash aus der Liste und wendet den zuletzt gespeicherten Status an.
Sie können auch verwenden:
Git Stash anwenden
Der obige Befehl behält die Änderungen im Vorrat bei und entfernt sie nicht.
Jetzt werden die Änderungen erneut angewendet und Sie können die Änderungen festschreiben.
Beispiel 2: Verstecken Sie Ihre Änderungen, wechseln Sie den Zweig und führen Sie Änderungen zusammen.
Nehmen Sie die Änderung an der HTML-Datei in der vor Meister Verzweigungs- und Versteckänderungen.
Als nächstes wechseln Sie zu Fehler verzweigen, Änderungen vornehmen und Änderungen festschreiben.
Git Checkout -b Fehler
Nehmen Sie Änderungen an der HTML-Datei vor.
git commit -a -m 'E-Mail-Problem behoben'
Wechseln Sie zurück zu Meister Änderungen aus dem Stash verzweigen und erneut anwenden.
Jetzt aus dem zusammenführen Fehler Zweig zum Meister Ast. Übernehmen Sie die Änderungen nach dem Zusammenführen.
Beispiel 3: Arbeiten mit mehreren Verstecken.
Im lokalen Repo gibt es 2 HTML-Dateien. Es ist daher möglich, dass mehrere Entwickler an mehreren Dateien arbeiten und Änderungen nach Bedarf speichern, um dringende Anforderungen zu bearbeiten, die zur Behebung der Änderungen anfallen.
Entwickler 1 arbeitet mit hello.html und Entwickler 2 arbeitet mit index.html.
Entwickler 1
Die Stash-Liste hat jetzt 1 Eintrag.
Entwickler 2
Die Vorratsliste enthält jetzt 2 Einträge. Der letzte Stash befindet sich zuerst im Stack, nämlich Stash @ {0}. Jetzt können beide Entwickler dringend andere Commits ausführen oder an einem anderen Zweig arbeiten und dann zum zurückkehren Meister verzweigen und die Stash-Änderungen anwenden.
Um den neuesten Stash anzuwenden, können Sie ihn einfach ausführen
Git Stash Pop
Führen Sie den folgenden Befehl aus, um einen bestimmten Stash im Stack anzuwenden.
Git Stash Pop Stash @ {1}
Wenden wir den zweiten Stash an stash @ {1}
Ebenso kann der andere Vorrat angewendet werden.
Git Cherry Pick
Heute arbeiten die Entwickler an mehreren Zweigen wie Funktionen, Verbesserungen, Fehlern usw.
Es gibt Situationen, in denen nur einige bestimmte Commits ausgewählt werden müssen und nicht der gesamte Zweig in einem anderen Zweig zusammengeführt werden muss. Dies wird als Cherry Pick bezeichnet. Mit diesem Vorgang können Sie ein beliebiges Git-Commit aus den anderen Zweigen beliebig auswählen und an den aktuellen HEAD des Arbeitsbaums anhängen.
Beispiel 1:
Im lokalen Git-Repository haben wir die folgenden 6 Dateien.
Eine Datei wird gelöscht, z. B. file5.txt.
Übernehmen Sie die Änderungen.
Schauen Sie sich jetzt das Protokoll an. File5.txt wird gelöscht.
Wir möchten also das Commit auswählen, bei dem wir file5.txt hinzugefügt haben. Wir müssen die Commit-ID von file5.tx finden und den Befehl ausführen.
Git Cherry-Pick
In diesem Fall lautet die Festschreibungs-ID zum Zeitpunkt des Hinzufügens von file5.txt a2f0124
File5.txt wird jetzt wiederhergestellt. Wir haben das Commit ausgewählt.
Beispiel 2:
Lassen Sie uns einfach ändern file6.txt und übernehmen Sie die Änderungen in der Meister Ast.
Schauen Sie sich die zweite Zeile an file6.txt wo die E-Mail nicht richtig angegeben ist.
Erstellen Sie einen Fehlerzweig und beheben Sie das Problem. Gleichzeitig ändern Sie auch file5.txt so, dass im Fehlerzweig mehrere Commits ausgeführt werden, Cherry-Pick jedoch nur das in file6.txt vorgenommene Commit ausführt.
Datei6 geändert in Fehler Ast.
Insgesamt haben wir also Änderungen an vorgenommen Datei5 und Datei6 in der Bug-Filiale.
Wechseln wir jetzt zurück zu Meister branch und Cherry-Pick das Commit nur für file6.txt.
Wie Sie sehen können, anstatt die Fehler verzweigen in die Meister Zweig, wir haben nur Cherry-Picked nur ein bestimmtes Commit und angewendet in der Hauptzweig.
Git Reset
Git Reset ist ein leistungsstarker Befehl zum Rückgängigmachen lokaler Änderungen. Um die Bereitstellung aller bereitgestellten Dateien aufzuheben, wird dieser Befehl verwendet.
Beispiel
Ändern Sie eine Datei und fügen Sie sie dem Staging hinzu. Setzen Sie den Befehl wie gezeigt zurück, wenn die bereitgestellten Änderungen nicht bereitgestellt werden.
Parameter von Git zurücksetzen Befehl.
-Sanft: Dieser Parameter zeigt den HEAD auf ein anderes Commit. Alle Dateien werden zwischen dem ursprünglichen HEAD geändert und das Commit wird bereitgestellt. Das Arbeitsverzeichnis ist intakt.
Sehen Sie sich den aktuellen HEAD-Standort an.
Gehen wir 5 Commits in der Geschichte zurück.
Übernehmen Sie die Änderungen erneut.
-gemischt: Die Option ähnelt dem Parameter soft. Wenn es schlechte Commits gibt, entfernen Sie diese normalerweise und beheben sie später und setzen sie wieder fest. Im Wesentlichen müssen wir den Index mit hinzufügen git hinzufügen und dann Git Commit. Änderungen bleiben im Arbeitsbaum.
Gehen wir zwei Commits im Verlauf zurück und stellen fest, dass die Dateien nicht mehr verfolgt werden.
Fügen Sie nun die Dateien zum Staging hinzu und übernehmen Sie die Änderungen.
-hart: Dieser Parameter ruht bis zu einem Punkt, an dem eine bestimmte Datei vorhanden war. Die Änderungen sind im Arbeitsbaum nicht verfügbar.
Wenn Sie sich das obige Protokoll ansehen, kehren Sie zu dem Punkt zurück, an dem nur Datei 1 festgeschrieben wurde, d. H. Der letzte Eintrag.
Verwenden von Git Reset - hart
Git Bisect
Finden Sie das genaue Commit, das den Code gebrochen hat (wir sind doch alle Menschen). Während des Testens der Anwendung hören wir oft von unseren Testern, dass ein Fehler vorliegt oder die Funktion defekt ist, und Sie als Entwickler werden sagen, dass sie letzte Woche funktioniert hat. Also, was ist passiert und warum ist dieser Fehler aufgetreten?
Manchmal hat sich eine Änderung des anderen Codes auf Ihre Funktion ausgewirkt. Sie müssen Zeit damit verbringen, den Verlauf zu durchlaufen, in dem viele Commits zeitaufwändig und schwer nachzuvollziehen sind, welche Änderung den Code beschädigt hat.
Git Bisect ist der Befehl, um das genaue Commit zu finden, als der Fehler eingeführt wurde. Mit Git bisect müssen Sie zwei Commits auswählen, einen guten und einen schlechten. Etwa auf halbem Weg zwischen beiden Commits wird ausgecheckt. Sie überprüfen jedes Commit entweder schlecht oder gut, bis das Commit gefunden wurde, durch das der Fehler oder Code unterbrochen wurde.
Beispiel:
- Erstellen Sie ein neues lokales Git-Repository und erstellen Sie eine Datei mit dem Namen index.html
- Anfangsinhalt der Datei wie gezeigt.
- Zum Staging hinzufügen und in das Repository übertragen.
- Erstellen Sie wie gezeigt einen Verlauf von Commits, damit wir zwischen guten und schlechten Commits wählen können. Nehmen Sie nun nach Abschluss des ersten Commits die anderen Änderungen wie gezeigt vor und schreiben Sie dasselbe fest. Insgesamt werden wir 7 Commits durchführen.
Zweite Änderung
Dritte Änderung
Vierte Änderung
Fünfte Änderung
Sechste Änderung
Siebte Änderung
Hören wir hier auf. Wir haben also sieben Commits.
Wenn Sie sich die HTML-Seite ansehen, sind die Zeilen nach „Alle 4 Ereignisse…“ falsch und daher ist die Dokumentation nicht korrekt. Wir müssen also das Commit finden, bei dem der Fehler aufgetreten ist, damit wir unseren HEAD auf dieses Commit ausrichten können.
Schauen wir uns das Protokoll an und finden es heraus Schlecht und gutes Commit.
Das letzte Commit ist nicht richtig, daher kann es ein schlechtes Commit sein. Das Commit wurde nach dem dritten Commit eingeführt, damit wir das haben können Dritte Änderung wie das gute begehen.
Der Prozess der Halbierung beginnt mit Git Bisect Start und endet mit Git Bisect Reset.
git bisect schlecht // Da das letzte Commit schlecht ist. Die Commit-ID muss nicht angegeben werden.
git bisect gut
Sie können jetzt sehen, dass HEAD jetzt zwischen der Hälfte des schlechten und des guten Commits liegt.
Sehen Sie sich den Inhalt von index.html an und prüfen Sie, ob ein gutes Commit vorliegt. Wenn nicht, wird der Fehler immer noch nicht gefunden.
Nicht wirklich, dass der Fehler noch besteht. Die letzte Zeile ist falsch. Also laufen wir git bisect bad “. Es gibt immer noch ein schlechtes Commit und der aktuelle Inhalt ist nicht akzeptabel.
Der obige Inhalt ist korrekt und akzeptabel.
Führen Sie 'git log –oneline' und 'git bisect good' aus.
Also, die Fünfte Änderung war das erste schlechte Commit und wirklich so. Der Fehler wurde identifiziert.
Der aktuelle Inhalt sollte in der endgültigen Dokumentation enthalten sein.
Sobald das fehlerhafte Festschreiben erkannt wurde, können Sie den Entwickler informieren, um die Änderungen zu korrigieren, die möglicherweise dazu führen, dass der Kopf auf die vierte Änderung zurückgesetzt wird, die das letzte gute Festschreiben war.
Lauf ' Git Bisect Reset ’, Um den Prozess zu beenden.
Fazit
In diesem praktischen Primer von GitHub haben wir versucht, alles abzudecken, woran ein Entwickler arbeiten müsste, d. H. Unter dem Gesichtspunkt der Versionskontrolle und Nachverfolgung.
In den ersten drei Tutorials der GitHub-Reihe haben wir uns mit Versionskontrollaktivitäten, dem Erstellen von Repositorys, Pull-Anfragen, Zweigen, Codeüberprüfungen, Organisationen und Teams, dem Verzweigen eines Repositorys, Labels, Meilensteinen, Problemen, Projektplatinen, Wikis, Releases und der Integration vertraut gemacht mit Jira und einigen häufig verwendeten Git-Befehlen für Entwickler.
Wir hoffen sehr, dass alle Entwickler diesen praktischen Ansatz für GitHub und die Git-Befehle in ihren Projekten nützlich finden.
=> Lesen Sie die Easy GitHub Training Series durch.
Literatur-Empfehlungen
- GitLab Jira Integration Tutorial
- Unix-Befehle: Grundlegende und erweiterte Unix-Befehle mit Beispielen
- Selen-Integration mit GitHub unter Verwendung von Eclipse
- JIRA- und SVN-Integrations-Tutorial
- Git vs GitHub: Erforschen Sie die Unterschiede anhand von Beispielen
- Cucumber Selenium Tutorial: Integration von Cucumber Java Selenium WebDriver
- GitHub Tutorial für Entwickler | Verwendung von GitHub
- Unix Pipes Tutorial: Pipes in der Unix-Programmierung