Frage zu Git (Datei aus merge Prozess ausschliessen)

[fliegermichl]

Guten morgen,

nachdem ich mein Delphiprogramm erfolgreich nach Lazarus portiert habe, habe ich Bugfixes bislang immer noch in der Delphiversion gemacht. (Die wird ja aktuell auch noch an die Kunden ausgeliefert)

Dann wechsel ich einfach in den Lazarus Branch und übernehme diese Anpassungen per

Code: Alles auswählen

git merge master

aus dem Master Branch.

Jetzt habe ich da eine lfm Datei, die sich gegenüber der alten dfm Version dermassen geändert hat, das ein merge hunderte von Konflikten erzeugt und ich Anpassungen in dem Bereich sowieso in beiden Versionen händisch mache.

Gibt es eine Möglichkeit git zu sagen, daß es diese Datei beim mergen bitte aussen vorlassen soll?

[Warf]

Klar geht das. Du kannst die merge strategie "ours" angeben, dann werden alle konflikte zu gunsten des aktuellen standes aufgelöst.

Code: Alles auswählen

$> git merge -s ours -F file_to_merge

Allerdings würde ich grundsätzlich empfehlen statt einem git merge einen interaktiven rebase zu machen. Der unterschied ist, beim merge tust du praktisch 2 git pfade zusammenführen mit einem merge commit, beim rebase nimmst du einfach deine Änderungen von deinem branch, und hängst sie an die neuste version des anderen branches an.
Also z.B. sagen wir mal du willst ein neues feature auf basis von Branch A machen in Branch B. Wenn du branch B erstellst ist Branch A die commit historie:

Code: Alles auswählen

A1->A2->A3->A4

Dann machst du ein paar commits in B:

Code: Alles auswählen

A1->A2->A3->A4->B1->B2

Währenddessen wurde zu A allerdings A5 und A6 hinzugefügt. Bei einem Merge hast du dann

Code: Alles auswählen

A1->A2->A3->A4->B1->B2->Merge
             \        /
              +A5->A6+

Das Problem ist das du jetzt parallele branches hast. Also wenn du von Merge 1 commit zurückgehen willst, wo landest du B2 oder A6? Egal was du wählst, einer der beiden subbranches geht verloren und du darfst den merge nochmal machen.

Bei einem rebase hingegen fügst du einfach die neuen commits ein und endest mit:

Code: Alles auswählen

A1->A2->A3->A4->A5->A6->B1->B2

Was viel sauberer und viel einfacher zu managen ist. Noch dazu kannst du in einem Rebase die commit history aufräumen, du kannst commits umsortieren, zusammenfassen, aufsplitten, löschen, neue hinzufügen, nachrichten ändern, etc.

Um einen rebase zu Branch A zu machen einfach auf branch B dann:

Code: Alles auswählen

git rebase -i A

Dann öffnet sich dein GIT editor (z.B. vim) mit einer liste mit allen betroffenen commits (Also B1, B2, A5 und A6). Hier kannst du jetzt erst einmal schauen ob du mit dem Layout der commits so zufrieden bist, oder due wie oben erwähnt, reiehenfolge ändern willst, zusammenfassen willst oder löschen willst. In den allermeisten fällen solltest du aber nix ändern müssen.

Danach wenn du das dokument speicherst und den editor schließt, fängt der rebase an. Dabei wird durch jeden commit gegangen der sich geändert hat und geschaut ob du merge konflikte hast. Die musst du einfach ganz normal beheben und evtl neu commiten. Am ende ein git rebase --continue machen und der rebase prozess geht weiter.

Wenn du auf Branch B 3 commits hast, musst du im schlimmsten Fall 3 mal merge konflikte lösen. Das wird zwar bei sehr vielen commits irgendwann echt langwierig, aber für das endergebnis lohnt es sich. Die Git historie ist viel übersichtlicher und rollbacks sind viel einfacher zu machen

[fliegermichl]

Danke erstmal für die ausführliche Beschreibung.
Mit rebase habe ich noch nicht gearbeitet.

Kann ich da durch Unwissenheit auch was so kaputt machen, daß ich es am Ende nicht wieder hinbekomme?

Wenn ich mir die Historie so anschaue mit diesen ganzen Pfaden die da hin und hergehen, wird mir schlecht.

[Warf]

Mit einem Rebase änderst du die Historie deines Git branches, also ja, da kann einiges kaputt gehen. Während dem rebase kannst du aber auch jederzeit abbrechen:

Code: Alles auswählen

$> git rebase -i branch
# Fehler aufgefallen: Abbrechen und alles wird rückgängig gemacht
$> git rebase --abort

Wenn dir nach dem rebase auffällt das was kaputt gegangen ist, geht das natürlich nicht. Das lässt sich aber einfach lösen, einfach vor dem rebase eine backup kopie des branches zu machen:

Code: Alles auswählen

$> git branch backup
$> git rebase ...
[...]
# Was kaputt gegangen einfach zurücksetzen:
$> git reset --hard backup
# Oder einfach server als backup benutzen
$> git reset --hard origin/branch

Und ganz wichtig
1. Niemals master/main rebasen, nur branches die auch kaputt gehen dürfen
2. Erst pushen wenn du dir sicher bist das der rebase korrekt war (damit hast du den server immer als backup)

[fliegermichl]

Hmm,

irgendwas mache ich wohl noch falsch.
Wenn ich git rebase -i Lazarus eingebe, dann erscheint der vi. Da steht nur noop in der ersten Zeile und darunter eine Liste von Kommandos die man wohl eingeben kann.
Wenn ich den Editor verlasse, spricht er:
Successfully rebased and updated refs/heads/Lazarus.

Aber danach sieht alles so aus wie vorher und git status zeigt "Your branch is up to date with 'origin/Lazarus'. nothing to commit, working tree clean.

[Mathias]

Frage zu Git (Datei aus merge Prozess ausschliessen)

Ist die diese Datei bekannt ?
Dort kannst du alles auflisten, was nicht hochgeladen werden soll.

.gitignore

https://www.atlassian.com/de/git/tutori ... /gitignore

[fliegermichl]

Dann würde die Datei ja nicht mehr versioniert.
Das soll sie schon noch. Nur eben beim merge nicht.