Hallo,
ich hab seit neuestem das Problem, immer wenn ich in Git “Pulle”, bekomme ich eine Fehlermeldung die das pullen abbricht.
Auf der Fehlermeldung steht:
Checkout conflict with file.
Kennt sich ja jemand eventuell aus und kann mir helfen?
Ich glaub es liegt daran, dass die Files unterschiedlich sind, aber es handelt sich hier um ein git Projekt, da ist das doch normal das die files sich verändern.
[quote=fragen]Ich glaub es liegt daran, dass die Files unterschiedlich sind, aber es handelt sich hier um ein git Projekt, da ist das doch normal das die files sich verändern.[/quote]Das schon, aber manchmal entstehen durch änderungen anderer Konflikte, die git nicht selbst auflösen kann.
Wenn beispielsweise in einer zeile “FooBar” stand, und jemand anders die Zeile zu “Foo” geändert und das gepusht hat und Du vor dem Pull die selbe Zeile zu “Bar” geändert hast, dann kann git nicht wissen, wer von euch beiden recht hat. Das musst Du im Kontext Deiner weiteren Änderungen selbst entscheiden.
bye
TT
Ja. Git ist nicht so gut geeignet, für Dinge, die sich ändern. :o)
Mal im Ernst: Ich finde auch, dass das ein Krampf ist, aber… es hat seine Gründe: Wenn jemand anderes an der gleichen Datei etwas geändert hat, wie du, ist erstmal nicht klar, was passieren soll.
Die übliche Empfehlung ist, nicht zu Pullen. Also, praktisch NIE zu pullen. Stattdessen sollte man
git fetch
machen, um sich erstmal die Dateien abzuholen, die ggf. jemand im zentralen Repository das es ja bei Git eigentlich gar nicht mehr gibt geändert hat.
Diesen Stand kann man dann mit seinem aktuellen, lokalen Stand mergen. Meistens mit sowas wie
git merge origin/master
(Wie genau das mit der Eclipse-Git-Integration geht, müßte ich auch erst nachsehen - aber die Empfehlung “nicht pull, sondern fetch+merge” sollte auch da gelten. IIRC ist “git pull” eigentlich nur eine Abkürzung für diese beiden Schritte - aber bei Konflikten funktioniert das eben nicht…)
Ist ja etwas nervig bei git, aber jetzt verstehe ich es zumindest.
Ich danke euch!
Hallo,
die einfachste Lösung für solche Probleme ist jegliche Arbeit auf einem lokalen Branch durchzuführen und niemals im master direkt zu arbeiten…
Dann kann man einfach auf den Master gehen und git pull machen…auf den branch wechseln und dann git rebase master …und weiter machen…
Gruß
Karl Heinz
[quote=fragen]Ist ja etwas nervig bei git,[/quote]Das ist bei jedem SCM so.
Im Gegensatz zu vielen anderen (insbesondere zentralistischen) SCM hat git aber die Konflikt nur bei dem User, der gerade den merge (als ein Teil von Pull) macht, und nicht bei allen gleichzeitig. Darüber hinaus ist git extrem gut im Auflösen von Konflikten, besser als andere SCMs.
[quote=kama;128855]die einfachste Lösung für solche Probleme ist jegliche Arbeit auf einem lokalen Branch durchzuführen[/quote]Das klingt jetzt danach, als wenn dann keine Konflikte auftreten würden, tun sie aber doch.
Konflikte sind unvermeidbar, wenn mehrere Leute zusammen arbeiten, und dabei nicht alle am selben Rechner sitzen.
Damit die Auflösung der Konflikte leichter wird benötigt man neben dem “Feature-Zweig” viele kleine commits in diesem. Beim “rebase” stellt git die Konflikte dann in jedem commit einzeln fest und fordert deren Auflösung. Und je weniger Änderungen dann in dem jeweiligen commit drin sind um so einfacher ist es zu beurteilen, welche Änderung übernommen werden sollte.
Wenn man dann noch Unittests für seine Änderungen im selben commit drin hat kann man diese vor dem “rebase --continue” noch mal Laufen lassen, denn “compiliert” heißt ja noch nicht “funktioniert”.
Falls da jemand fragt, wie man das schaffen soll: https://de.wikipedia.org/wiki/Testgetriebene_Entwicklung
bye
TT
Hallo,
ich hatte nicht geschrieben, dass das Konflikte vermeidet aber in der Situation, dass man den Master eben am einfachsten immer per git pull holen kann…wenn selbst nicht auf dem Master arbeitet ist das immer einfach möglich. (ja kann man auch mit git fetch machen) aber lokale branches sind nun mal einfacher…und eben auch Best Practice.
Die Auflösung der Konflikte muss man selbstverständlich entweder beim git rebase master machen oder später wenn man dann in den Master zurück merged…
Wie Du ja auch beschrieben hast…eben mit vielen kleinen Commits machen das Leben dann nochmal eine Spur leichter…
Gruß
Karl Heinz
[quote=kama]ich hatte nicht geschrieben, dass das Konflikte vermeidet[/quote]Das war Dir beim schreiben sicherlich auch klar, aber als unbedarfter Leser hätte man das so verstehen können. Deshalb wollte ich es klar stellen, so rein prophylaktisch…
bye
TT