Gibt es einen Grund, Pull-Anfragen für mein eigenes Repo zu verwenden, wenn ich der einzige Entwickler bin?

Also habe ich ein echtes Projekt von mir auf GitHub gestartet und die Dinge laufen ziemlich gut und die Ideen fließen viel schneller, als ich ursprünglich gedacht hatte. Um die Dinge zu organisieren, richte ich einige Zweige ein, damit ich verschiedene Funktionen separat entwickeln kann.

Wenn ich jetzt meinen Zweig zu GitHub schiebe, habe ich diesen Abschnitt, in dem ich zwei Schaltflächen habe: Pull Requestund Comparemit dem Namen des Zweigs, zu dem ich kürzlich geschoben habe. Ich verstehe den Zweck des CompareButtons, verstehe aber nicht, warum ich eine Pull-Anfrage für mein eigenes Repo erstellen möchte.

Kann mir jemand erklären, warum ich das machen würde? Ist es nützlich, eine Pull-Anfrage für mein eigenes Repo zu stellen, wenn ich der einzige Entwickler bin?

Für viele (vielleicht die meisten) Einzelentwickler, die alleine arbeiten, lohnt es sich wahrscheinlich nicht, Pull-Requests zu erstellen. Ich kann mir jedoch mindestens einen möglichen Grund dafür vorstellen:

Pull-Anforderungen können verwendet werden, um den Verlauf Ihres Projekts einfacher zu verfolgen. Eine Pull-Anforderung verfügt über eine Issue-ID, auf die in Commit-Nachrichten und in einem Änderungsprotokoll verwiesen werden kann. Auf diese Weise können Sie den Zusammenführungspunkt und den Satz zusammengeführter Commits für eine bestimmte Änderung problemlos suchen, ohne Ihr Feature beibehalten zu müssen Zweige auf unbestimmte Zeit.

Wenn wir beispielsweise in Pioneer (schamloser Plug) eine Pull-Anforderung zusammenführen, fügen wir dem Changelog ein Element mit einer einzeiligen Beschreibung der Änderung und einem Verweis auf die ID der Pull-Anforderung hinzu. Natürlich hat Pioneer mehrere Entwickler, aber der gleiche Mechanismus könnte für einen Entwickler nützlich sein, der alleine arbeitet.

Dies ist möglicherweise weniger nützlich, wenn Sie sich für ein lineares Festschreibungsprotokoll entscheiden (indem Sie Ihre Feature-Zweige vor dem Zusammenführen neu basieren, sodass das Zusammenführen immer als schneller Vorlauf ausgeführt werden kann) und wenn Sie sehr diszipliniert sind, Ihre zu bearbeiten und zu komprimieren Commits vor dem Zusammenführen zum Master, da in diesem Fall die einzelnen Commit-Nachrichten als eigenständiges Changelog verwendet werden können.

Pull-Anforderungen werden erstellt, damit jemand die Arbeit überprüfen, Kommentare, Vorschläge machen, Änderungen vornehmen oder anfordern und dann den Code zum Master zusammenführen kann.

In deinem Fall bist der Jemand du.

Als einziger Entwickler sollten Sie Ihre eigene Arbeit noch einmal überprüfen, überarbeiten und zusammenführen, um sie zu meistern, wenn Sie fertig sind.

Ein Ansatz, den ich oft benutze, ist zu versuchen, einen anderen Hut aufzusetzen, andere Personen auszuprobieren. Setzen Sie sich also für eine kurze Zeit hin und versetzen Sie sich in die Situation: Neuling in der Gruppe; Junior Entwickler; Kollege, den Sie in der Vergangenheit respektiert haben, usw. Schauen Sie es sich durch die Augen an und überlegen Sie, was Sie tun können, um die Änderung offensichtlicher zu machen .

