Unterschied zwischen Forking und Branching auf GitHub

In diesem Artikel wird der Unterschied zwischen Forking und Branching auf GitHub erläutert. Im Kontext der Codierung ist die aktuelle Ära stärker auf Zusammenarbeit angewiesen.

Eines der am häufigsten verwendeten Collaboration-Tools ist GitHub. Forking und Branching auf GitHub sind einige der nützlichsten Dienstprogramme bei der Zusammenarbeit an Projekten.

Die beiden haben jedoch unterschiedliche Anwendungsfälle und Auswirkungen, wie unten erläutert.

Unterschied zwischen Forking und Branching auf GitHub

Forking auf GitHub beinhaltet das Erstellen einer Kopie eines öffentlichen Repositorys in Ihrem persönlichen Konto. Dieses Konzept fördert die divergente Entwicklung einer Codebasis.

Divergente Evolution ist ideal für diejenigen, die umfassend mit einem Thema experimentieren möchten.

Auf der anderen Seite beinhaltet das Verzweigen das Erstellen einer Verzweigung vom Ursprung. Es fördert die konvergente Entwicklung einer Codebasis.

Die meisten Unternehmen bevorzugen Verzweigungen, da sie sich positiv auf die Produktivität eines Teams auswirken.

Divergente vs. konvergente Evolution

Sie haben wahrscheinlich bemerkt, dass in der Open-Source-Welt eine Codebasis gleichzeitig in zwei Projekte aufgeteilt werden kann. Nehmen Sie das Beispiel der Linux-Codebasis.

Wir haben jetzt mehrere Forks, wie Linux RedHat, aber alle haben eine gemeinsame Abstammung. Dies ist ein Beispiel für die divergierende Entwicklung einer Codebasis.

Es ist erwähnenswert, dass diese Iterationen keine temporären Entwicklungspfade sind und sich niemals ineinander integrieren lassen.

Andererseits sind Verzweigungen temporäre Entwicklungspfade. Zweige sind kurzlebig, da sie erledigt sind, wenn der Code mit dem master-Zweig zusammengeführt wird.

Aus diesem Grund fördern sie die konvergente Entwicklung einer Codebasis.

Forking erstellt ein neues Repository

GitHub macht es einfach, mit nur einem Knopfdruck zu forken. Diese Aktion erstellt ein Duplikat des Repositorys bis zum Zeitpunkt des Forkings.

Wann ist es ideal zu forken?

Dies ist der Fall, wenn Sie ein unabhängiges Projekt erstellen möchten, ohne die Absicht zu haben, es mit seinem übergeordneten Projekt wieder zu vereinen.

Möglicherweise stoßen Sie auf GitHub auf ein Projekt, das ein guter Ausgangspunkt für Ihr Projekt ist. An einem solchen Punkt ist das Forken ideal.

Verzweigung auf GitHub

Zweige spielen die Rolle von Bauzonen in einer Codebasis. Wir verwenden Verzweigungen vorübergehend, um an Features zu arbeiten, mit der Absicht, sie mit dem Ursprung zu verschmelzen.

Um einen Branch auf GitHub zu erstellen, gehen Sie zu Alle Branches anzeigen und klicken Sie auf Neuer Branch.

Um lokal einen neuen Branch zu erstellen, verwenden wir den Befehl git checkout, wie unten dargestellt.

$ git checkout -b <new branch>

Was kostet Forking und Branching?

Es ist einfacher und schneller, einen Zweig zusammenzuführen, da Git nur die geänderten Dateien vergleicht. Auf der anderen Seite kann Forking als teurer angesehen werden.

Wenn ein Fork mit seinem ursprünglichen Elternteil zusammengeführt wird, muss Git zwei Repositories vergleichen. Denken Sie daran, dass Forking ein Duplikat des gesamten übergeordneten Repositorys erstellt.

Die Dateigröße Ihres neuen Zweigs variiert je nach übergeordnetem Zweig. Forks nehmen mehr Platz auf Ihrem Remote-Server ein.

Die Verzweigung wird für ein Unternehmen empfohlen, da es mehr Transparenz und ein geringeres Betriebsrisiko gibt.

Hier ist der Grund:

Nehmen wir an, wir haben ein zehnköpfiges Team, das an einem anderen Feature im Projekt arbeitet. Wenn jeder Entwickler einen Fork erstellt, haben wir zehn verschiedene und unabhängige Repositories.

Dadurch wird es schwierig zu sehen, woran alle arbeiten, es sei denn, Sie haben alle zehn Repos an einem Ort.

Dies ist keine echte Kollaborationsumgebung, da Codeänderungen in zehn verschiedenen Repos vorhanden sind.

Wenn sich die Entwickler für zehn verschiedene Zweige entscheiden würden, anstatt sich zu verzweigen, wäre es eher ein kollaborativer Raum, da sich alle Commits in einem Repository befinden. Dieses Argument geht auf die Frage der Sichtbarkeit ein.

Wenn wir von operationellen Risiken sprechen, nehmen Sie dieses Beispiel: Entwickler haben zehn Forks erstellt, und ein oder zwei sind aus irgendeinem Grund nicht verfügbar. Dies bringt das Risiko des Wissensmanagements mit sich, bei dem andere Entwickler nicht wissen, wo der andere Entwickler angekommen ist.

Dies ist nicht immer der Fall, aber es ist immer noch ein Risiko, das durch einen branchenzentrierten Workflow vermieden werden kann.

Ein branchenzentrierter Workflow eignet sich am besten für eine Geschäftsumgebung, während Forking am besten für die öffentliche Zusammenarbeit und Experimente geeignet ist. Wenn Sie alle auf ein Ziel hinarbeiten, entscheiden Sie sich für einen branchenzentrierten Workflow.