Komponenten des GitHub-Ablaufs

  • 8 Minuten

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

  • Zweige
  • Commits
  • Pullanforderungen
  • Der GitHub-Flow
  • Git-Fluss

Komponenten von GitHub Flow

Bevor wir auf GitHub-spezifische Workflows eingehen, ist es hilfreich zu verstehen, dass GitHub Flow direkt auf den grundlegenden Konzepten von Git basiert.

Git bietet Tools zum Nachverfolgen und Verwalten von Änderungen in Ihrem Code im Laufe der Zeit. GitHub baut darauf auf, indem es die Verwendung dieser Tools mit Features wie Verzweigungen, Commits, Pullanforderungen und visuellen Schnittstellen für die Zusammenarbeit erleichtert. Sehen wir uns zunächst an, wie diese Konzepte in GitHub funktionieren.

Was sind Branches?

Im letzten Abschnitt haben wir eine neue Datei und eine neue Verzweigung in Ihrem Repository erstellt.

Verzweigungen sind ein wesentlicher Bestandteil der GitHub-Erfahrung. Sie ermöglichen es Ihnen, Änderungen vorzunehmen, ohne dass sich dies auf die Standardverzweigung auswirkt.

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. Jeder Commit wird von einer eindeutigen ID, einem Zeitstempel und einem Mitwirkenden nachverfolgt, unabhängig davon, ob er über die Befehlszeile oder direkt auf der Webschnittstelle von GitHub erfolgt. Commits schaffen einen Überwachungspfad, damit der Verlauf einer Datei oder eines verknüpften Elements (z. B. ein Issue oder Pull Request) eindeutig überprüft und nachverfolgt werden kann.

Sie können einen Commit mit Git in Ihrem Terminal erstellen mit:

git commit -m "Add a helpful commit message"

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: Die Datei wurde seit dem letzten Commit geändert, aber diese Änderungen sind noch nicht für den nächsten Commit vorbereitet.
  • Staged: Die Datei wurde geändert, und die Änderungen wurden dem Staging-Bereich (auch als Index bezeichnet) hinzugefügt. Diese Änderungen sind bereit, übernommen zu werden.
  • Committed: Die Datei befindet sich in der Datenbank des Repositories. Sie stellt die zuletzt committete Version der Datei dar.

Diese Zustände helfen Ihrem Team, den Status jeder Datei zu verstehen und wo sie sich im Versionssteuerungsprozess befindet.

Was sind Pull Requests?

Ein Pull Request ist der Mechanismus, der signalisiert, dass die Commits aus einem Branch bereit sind, in einen anderen Branch zusammengeführt zu werden.

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.

GitHub unterstützt auch Entwurfs-Pullanforderungen, mit denen Sie eine Pullanforderung öffnen können, die noch nicht zur Überprüfung bereit ist.

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

Ein Screenshot einer Pull-Anfrage und eines Kommentars innerhalb der Pull-Anfrage.

Nachdem Sie nun gesehen haben, wie Verzweigungen, Commits und Pullanforderungen funktionieren, sehen wir uns an, wie sie in GitHub Flow zusammenkommen.

Der GitHub-Flow

Screenshot einer visuellen Darstellung des GitHub-Flusses in einem linearen Format, das eine neue Verzweigung enthält, Commits, Pullanforderung und Zusammenführen der Änderungen zurück zum Hauptbereich in dieser Reihenfolge.

Der GitHub-Fluss ist ein einfacher Workflow, der Ihnen hilft, Änderungen sicher vorzunehmen und freizugeben. Es eignet sich hervorragend für das Ausprobieren von Ideen und die Zusammenarbeit mit Ihrem Team mithilfe von Filialen, Pullanforderungen und Zusammenführungen.

Hinweis

GitHub-Fluss ist einer von mehreren beliebten Workflows. Andere umfassen Git-Fluss und trunkbasierte Entwicklung.

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

  1. Erstellen Sie zunächst eine Verzweigung, sodass sich Ihre Änderungen, Features oder Korrekturen nicht auf die Hauptzweige auswirken.
  2. Als Nächstes nehmen Sie Ihre Aktualisierungen in der Verzweigung vor. Wenn Ihr Workflow dies unterstützt, können Sie Änderungen aus dieser Verzweigung bereitstellen, um sie vor dem Zusammenführen zu testen.
  3. Öffnen Sie nun eine Pull-Anforderung, um Feedback einzuladen und eine Überprüfung zu beginnen.
  4. Überprüfen Sie dann die Kommentare, und nehmen Sie alle erforderlichen Updates basierend auf dem Feedback Ihres Teams vor.
  5. Nachdem Sie sich auf Ihre Änderungen verlassen haben, erhalten Sie die Genehmigung, und führen Sie die Pullanforderung in der Hauptverzweigung zusammen.
  6. Löschen Sie danach die Verzweigung, um Ihr Repository sauber zu halten und die Verwendung veralteter Verzweigungen zu vermeiden.

