git rebase eines zu lange offenen Branches -> What is the point?

[Jasson J. (jasson)]

Hallo zusammen,

ich finde mich noch in Git rein und verstehe diverse Erklärungen nicht, 
die ich online finde.

>Scenario: (siehe auch angehängtes Bild)
Mein konkretes Scenario ist, ich habe an einer Datei etwas verändert. 
Während ich das mache, arbeiten auch andere an dieser Datei in anderen 
Bereichen und mergen ihre Versionen auf den Master.
-
Wenn ich meine Version jetzt auch einfach merge, mache ich die Arbeit 
der anderen zu Nichte.
-
Ich habe den Hinweis bekommen "rebase" zu benutzten und einen Link
https://www.freecodecamp.org/news/the-ultimate-guide-to-git-merge-and-git-rebase/#git-rebase

Ich lese auch immer wieder, "rebase" ist quasi die Commit Geschichte neu 
schreiben.

>Mein Problem
Auch mit der gelinkten Seite und dem was ich sonst so finde, verstehe 
ich nicht, was rebase in diesem Scenario konkret "für mich tut" - bzw. 
mir hilft.
-
Am Ende geht es ja darum, die Abweichungen, die auf dem Master sind, an 
denen ich nicht gearbeitet habe, in meine Version des Dokumentes zu 
bekommen.

>Anmerkung
Ich denke, das Problem in meinem mentalen Modell ist, dass ich denke, 
dass nach dem Reabse in meinem lokalen Branch der Inhalt von dem File 
immer noch ausschließlich meine Änderungen enthält. Oder passiert da 
etwas hinter den Kulissen, durch das Rebase?

viele Grüße

[Ob S. (Firma: 1984now) (observer)]

Jasson J. schrieb:

> Ich habe den Hinweis bekommen "rebase" zu benutzten

Das ist ziemlicher Unsinn. Das benutzt man (wenn überhaupt) in eigenen 
Repos und dann auch nur, wenn man sich mit irgendeinem Ansatz völlig 
verrannt hat. Sollte also eigentlich niemals nötig sein.

> Am Ende geht es ja darum, die Abweichungen, die auf dem Master sind, an
> denen ich nicht gearbeitet habe, in meine Version des Dokumentes zu
> bekommen.

Da machst du einfach einen Pull in dein lokales Repo und löst die 
Konflikte auf, wenn es welche gibt. Erst danach kannst du dann das 
Ergebnis committen. Allerdings erst nach reiflicher Überlegung und 
Tests. Insbesondere in dem Fall, dass es echte funktionale Konflikte gab 
natürlich.

[Clemens L. (c_l)]

Jasson J. schrieb:
> Wenn ich meine Version jetzt auch einfach merge, mache ich die Arbeit
> der anderen zu Nichte.

Diese Beschreibung ist falsch. Ein Merge würde alle Änderungen 
zusammenführen. Die Änderungen der anderen würden nur dann verloren 
gehen, wenn du deine Revision auf den Server schiebst und dabei explizit 
andere Änderungen überschreibst. Das ist möglich (z.B. mit --force), 
aber nicht Standard, und oft gar nicht erlaubt.

> Ich lese auch immer wieder, "rebase" ist quasi die Commit Geschichte neu
> schreiben.

"Merge" und "rebase" sind ähnlich; das Ergebnis enthält alle Änderungen. 
Der Unterschied ist, das mit "merge" zwei Äste sichtbar sind, während es 
nach dem "rebase" so aussieht, als ob du deine Änderungen nach den 
anderen Änderungen gemacht hättest.

[J. S. (jojos)]

Das rebase macht gerade in großen Projekten Sinn weil man beim CI keine 
merge Konflikte haben möchte.
Man holt damit den aktuellen branch und dann werden darauf die commits 
angewandt. Dabei kann es zu merge Konflikten kommen, die du dann 
auflösen musst.

[Oliver S. (oliverso)]

Jasson J. schrieb:
> Wenn ich meine Version jetzt auch einfach merge, mache ich die Arbeit
> der anderen zu Nichte.

to merge:
https://m.dict.cc/englisch-deutsch/merge.html
vereinen, verbinden, zusammenführen, verschmelzen...

Der Sinn eines merges ist es, deine Änderungen mit denen von anderen 
zusammenzuführen.

Wenn allerdings die Änderungen der anderen genau im selben Codebereich 
wie deine stattgefunden haben, und die zueinander inkompatibel sind, 
dann habt ihr alle zusammen verkackt. Das kann weder ein merge noch ein 
rebase, noch git überhaupt lösen. Da die anderen in dem Fall einfach 
schneller waren, wirst du deine Änderungen schlicht in den Wind 
schreiben, und das commit dazu in deinem repo zurücknehmen müssen. Die 
Arbeit war umsonst.

