Nach vielen Versuchen erhielt ich dieses einfache Testfallszenario:

a --> b --> c --   (master)
 \              \
  --> d --> b' --> e   (branch)

Woher:

b' ist eine Kirschsorte vonbe ist einverschmelzen vonmaster.

b' wurde nach getanc undc hat Änderungen an den gleichen Dateien wieb (d spielt wahrscheinlich keine Rolle).

e kann leicht sehr unerwartet aussehen.

Angenommen, alle haben es mit derselben Datei zu tun. "foobar.txt". So sieht die Datei in jedem Commit aus:

// ----------- a
foo

delme

bar

// ----------- b
foo

delme

new

bar

// ----------- c
foo

new

bar

// ----------- b'
foo

delme

new

bar

// ------------ e
foo

new

new

bar

Nun, das war von meinem kurzen Test gerade, mit diesemgenau Konfiguration.

Wenn Sie alles entfernenLeerzeichen da gibt es kein solches problem. Merge beschuldigt nur einen Konflikt, wie ich es erwarten würde. Aber ich glaube nicht, dass wir hier nach einer -X-Einstellung für Leerzeichen suchen ... oder?

In der Zwischenzeit habe ich in meinem Produktionscode, der der Grund war, warum ich mich mit all dem befasst habe, und der nicht annähernd so viele Leerzeichen aufweist, gesehene sieht stattdessen so aus:

// ----------- e
foo

delme

new

bar

Das alles passiert mitverschmelze und beschuldige niemals einen Konflikt!

Wenn git hier eines seiner magischen Voodoo-Auto-Merges durchführen würde, würde ich erwarten, dass es so aussieht:

// ----------- e
foo

new

bar

Das passiert aber auch nicht.

Als ein bisschen aHaftungsausschluss...

Ich habe es auch versuchtLesen Sie das f-Handbuch, aber ich kann nicht wirklich zu viele Punkte unter Zusammenführungsstrategien verstehen. Außerdem sagt es nicht wirklich, was das istresolve Strategie tut unter der Haube, zum Beispiel:

Es versucht, Kreuz-Kreuz-Mehrdeutigkeiten sorgfältig zu erkennen und gilt allgemein als sicher und schnell.

Das sagt nichts.

Der Text zum Standardrecursive ist größer, aber ich konnte auch nicht genug Informationen daraus extrahieren:

Es wurde berichtet, dass dies zu weniger Zusammenführungskonflikten führt, ohne dass durch Tests, die mit tatsächlichen Zusammenführungs-Commits aus dem Entwicklungsverlauf des Linux 2.6-Kernels durchgeführt wurden, Fehlzusammenführungen verursacht werden.

Gemeldet? Wir haben also einen sehr schweren Unit-Test und von ein paar Berichten angenommen, dass alles in Ordnung ist?

Nun, es ist mir alles zu vage.

Meiner Ansicht nachIch muss etwas falsch machen! Also, wie kann ich es richtig machen?

Was muss ich tun, um wieder sorglos zu verschmelzen?