Was ist falsch an Merge-Commits?

Lesezeit: 3 Minuten

Ich sehe viele Fragen, bei denen die Leute fragen, wie das “sinnlose” Merge-Commits vermeiden kann.

Was genau ist schlecht an einem Merge-Commit? Ich finde sie nützlich, da Sie genau sehen können, wo zwei Entwickler mit der Arbeit begonnen haben und wo ihre Arbeit zusammengeführt wurde. Es scheint, als würde eine Neubasierung, wie viele Antworten vermuten lassen, diese Informationen zerstören und Sie verlieren einen Großteil der Projektgeschichte.

Gibt es etwas, das ich vermisse, das einen Merge-Commit unerwünscht macht?

Ich habe mich eigentlich gefragt, ob es Fälle gibt, in denen Merge-Commits tatsächlich sind Ja wirklich, Ja wirklich nützlich. (Der Fall, den Sie erwähnen, klingt ehrlich gesagt nicht allzu überzeugend …) Ich frage mich, ob jemand darauf näher eingehen möchte …

– Alois Mahdal

9. Oktober 2018 um 18:22 Uhr

Michael

Es gibt zwei verschiedene Arten von Merge-Commits:

Explizite Merge-Commits, die beispielsweise durch das explizite Mergen eines Feature-Branch in den Main-Branch entstehen
und implizite Merge-Commits, die zum Beispiel resultieren, indem man a git pull bevor Sie versuchen zu drücken

Die expliziten Merge-Commits sind normalerweise vollkommen in Ordnung. Normalerweise erzwingen Sie diese Art von Merge-Commits sogar, indem Sie sagen git merge --no-ff.

Die impliziten sind nur Rauschen, da die typische Situation ist, dass ein Entwickler eine Datei geändert hat und danach ein anderer Entwickler an einer anderen Datei arbeitet, aber vergessen hat, vor den Änderungen zu ziehen, und a git pull wird beide Commits implizit zusammenführen, indem es ein lautes Merge-Commit erstellt. Der logischere Verlauf wäre einfach ein Commit des einen Autors und ein Commit des anderen Autors. Tun git pull --rebase werde genau das tun.

Natürlich gibt es Ausnahmen. Wenn beide Autoren tatsächlich an derselben Datei gearbeitet haben, ist es möglicherweise besser, an dieser Stelle einen Merge-Commit zu haben. – Aber auch in diesem Fall könnte ein Rebase besser sein, da es die Änderungen gegenüber dem ersten Commit expliziter und daher weniger fehleranfällig macht.

Aber wenn Sie eine implizite Zusammenführung haben, die Sie aber lösen, wäre es nicht eigentlich gut, das in Ihrer Historie zu haben? Dann können Sie sehen, was Git automatisch für Sie getan hat. Ich meine, auch ohne Konflikte ist es relevant. Weil ein Commit auf einem bestimmten Status basierte, der nach einem Pull/Fetch/Rebase/Merge möglicherweise nicht mehr gültig ist.

– Wouter Schut

21. November 2014 um 22:35 Uhr
@WouterSchut Es bewahrt zwar die Informationen darüber, in welchem genauen Zustand sich die Codebasis befand, aber in der Praxis würde ich sagen, dass es den Lärm nicht wert ist. Wenn Sie Geschichte studieren, interessieren Sie sich normalerweise mehr dafür, wer und warum, und Commit-Nachrichten bieten bereits einen weitaus besseren Weg, dies zu bestehen. Auch wenn der Zustand so erheblich anders ist und jemand diese Unterschiede nicht bewusst, ehrlich und sorgfältig angegangen ist (z. B. bedenkt, ob angesichts des neuen Zustands sein Feature immer noch wert ist), wenn er zusammengeführt/umbasiert wird, haben Sie wahrscheinlich sowieso ein größeres Problem .

– Alois Mahdal

9. Oktober 2018 um 18:17 Uhr
Ich liebe diesen Namen: „Implicit Merge Commits“! Aber das Beispiel war mir zu vage, kannst du das etwas genauer erklären? Das ist jedoch in Ordnung, es macht für mich auch ohne dieses Beispiel völlig Sinn, wenn es beim Git-Pull Konflikte gibt, dann (es sei denn, es schlägt aufgrund von –ff-only fehl) müssen die Merge-Konflikte gelöst werden, die dann ein werden fremdes Commitment. Aber ich bin immer noch neugierig, ob ein Merge-Commit auch OHNE Konflikte generiert werden kann? Wie klingt das in deinem Beispiel? Die Antwort ist trotzdem großartig, danke.

– aderchox

28. Juni um 22:10 Uhr

11768700cookie-checkWas ist falsch an Merge-Commits?

#git #git-merge #git-rebase