it-swarm.com.de

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

Also habe ich mit einem echten Projekt von mir auf GitHub angefangen und die Dinge laufen ziemlich gut und die Ideen fließen viel schneller als ich ursprünglich dachte. Um die Organisation zu gewährleisten, habe ich einige Zweige eingerichtet, 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 Request und Compare mit dem Namen des Zweigs, zu dem ich kürzlich verschoben habe. Ich verstehe den Zweck der Schaltfläche Compare, verstehe aber nicht, warum ich eine Pull-Anfrage für mein eigenes Repo erstellen möchte.

Kann mir jemand erklären, warum ich das tun würde? Ist es nützlich, eine Pull-Anfrage in meinem eigenen Repo zu stellen, wenn ich der einzige Entwickler bin?

43
marco-fiset

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

Pull-Anfragen können verwendet werden, um Ihren Projektverlauf einfacher zu verfolgen. Eine Pull-Anforderung verfügt über eine Problem-ID, auf die in Festschreibungsnachrichten und in einem Änderungsprotokoll verwiesen werden kann. Auf diese Weise können Sie problemlos zurückgehen und den Zusammenführungspunkt und den Satz zusammengeführter Festschreibungen für eine bestimmte Änderung suchen, ohne Ihre Funktion 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 a hinzu Verweis auf die Pull-Request-ID. Natürlich hat Pioneer mehrere Entwickler, aber der gleiche Mechanismus kann für einen Entwickler nützlich sein, der alleine arbeitet.

Dies ist möglicherweise weniger nützlich, wenn Sie sich für einen linearen Festschreibungsverlauf entscheiden (indem Sie Ihre Feature-Zweige vor dem Zusammenführen neu gründen, damit die Zusammenführung immer als schneller Vorlauf ausgeführt werden kann) und wenn Sie beim Bearbeiten und Quetschen Ihres Verlaufs sehr diszipliniert sind Commits vor dem Zusammenführen zum Master, da in diesem Fall die einzelnen Commit-Nachrichten als Änderungsprotokoll für sich verwendet werden können.

32

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

In deinem Fall bist du jemand.

Als einziger Entwickler sollten Sie Ihre eigene Arbeit noch überprüfen, umgestalten und zusammenführen, um sie zu beherrschen, wenn Sie bereit sind.

Ein Ansatz, den ich häufig benutze, ist der Versuch, einen anderen Hut aufzusetzen und andere Persönlichkeiten auszuprobieren. Setzen Sie sich also für eine kurze Zeit und versetzen Sie sich in die Situation von: Neuling in der Gruppe; Nachwuchsentwickler; Kollege, den Sie in der Vergangenheit respektiert haben usw. Versuchen Sie, es durch ihre Augen zu betrachten und überlegen Sie einfach, was Sie tun können, um die Änderung offensichtlicher zu machen, besser geschrieben mit noch besseren Namen, die Stammes- und Domänenwissen so weit wie möglich vermeiden .

Wie Sie bereits angegeben haben, sollten Sie in Zweigen arbeiten, wenn Sie Funktionen und Änderungen trennen möchten, die nicht für den Master bereit sind. Sie können dies alles in Zweigen tun (Sie benötigen nicht einmal Pull-Anforderungen, um sie zu verwalten, wenn Sie die PR-Aufgaben trotzdem ausführen, aber es kann eine nützliche Struktur für Sie bereitstellen).

Außerdem stelle ich manchmal fest, dass meine Änderung nicht funktioniert, aber anstatt des Schreckens, sie vom Master zurückzuziehen, vielleicht jetzt gemischt mit anderen Master-Änderungen, kann ich alles in einem Zweig tun, den ich dann ignorieren kann/löschen, wenn es schief geht. Dies ist ein großer Vorteil.

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

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

12
Michael Durrant

Es hört sich so an, als hätten Sie sowohl entfernte als auch lokale Niederlassungen. Wenn der Overhead dieses Workflows zu hoch ist, können Sie mithilfe lokaler Zweige immer an verschiedenen Funktionen arbeiten, ohne sie zu verschieben.

Es kommt im Grunde darauf an, das zu tun, was für Sie funktioniert. Die Arbeit mit Zweigen ist ein großer Vorteil für Git, und Github macht das wirklich einfach, aber als Einzelentwickler besteht keine große Notwendigkeit, das Pull-Request-Modell zu verwenden, und die direkte Verpflichtung zum Master sollte gut funktionieren. Wenn Ihr Projekt irgendwann unglaublich erfolgreich wird und Dutzende oder Hunderte von Entwicklern daran arbeiten, ist es eine gute Möglichkeit, Pull-Anfragen von ihren Gabeln zu erhalten, um den Überblick über das Projekt zu behalten.

3
dma

Pull-Anfragen werden normalerweise entweder für Codeüberprüfungen oder für Beiträge von Benutzern mit einem eigenen Projektgabel verwendet - für einen einzelnen Entwickler eines Projekts sehe ich keinen wirklichen Zweck.

0
sevenseacat

Der Grund, warum ich das mache, ist, dass es eine bequeme Möglichkeit ist, sicherzustellen, dass alle automatisierten Prüfungen bestanden werden (es wird kompiliert, es hat die richtige Formatierung, Unit-Tests bestehen ...).

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

Im Allgemeinen ist es 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.

0
Mark