Git-Fluss

Diagramm, das den Git-Flussworkflow mit parallelen Lanes für Feature-Verzweigungen, Entwicklung, Release branches, Hotfixes und Master veranschaulicht. Es zeigt, wie Features in entwicklung zusammengeführt werden, Release-Branches aus der Entwicklung erstellt werden, Hotfixes werden von Master verzweigt, und alle Änderungen werden schließlich wieder mit Master zusammengeführt und mit markierten Versionen entwickelt.

Während GitHub Flow ein einfacher Workflow ist, der für die kontinuierliche Bereitstellung entwickelt wurde, ist Git Flow ein strukturiertes Verzweigungsmodell, das häufig in releasegesteuerten Umgebungen verwendet wird. Der Git-Fluss ist länger als GitHub Flow, und möglicherweise wird der begriff master weiterhin anstelle der main Standardverzweigung verwendet.

Git Flow Branch-Typen

Git-Fluss verwendet mehrere langlebige und temporäre Verzweigungen:

  • master: Spiegelt immer produktionsfertigen Code wider.
  • develop: Enthält die neueste Entwicklungsarbeit für die nächste Version.
  • feature/*: Wird verwendet, um neue Features zu erstellen; verzweigt von develop und zusammengeführt, wenn sie abgeschlossen ist.
  • release/*: Bereitet eine neue Produktionsversion von develop; ermöglicht endgültige Tests und kleinere Fehlerbehebungen.
  • Hotfix/*: Wird verwendet, um Produktionsprobleme schnell zu patchen; verzweigt von master.

Funktionsweise des Git-Flussprozesses

  1. Entwickler erstellen Feature-Verzweigungen aus develop , um neue Funktionen zu erstellen.
  2. Wenn es zeit für eine Version ist, wird eine Release-Verzweigung aus developerstellt. Dadurch wird die Veröffentlichungsvorbereitung isoliert, sodass die Entwicklung unterbrechungsfrei fortgesetzt werden kann.
  3. Fehlerkorrekturen können dem Release Branch hinzugefügt werden, aber wichtige Features sollten auf eine zukünftige Version warten.
  4. Sobald sie fertig sind, wird die Release-Verzweigung mit einer Versionsnummer zusammengeführt master und mit dieser gekennzeichnet. GitHub kann diese Tags verwenden, um Sie beim Generieren von Versionshinweisen zu unterstützen.
  5. Derselbe Release-Verzweigung sollte wieder develop zusammengeführt werden, um ihn synchron zu halten.
  6. Wenn ein kritischer Produktionsfehler auftritt, wird eine Hotfix-Verzweigung erstellt.master Nach der Behebung wird sie in beide master und develop.

Verwendung des Git-Flusses

  • Am besten geeignet für Projekte mit geplanten oder versionsierten Versionen
  • Hilfreich, wenn Sie mehrere Produktionsversionen verwalten (z. B. langfristige Support-Filialen)
  • Ideal für langsamere, strukturiertere Entwicklungszyklen (z. B. Unternehmens- oder regulierte Umgebungen)
  • Betrachtet als "schwergewichtiger" als GitHub Flow aufgrund zusätzlicher Verzweigungsverwaltung

Hinweis

Git flow geht davon aus, dass Zusammenführungs-Commits für die Integration von Verzweigungen ausgeführt werden. Die Verwendung von Rebase- oder Merge-Zusammenführungen kann die Verzweigungsstruktur und verlaufsnachverfolgung beeinträchtigen.

Für viele Teams, die GitHub verwenden, ist GitHub Flow einfacher und schneller. Wenn Ihr Team jedoch die Vorhersagbarkeit wertet und eine bessere Veröffentlichungsplanung benötigt, ist git flow möglicherweise besser geeignet.

Glückwunsch! Sie haben gerade den vollständigen GitHub Flow durchlaufen und untersucht, wie Git Flow eine strukturierte Alternative für releasegesteuerte Projekte bietet.

Lassen Sie uns mit dem nächsten Abschnitt fortfahren, in dem wir die Unterschiede zwischen Problemen und Diskussionen behandeln.