Wie werden Pull-Anfragen mit Git Extensions behandelt?

8

Ich habe ein öffentliches Repository auf github , das Probleme beim Verarbeiten von Pull-Anforderungen mit GitExtensions verursacht. Ich habe bisher 3 gemacht, und ich glaube nicht, dass einer von ihnen richtig funktioniert hat oder dort gearbeitet hat, wo ich sie haben möchte.

  1. Am 19. habe ich versucht, eine Pull-Anfrage zu bearbeiten, die Yi Jiang erstellt hat. In GitExtensions habe ich innerhalb von GitExtensions einen Pull ausgeführt, indem ich das Remote-Repository eingefügt habe, Master als Remote-Zweig ausgewählt habe und Remote-Zweig zum aktuellen Zweig zusammenführen als Standard festgelegt habe. Ich klickte auf Pull und es wurde ohne Fehler abgeschlossen. Es gab ein paar Dinge, die ich aufgeräumt habe, und dann habe ich dann einen Schub in GitExtensions gemacht. Es wurde keine Commit-Nachricht ausgefüllt, was mich überraschte, also warf ich einfach die URL von Yi Jiangs Commit ein, weil ich nicht wusste, was ich sonst tun sollte. Das Ergebnis war, dass es als ein Paar von Commits auftauchte, eines von Yi Jiang als Autor und eines von mir als Autor.

  2. Später am 19. habe ich versucht, eine Pull-Anfrage zu bearbeiten, die Michael erstellt hat. Da es ziemlich klar schien, dass ich den ersten falsch gemacht habe, suchte ich nach einer anderen Möglichkeit. Ich habe hier die ersten Befehle ausgeführt, die hier gefunden wurden und das scheint großartig zu funktionieren. Das einzige Problem ist, dass ich es über die Befehlszeile anstatt innerhalb von GitExtensions tun musste.

  3. Ein weiterer Antrag von Yi Jiang. Da es über GitBash anstatt GitExtensions das letzte Mal zu funktionieren schien, habe ich es nochmal versucht. Diesmal konnte es jedoch nicht abgeschlossen werden, da es Konflikte bei der Zusammenführung gab. Ok, also gehe ich zu GitExtensions und mache eine Zusammenführung, weil ich weiß, dass ich die Konflikte lösen kann. Also öffne ich den Dialog Zweige zusammenführen und wähle Merge with und wähle Yi Jiangs Hauptzweig aus, der Keep a single branch line if possible (fast forward) zurücklässt. Ich löse die Konflikte auf und mache einen Push. Es legt automatisch die Commit-Nachricht für mich fest. Dies zeigt sich in 4 Einträgen, 3 von Yi Jiang als Autor und 1 von mir als Autor. Scheint nicht richtig.

Meine Frage ist also, wie soll ich das richtig machen? Ich habe eine weitere Pull-Anfrage und möchte sicherstellen, dass ich sie richtig handhabe. Die Gabel-Warteschlange sagt, dass sie nicht sauber angewendet wird, also sehe ich voraus, dass ich eine Zusammenführung durchführen muss. Ich möchte sicherstellen, dass ich richtig verschmilze und dass die Zweige und die Verpflichtungen den Leuten zugeschrieben werden, die die Arbeit geleistet haben. Wenn es Änderungen gibt, die erledigt werden müssen, sollte ich zuerst das Merge / Push zuerst machen und dann ein zweites Commit nur mit dem einzelnen Zweig machen? Wie wirkt sich das auf das Lösen von Zusammenführungen aus?

Könnte jemand den genauen Prozess der korrekten Verarbeitung einer Pull-Anforderung in GitExtensions durchgehen?

    
Rebecca Chernoff 22.10.2010, 03:51
quelle

1 Antwort

5

# 1 klingt normal - Das erste ist das Commit aus dem Zweig, in den Sie gezogen haben, das zweite ist das Merge-Commit (das die Zweige tatsächlich zusammenführt). Der Merge-Commit wird von jedem durchgeführt, der git pull tut - aber wenn Sie sich die Dateien in git blame ansehen, werden Sie sehen, dass die Schuldzuweisungen alle für den ursprünglichen Autor sind (Merge-Commits fügen keine Schuld-Lines hinzu, außer Sie Konflikte lösen).

# 3 scheint aus dem gleichen Grund auch normal zu sein - das Zusammenführen fügt ein einzelnes Commit hinzu, das die Zweige tatsächlich zusammenführt.

Meine Annahme mit # 2 ist, dass die Pull-Anforderung dort eigentlich war ein Schnellvorlauf, und daher war kein Zusammenführen erforderlich, während # 1 und # 3 nicht schnell vorwärts waren (auch wenn sie sind ohne Konflikte zusammengeführt worden, sie waren nicht direkte Nachkommen der Ihrer HEAD ).

Grundsätzlich denke ich, dass du es richtig machst, auch wenn es ein bisschen seltsam erscheint. :)

Wenn Sie eine etwas längere Erklärung der Unterschiede zwischen Vorspulen und Zusammenführen möchten, hier ist jemand anderes:

  

Beim Zusammenführen und "Vorspulen"

     

Sie werden feststellen, dass wir den Ausdruck "schnell vorwärts" mehrmals gesehen haben. Dies ist eine Spezialfalloperation, die von "git merge" durchgeführt wird, wobei eine Verzweigung entlang einer linearen Sequenz vorgerückt werden kann. Dies geschieht immer dann, wenn Sie Änderungen ziehen, die direkt auf dem Commit basieren, das Sie als letzten Commit haben. Mit anderen Worten, es gab niemals eine Divergenz oder gleichzeitige Commits, die parallel in mehreren Repositories erstellt wurden. Wenn es Parallel-Commits gegeben hätte, würde "git merge" tatsächlich ein neues Merge-Commit einführen, um die beiden Commits miteinander zu verbinden.

     

Wenn eine Nicht-Fast-Forward-Zusammenführung auftritt, besteht immer die Möglichkeit, dass ein Konflikt auftritt. In diesem Fall hinterlässt "git merge" Konfliktmarken in den Dateien und weist Sie an, die Konflikte zu lösen. Wenn Sie fertig sind, geben Sie eine "git commit -a" aus, um den Zusammenführungs-Commit zu erstellen.

(Aus Ссылка )

Bearbeiten

Ich ging und sah mir das eigentliche Repository auf Github an. Die letzten zwei Pulls (# 2 und # 3) scheinen richtig funktioniert zu haben und getan zu haben, was hätte getan werden sollen - im Fall von # 2 schnell vorwärts und in # 3 zusammengeführt (mit einem hinzugefügten merge commit).

Ich bin nicht ganz sicher, was mit # 1 passiert ist - irgendwie scheint es, dass ein Teil der Änderungen von Euch in ein separates Commit versetzt wurde? Konnte es nicht besser sagen, ohne in der Lage gewesen zu sein, zu sehen, was tatsächlich zu der Zeit getan wurde. Vielleicht hatten Sie nicht festgeschriebene Änderungen und Sie haben sie begangen, ohne es zu merken?

    
Amber 22.10.2010, 04:16
quelle

Tags und Links