Ich bin wahrscheinlich nicht etwas richtig, aber könnte mir jemand erklären, warum git rebase
führt zu Konflikten, während git merge
(gleichen Zweig) nicht?Git: Warum führt Rebase zu Konflikten während Merge nicht?
Soweit ich weiß git rebase
setzt die Commits aus dem anderen Zweig vor den Commits, die ich auf meinem aktuellen Zweig gemacht, während git merge
nimmt die gleichen Commits und wendet sie auf meine Branche als Patch, richtig? Ist das diff
dann nicht dasselbe, obwohl vielleicht umgekehrt? Nicht sicher, warum das Patchen meines Zweiges mit den anderen Commits kein Problem ist, während das Patchen des anderen Zweigs mit meinen Commits ist.
Ich verstehe, was Sie sagen, aber ich verstehe es immer noch nicht ganz. Sagen Sie, mein Zweig A hat a, b und c festgelegt. Dann erzeuge ich Zweig B mit den Commits d und e. Commit f wird auf Zweig A gemacht. ** Rebase ** (während auf Zweig B) ergibt: a, b, c, f, d, e; ** Zusammenführen ** würde zu folgenden Ergebnissen führen: a, b, c, d, e, f. Nun, wie in aller Welt könnte man einen Zusammenführungskonflikt mit commit c erstellen, wenn es auf der Basis von commit c auf Zweig A erstellt wurde? – minitauros
@minitauros (1) Eine Zusammenführung würde dazu führen, dass zwei Zweige verbunden werden: einer mit a, b, c, f und einer mit a, b, c, d, e, keine lineare Historie. (2) Wenn Commit F, das auf Zweig A gemacht wurde, keinen Konflikt einführt, dann kann ich nicht sehen, wie es einen Konflikt beim Rebasieren verursachen könnte (wenn Sie ein detaillierteres Beispiel haben, wäre das großartig). (3) Aber wenn D Konflikt mit F und E behebt diesen Konflikt, würde eine Rebase den Konflikt wiedergeben, während eine Zusammenführung nicht würde. – coredump
Ok, danke für die Erklärung da! Es räumt ein bisschen auf. Leider habe ich das Beispiel nicht mehr (wie ich es behoben habe), aber wenn ich es noch einmal anführe und wenn die gleiche Frage auftaucht, werde ich diesen Beitrag mit mehr Infos aktualisieren :). Für jetzt denke ich, diese Antwort ist gut genug, danke! – minitauros