Komponenten des GitHub-Ablaufs

  • 8 Minuten

In dieser Lerneinheit stellen wir die folgenden Komponenten des GitHub-Ablaufs vor:

  • Branches
  • Commits
  • Pull Requests
  • Der GitHub-Flow

Was sind Branches?

Im letzten Abschnitt haben wir eine neue Datei und eine neue Verzweigung in Ihren Repositorys erstellt.

Branches sind ein wesentlicher Bestandteil von GitHub, da wir dort Änderungen vornehmen können, ohne dass diese sich auf das gesamte Projekt auswirken, an dem wir arbeiten.

Ihr Branch ist ein sicherer Ort, um mit neuen Features oder Fixes zu experimentieren. Wenn Sie einen Fehler machen, können Sie Ihre Änderungen rückgängig machen oder weitere Änderungen pushen, um den Fehler zu beheben. Ihre Änderungen wirken sich erst auf den Standardbranch aus, wenn Sie Ihren Branch mergen.

Hinweis

Alternativ können Sie einen neuen Branch erstellen und mithilfe von Git in einem Terminal auschecken. Der Befehl hierfür wäre git checkout -b newBranchName.

Was sind Commits?

In der vorherigen Lerneinheit haben Sie dem Repository mit einem Commit eine neue Datei hinzugefügt. Gehen wir kurz darauf ein, was Commits sind.

Ein Commit ist eine Änderung an einer oder mehreren Dateien in einem Branch. Jedem neu erstellten Commit wird eine eindeutige ID zugewiesen und er wird mit Uhrzeit und dem Mitwirkenden nachverfolgt. Commits schaffen einen Überwachungspfad, damit der Verlauf einer Datei oder eines verknüpften Elements, wie ein Issue oder Pull Request, eindeutig überprüft und nachverfolgt werden kann.

Screenshot: Liste von GitHub-Commits auf einen Mainbranch.

Innerhalb eines Git-Repositorys kann eine Datei in mehreren gültigen Zuständen vorhanden sein, während sie den Versionskontrollprozess durchläuft. Die primären Zustände für eine Datei in einem Git-Repository sind Untracked (Nicht nachverfolgt) und Tracked (Nachverfolgt).

Untracked (nicht nachverfolgt): Der Ausgangszustand einer Datei, wenn sie noch nicht Teil des Git-Repositorys ist. Git ist sich ihrer Existenz nicht bewusst.

Tracked (nachverfolgt): Eine nachverfolgte Datei ist eine Datei, die Git aktiv überwacht. Sie kann einen der folgenden Unterzustände aufweisen:

  • Unmodified (nicht geändert): Die Datei wird nachverfolgt, wurde aber seit dem letzten Commit nicht geändert.
  • Modified (geändert): Die Datei wurde seit dem letzten Commit geändert, aber diese Änderungen werden noch nicht für den nächsten Commit gestaget.
  • Staged (gestaget): Die Datei wurde geändert, und die Änderungen wurden dem Stagingbereich (auch als Index bezeichnet) hinzugefügt. Diese Änderungen können committet werden.
  • Committed (committet): Die Datei befindet sich in der Datenbank des Repositorys. Sie stellt die zuletzt committete Version der Datei dar.

Diese Zustände und Unterzustände sind wichtig für die Zusammenarbeit mit Ihrem Team, damit alle wissen, wo sich jeder Commit im Prozess Ihres Projekts befindet. Befassen wir uns nun mit Pull Requests.

Was sind Pull Requests?

Ein Pull Request signalisiert, dass die Commits aus einem Branch mit einem anderen Branch zusammengeführt werden können.

Das Teammitglied, das den Pull Request übermittelt, bittet mindestens einen Reviewer darum, den Code zu kontrollieren und den Merge zu genehmigen. Die Reviewer können dann Änderungen kommentieren, eigene Änderungen hinzufügen oder selbst mithilfe eines Pull Requests weitere Diskussionen anregen.

Nachdem die Änderungen genehmigt wurde (sofern eine Genehmigung erforderlich ist), wird der Quellbranch des Pull Requests (der Vergleichsbranch) mit dem Basisbranch gemergt.

Screenshot: Pull Request und ein Kommentar innerhalb der Pull Request.

Nachdem Sie nun alle Komponenten gehen, fassen wir den GitHub-Ablauf noch einmal zusammen.

Der GitHub-Flow

Screenshot: visuelle Darstellung des GitHub-Ablaufs in einem linearen Format mit einer neuen Verzweigung, Commits, Pull Request und Zusammenführen der Änderungen zurück zum Mainbranch, in dieser Reihenfolge.

Der GitHub-Ablauf kann als einfacher Workflow definiert werden, der sichere Experimente ermöglicht. Sie können neue Ideen testen und mit Ihrem Team zusammenarbeiten, indem Sie Branches, Pull Requests und Merges verwenden.

Nachdem wir nun die Grundlagen von GitHub kennen, können wir den GitHub-Ablauf und seine Komponenten durchgehen.

  1. Erstellen Sie zunächst einen Branch, damit sich die von Ihnen erstellten Änderungen, Features und Korrekturen nicht auf den Mainbranch auswirken.
  2. Nehmen Sie danach Ihre Änderungen vor. Es wird empfohlen, Änderungen im Featurebranch bereitzustellen, bevor sie mit dem Mainbranch gemergt werden. Dadurch wird sichergestellt, dass die Änderungen in einer Produktionsumgebung gültig sind.
  3. Erstellen Sie nun einen Pull Request, um Ihre Kollegen um Feedback zu bitten. Die Überprüfung von Pull Requests ist so wichtig, dass in einigen Repositorys ein Review zur Genehmigung erforderlich ist, bevor Pull Requests gemergt werden können.
  4. Überprüfen und implementieren Sie danach das Feedback von Ihren Kollegen.
  5. Wenn Sie mit Ihren Änderungen zufrieden sind, können Sie die Genehmigung Ihres Pull Requests und sein Mergen mit dem Mainbranch anfordern.
  6. Zum Schluss können Sie Ihren Branch löschen. Das Löschen Ihres Branches signalisiert, dass Ihre Arbeit am Branch abgeschlossen ist, und verhindert, dass Sie oder andere versehentlich alte Branches verwenden.

Damit haben Sie erfolgreich einen GitHub-Flow durchlaufen.

Lassen Sie uns mit dem nächsten Abschnitt fortfahren, in dem die Unterschiede zwischen Issues und Diskussionen behandelt werden.