Ob S. schrieb:
>> Ich habe den Hinweis bekommen "rebase" zu benutzten
>
> Das ist ziemlicher Unsinn. Das benutzt man (wenn überhaupt) in eigenen
> Repos und dann auch nur, wenn man sich mit irgendeinem Ansatz völlig
> verrannt hat. Sollte also eigentlich niemals nötig sein.

Natürlich nutzt man rebase immer dann, wenn es sinnvoll ist. Und das ist 
es in vielen Fällen.
Ob es im aktuellen Fall sinnvoll ist, keine Ahnung. Wenn das remote repo 
im gleichen branch nur ein commit weiter ist, als das repo des TO, ist 
ein rebase natürlich zweckfrei.

Oliver

[Udo S. (urschmitt)]

Hier ganz gut erklärt:
https://git-scm.com/book/de/v2/Git-Branching-Rebasing
Bei einem Rebase wird deine lokale Kopie erst auf den Stand von Master 
gebracht, incl. den Änderungen in Master.
Deshalb "rebase" Die "basis" deines Standes wird von der Version beim 
Pull auf die Version gebracht, die deine Kollegen vor dir schon 
hochgeladen haben.

[Monk (roehrmond)]

Jasson J. schrieb:
> Am Ende geht es ja darum, die Abweichungen, die auf dem Master sind, an
> denen ich nicht gearbeitet habe, in meine Version des Dokumentes zu
> bekommen.

Das Kommando dazu lautet
> git pull --rebase

[Jasson J. (jasson)]

Udo S. schrieb:
> Hier ganz gut erklärt:
> https://git-scm.com/book/de/v2/Git-Branching-Rebasing
> ...

Ja, da war ich vor 2 Stunden auch mal vorbeigekommen - aber in der 
englischen Variante - hatte nicht gesehen, dass sich die Sprache 
umstellen lässt.

Ich denke, der springende Punkt ist

>Dies funktioniert, indem Git zum letzten gemeinsamen Vorgänger der beiden 
>Branches (der, auf dem du arbeitest, und jener, auf den du rebasen möchtest) 
>geht, dann die Informationen zu den Änderungen (diffs) sammelt, welche
>seitdem bei jedem einzelnen Commit des aktuellen Branches gemacht wurden,
>diese in temporären Dateien speichert, den aktuellen Branch auf den gleichen
>Commit setzt wie den Branch, auf den du rebasen möchtest, und dann alle
>Änderungen erneut durchführt.

[Jan K. (jan_k776)]

Ob S. schrieb:
> Das ist ziemlicher Unsinn. Das benutzt man (wenn überhaupt) in eigenen
> Repos und dann auch nur, wenn man sich mit irgendeinem Ansatz völlig
> verrannt hat. Sollte also eigentlich niemals nötig sein.

Das ist so pauschal wirklich Quark... man kann rebase (wenn man weiß wie 
es funktioniert und die Zuständigkeiten des merge requests geklärt sind) 
wunderbar nutzen und damit das repo wunderbar sauber halten.

Mein "mentales" Modell, unter der folgenden Annahmen:
- es wird niemals auf dem Hauptentwicklungszweig (main/develop/master) 
gearbeitet, sondern nur in feature/bugfix branches (ist eh 
empfehlenswert, sogar wenn man alleine arbeitet)
- angenommener Stand: du arbeitest in deinem feature branch, der 
irgendwann mal von main abgezweigt ist, aber main wurde weiterentwickelt 
und du möchtest gerne die Änderungen in deinem feature branch haben.

Dann gibt es zwei Möglichkeiten:

1. merge main in feature, d.h. du integrierst die Änderungen vom main in 
deinen feature branch via `git merge`. Vorteile: Kein history rewrite. 
Nachteil: du hast merge commits (potenziell mehrere, wenn der feature 
branch länger lebt), i.e. eine etwas unsauberere git history - ist 
möglicherweise gar kein Problem.

2. rebase - das funktioniert anders herum als ein merge. Anstatt dass du 
die Änderungen von main in dein feature mergst (also main "oben drauf 
gesetzt"), werden bei einem rebase zuerst die Änderungen von main 
genommen, und dann werden all deine commits aus dem feature branch auf 
den main "angewendet". D.h., deine features werden auf main drauf 
gesetzt. Damit änderst du die history. Deswegen macht man das NUR in 
branches, die dir gehören, weil das sonst bei anderen, die auch in dem 
branch arbeiten zu Problemen führen kann - die man aber natürlich lösen 
kann. Vorteil: viel klarere History, keine merge commits von main in den 
feature branch. IMO das Killerfeature ist aber, dass im Gegensatz zum 
merge bei einem rebase auch Änderungen, die bereits angewendet wurden 
(z.B., weil diese schon über einen anderen feature branch nach main 
integriert wurden), einfach wegfallen/übersprungen werden, d.h. du wirst 
keine doppelten commits haben - macht die Sache viel klarer.

Es geht beides.