Best Practices für GitHub-Repositorys, zum Forken oder Erstellen eines neuen Zweigs

Ich suche nach der Best Practice, Forking vs. Branching auf GitHub. Ich habe dieses Forking vs. Branching in GitHub gelesen, aber es ist nicht relevant.

Unser 5-köpfiges Team arbeitet am selben Repository, und wir möchten Zusammenführungsprobleme, Konflikte oder Regressionen im Code vermeiden. Das Ziel ist, dass die 5 Personen an verschiedenen Teilen des Projekts arbeiten, oft an derselben Datei.

Ich würde gerne wissen, ob sich das lohnt:

• Forken Sie das Projekt, arbeiten Sie und erstellen Sie Pull-Requests, damit jeder den Code einfach überprüfen kann, oder
• Erstellen Sie einen neuen Zweig – arbeiten Sie und führen Sie ihn auf dem Master zusammen, wenn die Arbeit erledigt ist.

Für mich ist die beste Vorgehensweise beim Umgang mit einem Projekt mit mehr als einem Entwickler die Verwendung von gitflow Verzweigungsmodell.

Erstens wird der Master-Zweig jetzt nur noch verwendet, um die Veröffentlichungen Ihrer App, Haupt-, Neben- oder Patch-Versionen nachzuverfolgen Semantische Versionierung.

Der Entwicklungszweig wird der Kern Ihres Projekts sein, da er die Brücke zwischen den verschiedenen Funktionen und Ihren Releases schlägt.

Dieses System hilft, die Anzahl der Zusammenführungen zu reduzieren, genau wie ein einfaches Verzweigungssystem, fügt jedoch die semantische Logik und die damit verbundenen freundlichen und einfachen Befehle hinzu.

Für weitere Informationen zu Gitflow können Sie folgen dieser Link.

Die Wartung von Forks führt zu zusätzlichem Overhead, da jeder Fork Änderungen von Upstream abrufen muss. Ich sehe keinen Vorteil darin, wenn jeder Entwickler Zugriff auf ein gemeinsames Repository haben kann.

Pull-Requests können ein sehr nützlicher Mechanismus für Code-Reviews sein, aber sie verlangen nicht, dass Sie Forks verwenden. Sie können Branches im selben Repository erstellen und Pull-Requests verwenden, um deren Zusammenführung mit Ihrem Master-Branch zu verwalten.

In meinem Büro haben wir eine ähnliche Situation: ein großes Projekt, bei dem fünf oder mehr Entwickler Commit-Zugriff haben und in der Regel mindestens drei gleichzeitig daran arbeiten. Wir verwalten alles über ein einziges Repository mit Verzweigungen und Pull-Anforderungen, und wir hatten keine Probleme (die sowieso durch unsere Einrichtung der Quellcodeverwaltung verursacht wurden).

Pull-Requests sind eine hervorragende Möglichkeit, Code-Reviews von anderen Entwicklern zu erbitten, was besonders wichtig ist, wenn dieselben Entwickler möglicherweise am nächsten Tag mit Ihrem Code arbeiten. Forking hingegen bringt keinen wirklichen Nutzen; Es ist eine Lösung für das Problem, einen breiteren Zugriff auf eine kontrollierte Codebasis zu ermöglichen, und dieses Problem besteht einfach nicht, wenn jeder Commit-Zugriff auf das Repo hat.

Atlassian hat auf seiner Seite mit Git-Tutorials eine hervorragende Beschreibung der Unterschiede zwischen Forking und anderen Git-Workflows. (Sehen Forking-Workflow | Atlassian-Git-Tutorial)

Relevante Zitate:

Der Hauptvorteil des Forking-Workflows besteht darin, dass Beiträge integriert werden können, ohne dass jeder auf ein einziges zentrales Repository pushen muss. Entwickler pushen auf ihre eigenen serverseitigen Repositorys, und nur der Projektbetreuer kann auf das offizielle Repository pushen. Dies ermöglicht es dem Betreuer, Commits von jedem Entwickler zu akzeptieren, ohne ihm Schreibzugriff auf die offizielle Codebasis zu geben.

…

Es ist wichtig zu verstehen, dass der Begriff eines „offiziellen“ Repositorys im Forking-Workflow lediglich eine Konvention ist. Aus technischer Sicht sieht Git keinen Unterschied zwischen dem öffentlichen Repository jedes Entwicklers und dem offiziellen. Tatsächlich ist das einzige, was das offizielle Repository so offiziell macht, dass es das öffentliche Repository des Projektbetreuers ist.

…

Alle diese persönlichen öffentlichen Repositories sind wirklich nur eine bequeme Möglichkeit, Branches mit anderen Entwicklern zu teilen. Jeder sollte immer noch Branches verwenden, um einzelne Features zu isolieren, genau wie im Feature Branch Workflow und im Gitflow Workflow. Der einzige Unterschied besteht darin, wie diese Branches geteilt werden. Im Forking-Workflow werden sie in das lokale Repository eines anderen Entwicklers gezogen, während sie in den Feature Branch- und Gitflow-Workflows in das offizielle Repository gepusht werden.

Ich würde “zentralisiert” arbeiten, d. h. mit einem Haupt-Repo, das jeder forkt, jeder Entwickler würde sich auf sein eigenes Repo festlegen, was den Code-Review-Prozess einfacher macht. Sobald die Codeüberprüfung abgeschlossen ist, können Sie die Änderungen mit dem Hauptrepo zusammenführen.

Das ist nur die Grundidee…

Sie müssten auch die Strategien für die Verzweigung festlegen. ich würde empfehlen Nvie-Modell

Ich habe das Gefühl, dass der Flaschenhals weder eine Gabelung noch eine Verzweigung ist. Bei beiden Ansätzen müssen Sie manuell eingreifen, um die Änderungen zusammenzuführen / zu überprüfen.,

Der Engpass liegt also beim Anwendungsentwicklungsansatz. Ich sehe ein Problem, wenn ein Team an derselben Datei arbeitet. Kann es mit einem geeigneten Architekturdesign in separate Module mit einzelnen Dateien aufgeteilt werden? Zur Laufzeit oder Build-Zeit könnten die separaten Module (oder Dateien) aggregiert werden, um das gesamte Feature (oder eine einzelne Datei) zu bilden.

Wenn wir es auf dieser Ebene lösen könnten, werden die Dinge reibungslos skalieren, sobald die Teamgröße zunimmt oder die Feature-Komplexität zunimmt.