Wie Sie angegeben haben, sollten Sie in Zweigen arbeiten, wenn Sie Features und Änderungen herausfiltern möchten, die nicht für den Master bereit sind. All das können Sie in Filialen erledigen (Sie brauchen nicht einmal Pull-Anfragen, um sie zu verwalten, wenn Sie die PR-Aufgaben trotzdem erledigen, aber es kann eine nützliche Struktur für Sie darstellen).

Manchmal stelle ich auch fest, dass meine Änderung nicht funktioniert, aber anstatt zu schrecken, dass ich versucht habe, sie vom Master zurückzusetzen, kann ich alles in einem Zweig tun, den ich dann ignorieren kann / delete wenn es schief geht. Das ist ein großer Vorteil.

Sie sollten also in Zweigen arbeiten und sich nicht direkt zum Master verpflichten, bis Sie sich entschließen, den gesamten Zweig zusammenzuführen.

Dies sind Richtlinien - und keine Regeln -, die befolgt werden müssen. Ich breche sie absichtlich manchmal. Zum Beispiel habe ich gestern einen Tippfehler behoben, um zu meistern.

Es hört sich so an, als ob Sie sowohl Zweigstellen in der Ferne als auch in der Region haben. Wenn Sie den Overhead dieses Workflows zu sehr bemerken, können Sie immer mit lokalen Zweigen an verschiedenen Features arbeiten, ohne diese zu verschieben.

Im Grunde kommt es darauf an, das zu tun, was für Sie funktioniert. Das Arbeiten mit Zweigen ist ein großer Vorteil für Git, und Github macht das wirklich einfach, aber als Einzelentwickler ist es nicht unbedingt erforderlich, das Pull-Request-Modell zu verwenden und sich direkt beim Master zu engagieren, sollte gut funktionieren. Wenn Ihr Projekt irgendwann unglaublich erfolgreich wird und Dutzende oder Hunderte von Entwicklern daran arbeiten, ist es eine gute Möglichkeit, den Überblick über das Projekt zu behalten, wenn Sie Pull-Anfragen von ihren Gabeln erhalten.

Pull-Anfragen werden normalerweise entweder für Code-Überprüfungen oder für Beiträge von Benutzern verwendet, die über einen eigenen Zweig des Projekts verfügen - für einen einzelnen Entwickler eines Projekts sehe ich keinen wirklichen Zweck.

Der Grund, warum ich das mache, ist, dass es ein bequemer Weg ist, um sicherzustellen, dass alle automatisierten Prüfungen bestanden werden (es wird kompiliert, es hat die richtige Formatierung, Unit-Tests bestanden ...).

Ich muss nicht unbedingt alle Prüfungen für jede Festschreibung bestehen, aber ich möchte, dass der Leiter der Hauptniederlassung immer die Prüfungen besteht. Ich denke, Pull-Anfragen sind der einfache Weg (vielleicht nicht der einzige).

Im Allgemeinen ist dies eine Möglichkeit, Hooks zu verbinden, um Änderungen abzuschließen. Tests sind ein Beispiel; @ John erwähnte das Erstellen von Versionshinweisen als ein weiteres Beispiel.

Pull-Anfragen im Vergleich zu Git-Push hängen letztendlich von der individuellen oder gemeinsamen Geschichte ab. Das Haupt-Repository ist die Quelle für alle Änderungen. Wenn andere Benutzer lokale Änderungen abrufen und möglicherweise lokale Änderungen vornehmen, kann eine Push-Anforderung dazu führen, dass diese Benutzer Probleme in der Struktur haben, aus der sie Änderungen ableiten.

Das Pull-Anforderungsmodell (entweder aus benutzerdefinierten Zweigen oder aus persönlichen Repositorys) dient als Möglichkeit, einen konsistenten Verlauf für alle Benutzer bereitzustellen, die den Code verwenden und von diesem ableiten.

Ein Grund, warum Sie Code auf github setzen, besteht darin, den Code zum Gabeln verfügbar zu machen und Anforderungen abzurufen. Sie haben nie gewusst, wann es passieren wird, und es wäre ein großes Plus, die Historie Ihrer Mitentwickler konsistent zu halten.