Ich benutze GitHub schon seit einiger Zeit und habe normalerweise meine Feature-Zweige verschoben und dann eine Pull-Anfrage gestartet, die ich selbst zusammengeführt habe. Ich fand, dass es mir half, den Überblick darüber zu behalten, wo ich Zweige zusammengeführt habe.
Aber in letzter Zeit habe ich immer mehr darüber gelesen, wie Git funktioniert, und mir wurde klar, dass ich die Zusammenführungs-Commits verwenden kann, um beim Zusammenführen darauf zu verweisen Zweige.
Was kann ich also tun, wenn ich einen Feature-Zweig mit dem Master zusammenführe:
Führen Sie ein Merge-Commit für den Master durch und schieben Sie ihn dann nach oben. ODER Den lokalen Zweig drücken und eine Pull-Anfrage starten?
Ich habe Pull-Anforderungen für ein 2-Personen-Team eingeführt – meine eigenen Anforderungen zusammenführen? und Wie sieht der Arbeitsablauf mit 2 Personen in einem Projekt aus und Soll ich Pull-Anfragen von einer Filiale im offiziellen Repo oder auf meiner Gabel öffnen? aber keiner von ihnen scheint zu antworten, wonach ich suche.
Kommentare
- Was genau fehlt Ihrer Meinung nach in diesen Antworten?
- Der erste spricht darüber aus dem Sinne, dass Pull-Anfragen Peer-Review sein sollen. Der zweite bietet einen Workflow. Der dritte ist nicht ' nicht einmal verwandt.
- Ich betrachte dies anhand einer Best Practices oder Gewusst wie Eine gute Git-Historie Sichtweise.
- Wenn ich eine PR zusammenführe, füge ich dazu den Zweig lokal zusammen. Auf diese Weise kann ich sicherstellen, dass die Zusammenführung sauber angewendet wird, und Tests erneut ausführen, bevor ich das Ergebnis veröffentliche. GitHub ' s Pull Requests sind nur eine Formalisierung dieses Workflows. Git selbst hat kein PR-Konzept.
- Wenn ein PR zusammengeführt wird, wird eine Zusammenführung erstellt Commit auf Master, also denke ich nicht, dass dies einen Unterschied für die Git-Geschichte macht. ' Daher glaube ich nicht, dass es ' einen Grund gibt, den einen oder anderen zu verwenden, abgesehen von Ihrer persönlichen Präferenz zwischen der Befehlszeile und der Github-Benutzeroberfläche.
Antwort
Git-Merge-Mechanismus:
Wenn Sie git merge feature verwenden, während Sie sich auf dem Master befinden, wird der Zweig feature mit master und zusammengeführt erzeugt ein merge-commit (wenn der Zweig nicht schnell vorgespult werden kann) im Git-Verlauf. Verwenden Sie die Option --no-ff mit merge, um das Erstellen einer merge-commit zu erzwingen.
Pull-Request-Mechanismus zusammenführen:
Wenn wir eine Pull-Anfrage auf GitHub starten, wird ein GitHub Issue, wo die Leute sprechen und die Commits in der PR diskutieren können, bevor sie zusammengeführt werden. Wenn ein PR auf GitHub zusammengeführt wird, funktioniert er genauso wie git merge feature.
Was soll ich tun? ?
In Bezug auf die Geschichte gibt es also keinen Unterschied zwischen den beiden.
Und was den Beitrag betrifft, werden Ihre Mitwirkenden keinen haben für die beiden Situationen etwas anderes zu tun. Sie sind gleich (abzüglich des netten kleinen Chats).
Best Practices:
Und ich konnte keine Best Practices finden, aber die Logik besagt, dass PRs nicht sehr hilfreich sind, wenn nur ein einziger Mitarbeiter zu einem Repository beiträgt.
@lxrec und @amon haben mir geholfen, zu dieser Schlussfolgerung zu gelangen.
Kommentare
- Tipp:
git mergezeichnet möglicherweise kein Zusammenführungs-Commit auf, wenn ein „schneller Vorlauf“ durchgeführt werden kann. Um ein Zusammenführungs-Commit zu erzwingen, können Sie die Option--no-ffhinzufügen. - Ich bevorzuge git-merge auf lokaler Ebene anstatt auf githuib.com, wenn ich Ich würde es vorziehen, nicht direkt auf dem Hauptzweig zu arbeiten. Ich würde lieber einen Nicht-Hauptzweig nehmen, der zuerst in den Staging-Modus versetzt werden kann, bevor er für die Produktion verfügbar gemacht wird.
Antwort
Wie Ashhar sagte, gibt es technisch und geschichtlich keinen Unterschied. Für Projekte mit a kleines Team Ich bevorzuge das direkte Zusammenführen anstelle des zusätzlichen Schritts zum Erstellen einer PR. Wenn jedoch eine Funktion überprüft / Feedback benötigt wird oder wenn es sich um eine WIP handelt und mehr als eine Person daran arbeitet, neige ich dazu, eine PR zu öffnen und eine hinzuzufügen Liste der Aufgaben in der PR-Beschreibung.
Beachten Sie, dass git merge möglicherweise den Schnellvorlauf verwendet, wenn keine Änderungen am Master vorgenommen wurden git merge --no-ff. Ich neige dazu, dies nicht zu tun.
Verwenden Sie also zusammenfassend nur PR s wenn Sie Diskussion brauchen. Ansonsten einfach direkt zusammenführen.
Kommentare
- ' Erwähnenswert ist auch, dass die Diskussion und das Feedback zu einer Pull-Anfrage möglich sind kommen aus automatisierten Quellen sowie Teammitgliedern. Wenn Sie einen CI-Server eingerichtet haben, kann dieser Build- und Testergebnisse liefern, sodass Sie niemals etwas zusammenführen, das den Build auf dem Master unterbricht.