Forking vs. Branching in GitHub

Question

Ich würde gerne mehr über die Vor- und Nachteile des Forkens eines Github-Projekts im Vergleich zur Erstellung eines Zweigs eines Github-Projekts erfahren.

Durch das Forken ist meine Version des Projekts isolierter vom Original, da ich nicht auf der Liste der Mitarbeiter des Originalprojekts stehen muss. Da wir ein Projekt im Haus entwickeln, ist es kein Problem, Leute als Mitarbeiter hinzuzufügen. Aber wir würden gerne verstehen, ob das Forking eines Projekts das Zurückführen von Änderungen in das Hauptprojekt erschweren würde. Das heißt, ich frage mich, ob es durch die Verzweigung einfacher wird, die beiden Projekte auf dem gleichen Stand zu halten. Mit anderen Worten, ist es einfacher, Änderungen zwischen meiner Version des Hauptprojekts und dem Hauptprojekt zusammenzuführen und zu übertragen, wenn ich mich verzweige?

Answer 1

Sie können nicht immer eine Verzweigung erstellen oder eine bestehende Verzweigung ziehen und zu dieser zurückschieben, da Sie nicht als Mitwirkender für dieses spezielle Projekt registriert sind.

Forking ist nichts anderes als ein Klon auf der GitHub-Server-Seite :

• ohne die Möglichkeit, direkt zurückzuschlagen
• mit Gabelschlange Funktion zur Verwaltung der Zusammenführungsanfragen hinzugefügt

Sie halten eine Abspaltung mit dem ursprünglichen Projekt synchron, indem Sie:

• Hinzufügen des Originalprojekts als Remote-Projekt
• regelmäßige Abrufe aus dem ursprünglichen Projekt
• stellen Sie Ihre aktuelle Entwicklung auf den Zweig um, den Sie durch das Fetch aktualisiert haben.

Mit der Rebase können Sie sicherstellen, dass Ihre Änderungen unkompliziert sind (keine Merge-Konflikte), was Ihre Pulling-Anfrage erleichtert, wenn Sie möchten, dass der Betreuer des ursprünglichen Projekts Ihre Patches in sein Projekt aufnimmt.

Das Ziel ist es, die Zusammenarbeit zu ermöglichen, auch wenn direkt Die Teilnahme ist nicht immer möglich.

---

Die Tatsache, dass Sie auf der GitHub-Seite klonen, bedeutet, dass Sie jetzt zwei "zentrales" Repository ("zentral" im Sinne von "von mehreren Mitarbeitern sichtbar").
Wenn Sie sie direkt als Mitwirkende hinzufügen können für eine Projekt haben, brauchen Sie kein weiteres mit einer Gabel zu verwalten.

Die Merge-Erfahrung wäre in etwa die gleiche, aber mit einer zusätzlichen Ebene der Umleitung (zuerst auf dem Fork pushen, dann nach einem Pull fragen, mit dem Risiko, dass Entwicklungen auf dem ursprünglichen Repo Ihre Fast-Forward-Merges nicht mehr Fast-Forward machen).
Das bedeutet, dass der korrekte Arbeitsablauf wie folgt aussieht git pull --rebase upstream (Ihre Arbeit auf neue Übertragungen von Upstream umstellen), und dann git push --force origin um die Historie so umzuschreiben, dass Ihre eigenen Commits immer über den Commits aus dem ursprünglichen (Upstream-)Repo stehen.

Siehe auch:

• Ist Git fork ein Git-Klon?
• Neue Updates aus dem ursprünglichen Github-Repository in das geforkte Github-Repository ziehen

Answer 2

Hier sind die wichtigsten Unterschiede:

Forking

Profis

• Hält die Zweige nach Benutzer getrennt
• Reduziert das Durcheinander im primären Repository
• Ihr Teamprozess spiegelt den Prozess des externen Mitarbeiters wider

Nachteile

• Es ist schwieriger, alle aktiven (oder inaktiven) Zweige zu sehen.
• Die Zusammenarbeit an einem Zweig ist schwieriger (der Eigentümer des Zweigs muss die Person als Mitarbeiter hinzufügen)
• Sie müssen das Konzept mehrerer Remotes in Git verstehen
  • Erfordert zusätzliche geistige Buchführung
  • Dies erschwert den Arbeitsablauf für Leute, die sich mit Git nicht so gut auskennen.

