guten morgen,
ich habe eine Frage zu git.
Und zwar bin ich gerade dabei einen Merge von dem develop-Branch in
meinem Feature-Branch zu machen. Der develop-Branch ist natürlich etwas
weiter, beinhaltet aber Änderungen, die ich benötige.
Wenn ich jetzt den merge starte, bekomme ich in sehr vielen dateien die
Meldung, dass es einen Mergeconflikt gibt. Dieser Mergekonflikt kommt
von einer Namensänderung eines defeines.
Es wurden aber völlig unterschiedliche Bereiche geändert. Also es wurde
nie die selbe Zeile oder so geändert.
Wie kann ich jetzt schnell sagen, dass letztendlich jede Änderung vom
die BASE unterschiedlich sind genommen werden? Also ohne händisch jeden
Konflikt (was eigentlich kein Konflikt ist) zu sagen was genommen werden
soll.
BSP.
1
LOCAL REMOTE BASE
2
if(x) empty empty
3
{
4
...
5
}
Hier soll der Local genommen werden
1
LOCAL REMOTE BASE
2
NAME_OLD NAME_NEW NAME_OLD
hier ist mein LOCAL gleich der BASE (der Name auf dem Remote hat sich
geändert), also soll der Remote genommen werden.
Ich als absoluter git-Diletant kenne das Problem mit solchen durch
Umbennenungs-Massenänderung ausgelösten merge-Katastrophen trotzdem.
Lösung? in git kenne ich keine. Auuser natürlich, die branches erst gar
nicht so weit auseinander laufen zu lassen, und solche Massenänderungen
sauber in einzelne commits zu kapseln, und dann sofoert zu mergen, wenn
irgendwie möglich.
Was ich in diesem Fall machen würde, ist, eine Zwischenversion mit den
neuen Features, aber den alten define-Namen zu erstellen, und die
define-Umbenennung nach dem merge mit den anderen neuen features im
Sourcecode vorzunehmen. Falls der alte define-Name zu Namenskonflikten
führt, müssen die dann halt auch temporär umbenannt werden.
Dein erster Fall sollte allerdings doch eh automatisch mergen.
Oliver
develop merge ich generell nie in den Feature branch. Da mache ich
statdessen immer ein rebase. Dann sind nur die eigenen änderungen am
ende immer oben drauf, und nicht merge commits dazwischen die die
Historie auseinander laufen lassen. Wird hier aber vermutlich auch nicht
viel helfen. Naja, ist ja nur ein kleines feature, oder? Als halt dann
einmal manuell drüber, und vor dem einchecken nochmal nachprüfen, das
nichts durcheinander gekommen ist.
Oliver S. schrieb:> Dein erster Fall sollte allerdings doch eh automatisch mergen.
Ja, es sollten alle fälle automatisch gelöst werden,
aber er nimmt immer den BASE (also nicht meine Änderung)
🐧 DPA 🐧 schrieb:> develop merge ich generell nie in den Feature branch. Da mache ich> statdessen immer ein rebase. Dann sind nur die eigenen änderungen am> ende immer oben drauf,
Ja, normalerweise mache ich es auch so. Aber ich hatte einen teil schon
einmal gepusht zum Testen. Und einige ziehen sich das dann sofort
runter. Wenn ich jetzt einen Rebase mache, sind die sauer, da die
Branches auseinandergelaufen sind.
Also egal wie ich es mache, es ist sowieso verkehrt ;)
🐧 DPA 🐧 schrieb:> Naja, ist ja nur ein kleines feature, oder? Als halt dann> einmal manuell drüber, und vor dem einchecken nochmal nachprüfen, das> nichts durcheinander gekommen ist.
Ja, so habe ich es auch gemacht.
Mich hat es generell einfach gewundert warum es überhaupt konflikte
gibt, da es meiner Meinung nach kein Mergekonflikt gibt, da es völlig
unterschiedliche Zeilen sind.
Es war auch nicht schwer, da ich einfach alle Änderungen (egal ob von
LOCAL oder REMOTE) übernommen habe. War einfach nur fleißarbeit.
Wenn ein Featurebranch lange läuft und dabei grundlegende Änderungen an
bestehenden Softwareteilen oder gar an der Ordnerstruktur vorgenommen
werden dann kriegt man das irgendwann nicht mehr gemerged.
Da muss dann jemand händisch rann und per 3-Wege-Vergleich die
Änderungen einzeln bewerten und mergen.
den feature branch würde ich auch develop oder main rebasen bevor er
wieder in diese gemerged wird. So kenne ich es von größeren Projekten
und da ist das Pflicht vorher das rebase zu machen. Beim rebase kann es
natürlich auch merge Konflikte geben wenn an einer Datei in beiden
branches etwas geändert wurde.
Le X. schrieb:> Wenn ein Featurebranch lange läuft und dabei grundlegende Änderungen an> bestehenden Softwareteilen oder gar an der Ordnerstruktur vorgenommen> werden dann kriegt man das irgendwann nicht mehr gemerged.
naja, der läuft ja nur lange, weil die guten damen und herren nicht zum
testen kommen ;)
Mein Problem ist wahrscheinlich falsch rübergekommen.
An für sich gibt es kein Mergeproblem. (Ordnerstruktur, Dateinamen usw.
ist alles gleichgeblieben)
Auf dem Remote hat sich z.B in Zeile 6 was geändert und bei mir Lokal in
Zeile 200.
Beim Mergen zeigt der mir dann für Zeile 6 an:
1
LOCAL REMOTE BASE
2
Neue_Funktion Alte_Funktion Alte_Funktion
Wo ist dass denn ein konflikt? Remote und Base sind gleich. Trotzdem
nimmt er Base und ich muss händisch überall sagen, dass doch bitte meine
Lokale Änderung Übernehmen soll
J. S. schrieb:> den feature branch würde ich auch develop oder main rebasen bevor er> wieder in diese gemerged wird.
Wie oben schon erwähnt, so werde ich auch ärger bekommen ;)
Ja, das ist einfacher und würde ich auch machen wenn ich noch nichts
gepusht hätte.
Aber auch bei einem Rebase ist bei mir das Problem, dass es nicht
automatisch gemergt werden kann, obwohl es kein Konflikt ist (siehe
Beispiel im oberen Kmomentar)
Aber gerade durch das Rebase ändere ich ja die Historie, die bei einem
Merge nicht verändert wird.
david schrieb:> Auf dem Remote hat sich z.B in Zeile 6 was geändert und bei mir Lokal in> Zeile 200.> Beim Mergen zeigt der mir dann für Zeile 6 an:
Wer genau zeigt da was an? Das ist ja eher ein Problem deines
(ungenannten) merge-tools.
Oliver
david schrieb:> Ja, normalerweise mache ich es auch so. Aber ich hatte einen teil schon> einmal gepusht zum Testen. Und einige ziehen sich das dann sofort> runter.
Ich bin der Meinung, feature branches dürfen und sollen das. Ein Blick
auf die Historie genügt ja in der regel, um zu sehen, das da ein Rebase
war (Die Änderungen nue weiter oben sind). Und wenn sie selbst was
ändern, müssen sie das halt auch wieder rebasen. Dann macht man halt
fetch + rebase statt einfach nur pull.
Wobei, warum arbeiten überhaupt mehrere am selben Feature? Da muss man
sich ja in die quere kommen...
Oliver S. schrieb:> Wer genau zeigt da was an? Das ist ja eher ein Problem deines> (ungenannten) merge-tools.>> Oliver
zum Mergen nehme ich KDIFF3 (Beyond compare bekommen wir leider nicht)
in der .gitconfig habe ich dazu
Wenn dieses Tool ein Merge macht, nimmt dieser alles von BASE oder
änderungen von REMOTE, aber keine Änderungen von LOCAL
🐧 DPA 🐧 schrieb:> Wobei, warum arbeiten überhaupt mehrere am selben Feature? Da muss man> sich ja in die quere kommen...
Ja, mein reden. Aber sage das mal unserem Projektleiter.
Wobei, dass wir wirklich am selben Feature arbeiten ist selten.
Eher ziehen die anderen sich den Branch nur um zu sehen was ich mache.
Selber drauf entwickeln tun sie nicht.
Allerdings können die kein pull mehr machen, wenn ich ein rebase gemacht
habe
🐧 DPA 🐧 schrieb:> Dann macht man halt> fetch + rebase statt einfach nur pull.
Das funktioniert dann?
Wusste ich nicht, müssen wir mal testen. Das wäre dann natürlich
geschickt und ich könnte weiter den Rebase machen (obwohl wie oben schon
erwähnt ja auch hier das Problem mit dem Merge besteht)
david schrieb:> Eher ziehen die anderen sich den Branch nur um zu sehen was ich mache.> Selber drauf entwickeln tun sie nicht.
In solchen fällen würde ich beim checkout gar nicht erst einen Branch
erstellen. Also git fetch, dann "git checkout <remote>/<branch>". Dann
ist man in einem 'detached HEAD' state. Da kann man keine Commits
anhängen, weil auf keinem Branch, aber anschauen, inklusive historie
geht. Braucht mann dann doch einen Branch, kann man das mit "git branch
-b branchname" nachholen.
Thread beobachten
Seitenaufteilung abschalten