Verzweigung

Profis

• Hält alle Arbeiten rund um ein Projekt an einem Ort fest
• Alle Beteiligten können in denselben Zweig wechseln, um daran mitzuarbeiten.
• Es gibt nur eine Git-Remote, mit der man umgehen muss

Nachteile

• Zweige, die aufgegeben werden, können sich leichter anhäufen
• Ihr Teambeitragsverfahren entspricht nicht dem Verfahren für externe Mitarbeiter
• Sie müssen Teammitglieder als Mitwirkende hinzufügen, bevor sie verzweigen können

Answer 3

Es hat mit dem allgemeinen Arbeitsablauf von Git zu tun. Es ist unwahrscheinlich, dass Sie direkt in das Repository des Hauptprojekts pushen können. Ich bin mir nicht sicher, ob das GitHub-Projekt-Repository eine verzweigungsbasierte Zugriffskontrolle unterstützt, da Sie niemandem die Berechtigung erteilen möchten, z. B. in den Master-Zweig zu pushen.

Das allgemeine Muster ist wie folgt:

• Forken Sie das Repository des Originalprojekts, um Ihre eigene GitHub-Kopie zu erhalten, in die Sie dann Änderungen einbringen können.
• Klonen Sie Ihr GitHub-Repository auf Ihren lokalen Rechner
• Optional können Sie das ursprüngliche Repository als zusätzliches Remote-Repository zu Ihrem lokalen Repository hinzufügen. Dann können Sie die in diesem Repository veröffentlichten Änderungen direkt abrufen.
• Nehmen Sie Ihre Änderungen und Ihre eigenen Übertragungen lokal vor.
• Übertragen Sie Ihre Änderungen in Ihr GitHub-Repository (da Sie in der Regel keine direkten Schreibrechte für das Projekt-Repository haben).
• Wenden Sie sich an die Betreuer des Projekts und bitten Sie sie, Ihre Änderungen zu holen und zu überprüfen/zusammenzuführen und lassen Sie sie in das Repository des Projekts zurückschieben (wenn Sie und sie das wollen).

Ohne dies ist es für öffentliche Projekte ziemlich ungewöhnlich, dass jeder seine eigenen Commits direkt pushen kann.

Answer 4

Forking erstellt ein völlig neues Repository aus einem bestehenden Repository (einfach ein git clone auf gitHub/bitbucket)

Gabelungen werden am besten verwendet, wenn die Absicht der "Aufteilung" darin besteht, ein logisch unabhängiges Projekt zu schaffen, das möglicherweise nie wieder mit dem übergeordneten Projekt zusammengeführt wird.

Die Verzweigungsstrategie erstellt einen neuen Zweig über dem bestehenden/arbeitenden Repository.

Zweige werden am besten verwendet, wenn sie als temporäre Orte für die Arbeit an einer Funktion erstellt werden, mit der Absicht, den Zweig mit dem Ursprung zusammenzuführen.

Spezifischer :- Bei Open-Source-Projekten entscheidet der Eigentümer des Repositorys, wer in das Repository pushen darf. Die Idee von Open Source ist jedoch, dass jeder zu dem Projekt beitragen kann.

Dieses Problem wird durch Forks gelöst: Jedes Mal, wenn ein Entwickler etwas in einem Open-Source-Projekt ändern möchte, klont er nicht direkt das offizielle Repository. Stattdessen forken sie es, um eine Kopie zu erstellen. Wenn die Arbeit abgeschlossen ist, stellen sie eine Anfrage, damit der Eigentümer des Projektarchivs die Änderungen prüfen und entscheiden kann, ob er sie in sein Projekt einfügen möchte.

Im Kern ähnelt Forking dem Feature-Branching, aber anstatt Zweige zu erstellen, wird ein Fork des Repositorys gemacht, und anstatt einen Merge Request zu machen, erstellt man einen Pull Request.

Die nachstehenden Links erläutern den Unterschied auf anschauliche Weise:

https://blog.gitprime.com/the-definitive-guide-to-forks-and-branches-in-git/

https://buddy.works/blog/5-types-of-git-workflows

http://www.continuousagile.com/unblock/branching.html