{"id":22891,"date":"2025-10-17T17:41:35","date_gmt":"2025-10-17T15:41:35","guid":{"rendered":"http:\/\/blog.wenzlaff.de\/?p=22891"},"modified":"2025-11-01T19:50:41","modified_gmt":"2025-11-01T18:50:41","slug":"vermeide-git-foxtrot-merge-schritt-fuer-schritt-anleitung-mit-loesung","status":"publish","type":"post","link":"http:\/\/blog.wenzlaff.de\/?p=22891","title":{"rendered":"Vermeide git Foxtrot-Merge – Schritt f\u00fcr Schritt Anleitung mit L\u00f6sung"},"content":{"rendered":"

Der Foxtrott-Merge ist wie Tanzen mit Git<\/a> \u2013 nur dass hier nicht die F\u00fc\u00dfe stolpern, sondern die Commits. Beide starten synchron, drehen sich elegant umeinander, bis einer pl\u00f6tzlich im falschen Takt mitschreibt. W\u00e4hrend T\u00e4nzer das charmant \u00fcberspielen, verursacht es in Git eine chaotische Merge-Historie. Der Foxtrott bringt Schwung ins Parkett, der Foxtrott-Merge dagegen Unordnung ins Repository. <\/p>\n

Und das Beste daran: Ich kann zwar kein Foxtrott tanzen<\/a>, aber diesen Merge krieg ich jedes Mal hin \u2013 leider. In diesem Sinne mal eine Anleitung mit L\u00f6sung.<\/p>\n

\"\"<\/p>\n

Ein Foxtrot Merge ist ein problematischer Merge-Commit in Git, bei dem die Reihenfolge der Parent-Commits vertauscht ist und dadurch die First-Parent-Historie des Hauptzweigs durcheinanderbringt. <\/p>\n

Konkret entsteht ein Foxtrot Merge, wenn du lokale \u00c4nderungen committed hast, dann \u00a0git pull<\/strong>\u00a0 ausf\u00fchrst (was automatisch einen Merge erstellt), und dieser Merge-Commit den Remote-Branch als zweiten statt als ersten Parent referenziert.<\/p>\n

Das Problem wollen wir mal auf einem Raspberry PI 2 W Zero mit Kali (jedes andere Betriebssystem geht auch \ud83d\ude09 nachstellen und zum Schluss eine L\u00f6sung zum verhindern aufzeigen. Wir machen grob das:<\/p>\n

\"\"<\/p>\n

Das Problem<\/strong>
\nBei einem Merge-Commit sind die Eltern geordnet: Der erste Parent ist HEAD (der Commit, auf dem du warst), der zweite Parent ist der Commit, den du mergst. <\/p>\n

Ein Foxtrot Merge macht \u00a0origin\/master<\/strong>\u00a0 zum zweiten Parent, wodurch die First-Parent-Historie \u2013 die Git in vielen Befehlen wie \u00a0git log –first-parent\u00a0 verwendet \u2013 verf\u00e4lscht wird. Dies erschwert die Nachvollziehbarkeit der Haupt-Entwicklungslinie erheblich. <\/p>\n

Hier eine Schritt f\u00fcr Schritt Anleitung, oder auch hier ein Script auf GitLab<\/a>, welches alles automatisch erstellt.<\/p>\n

1. Neues Repository initialisieren<\/strong><\/p>\n

Ein neues leeres Repository wird angelegt und initialisiert.
\n„`
\nmkdir foxtrot-demo
\ncd foxtrot-demo
\ngit init
\n„`<\/p>\n

2. Erster Commit<\/strong><\/p>\n

Eine erste Datei wird angelegt und commitet.
\n„`
\necho „1. Initial content“ > file.txt
\ngit add file.txt
\n# Optional, wenn noch nicht gemacht
\n# git config –global user.email „you@example.com“
\n# git config –global user.name „Your Name“<\/p>\n

git commit -m „1. Initial commit“
\ngit log –oneline –graph –all –decorate
\n„`
\nGraph:
\n„`
\n# * 144b377 (HEAD -> master) 1. Initial commit
\n„`
\nDer `master`-Branch zeigt auf den ersten Commit.<\/p>\n

3. Remote anlegen und verbinden<\/strong><\/p>\n

Das lokale Repository wird als Bare Repository geklont und als Remote eingerichtet.
\n„`
\ncd ..
\ngit clone –bare foxtrot-demo foxtrot-remote.git
\ncd foxtrot-demo
\ngit remote add origin ..\/foxtrot-remote.git
\ngit remote -v
\n# Ergebnis:
\n# origin\t..\/foxtrot-remote.git\/ (fetch)
\n# origin\t..\/foxtrot-remote.git\/ (push)<\/p>\n

git push -u origin master
\ngit log –oneline –graph –all –decorate
\n„`
\nKeine Ver\u00e4nderung im Graph \u2014 er ist nur gespiegelt.<\/p>\n

Graph:
\n„`
\n* 144b377 (HEAD -> master, origin\/master) 1. Initial commit
\n„`<\/p>\n

4. Parallelen Klon als zweites Repository erstellen<\/strong>
\n„`
\ncd ..
\ngit clone foxtrot-remote.git foxtrot-other
\ncd foxtrot-other
\ngit log –oneline –graph –all –decorate
\n„`
\nGraph: identisch mit dem ersten Repository.<\/p>\n

„`
\n# * 144b377 (HEAD -> master, origin\/master, origin\/HEAD) 1. Initial commit<\/p>\n

„`<\/p>\n

5. \u00c4nderung im Remote-Klon durchf\u00fchren<\/strong><\/p>\n

Eine neue Zeile wird hinzugef\u00fcgt, commitet und ins Remote gepusht.
\n„`
\necho „2. Remote change“ >> file.txt
\ngit add file.txt
\ngit commit -m „2. Remote commit“
\ngit push origin master
\ngit log –oneline –graph –all –decorate
\n„`
\nGraph:
\n„`
\n* 59cdc2d (HEAD -> master, origin\/master, origin\/HEAD) 2. Remote commit
\n* 144b377 1. Initial commit
\n„`
\nJetzt enth\u00e4lt das Remote einen zus\u00e4tzlichen Commit.<\/p>\n

6. \u00c4nderung im ersten Repository lokal durchf\u00fchren<\/strong><\/p>\n

Zur\u00fcck im Haupt-Repository entsteht ein lokaler Commit ohne vorheriges Pull.
\n„`
\ncd ..\/foxtrot-demo
\necho „3. Local change“ >> file.txt
\ngit add file.txt
\ngit commit -m „3. Local commit“
\ngit log –oneline –graph –all –decorate
\n„`
\nGraph:
\n„`
\n* 5f8b0f4 (HEAD -> master) 3. Local commit
\n* 144b377 (origin\/master) 1. Initial commit
\n„`
\nDas lokale Repository wei\u00df noch nichts vom Remote-Commit. Die beiden Verl\u00e4ufe haben sich getrennt.<\/p>\n

7. Foxtrot-Merge erzeugen durch Pull<\/strong><\/p>\n

Ein normales `git pull` wird ausgef\u00fchrt.
\n„`
\ngit pull origin master
\n# Es wird diese ausf\u00fchrliche Meldung ausgegeben:
\nremote: Enumerating objects: 5, done.
\nremote: Counting objects: 100% (5\/5), done.
\nremote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 0 (from 0)
\nUnpacking objects: 100% (3\/3), 264 bytes | 52.00 KiB\/s, done.
\nFrom ..\/foxtrot-remote
\n * branch master -> FETCH_HEAD
\n 144b377..59cdc2d master -> origin\/master
\nhint: You have divergent branches and need to specify how to reconcile them.
\nhint: You can do so by running one of the following commands sometime before
\nhint: your next pull:
\nhint:
\nhint: git config pull.rebase false # merge
\nhint: git config pull.rebase true # rebase
\nhint: git config pull.ff only # fast-forward only
\nhint:
\nhint: You can replace „git config“ with „git config –global“ to set a default
\nhint: preference for all repositories. You can also pass –rebase, –no-rebase,
\nhint: or –ff-only on the command line to override the configured default per
\nhint: invocation.
\nfatal: Need to specify how to reconcile divergent branches.<\/p>\n

# wir erzwingen nun nur einmalig, f\u00fcr die Erzeugung des Foxtrot merge, man k\u00f6nnte es auch wie oben beschrieben mit
\n# git config pull.rebase false
\n# dauerhaft f\u00fcr das Repo einstellen oder auch Global mit
\n# git config –global pull.rebase false<\/p>\n

# also nur einmalig mit
\ngit pull –no-rebase origin master<\/p>\n

# Merge conflikt aufl\u00f6sen
\ngit add file.txt
\ngit commit -m „\u00e4nderungen wegen merge conflict“<\/p>\n

git log –oneline –graph –all –decorate
\n„`<\/p>\n

Graph:
\n„`
\n* 7469ab1 (HEAD -> master) \u00e4nderungen wegen merge conflict
\n|\\
\n| * 59cdc2d (origin\/master) 2. Remote commit
\n* | 5f8b0f4 3. Local commit
\n|\/
\n* 144b377 1. Initial commit
\n„`
\n
\nHier entsteht der eigentliche Foxtrot-Merge.<\/strong><\/p>\n

\t-Commit-ID 7469ab1 ist der Merge-Commit, der durch das Zusammenf\u00fchren des lokalen und des Remote-Zweigs entstanden ist.<\/p>\n

\t-Commit-ID 5f8b0f4 ist der lokale Commit auf deinem Branch vor dem Merge.<\/p>\n

\t-Commit-ID 59cdc2d ist der Remote-Commit, der parallel entstanden ist und im Remote-Repository liegt.<\/p>\n

\t-Commit-ID 144b377 ist der urspr\u00fcngliche Initial-Commit, von dem sowohl die lokalen als auch die Remote-\u00c4nderungen ausgegangen sind.<\/p>\n

Der Merge-Commit \u00a07469ab1<\/strong>\u00a0 hat zuerst den lokalen Commit 5f8b0f4<\/strong> als Parent und zweiten den Remote-Commit 59cdc2d<\/strong>. <\/p>\n

Dadurch wird die Hauptlinie der Historie (first parent) in die falsche Richtung gef\u00fchrt: Die erste Elternlinie<\/strong> folgt dem lokalen Commit, nicht<\/strong> dem Remote-Commit. <\/p>\n

Der Remote-Commit h\u00e4ngt nur noch seitlich am Verlauf und wird in der First-Parent-Historie nicht als direkter Fortschritt des Branches betrachtet. <\/p>\n

Dieses Muster ist charakteristisch f\u00fcr einen Foxtrot-Merge.<\/strong><\/p>\n

Infolgedessen f\u00fchrt eine Historienbetrachtung, die nur der ersten Elternlinie folgt (z. B. mit \u00a0git log –first-parent\u00a0), dazu, dass wichtige Remote-Commits im Verlauf verschwinden<\/strong> und die Nachvollziehbarkeit der Entwicklung erschwert wird<\/strong>.<\/p>\n

Oder auch mit:
\n„`
\ngit log –all –date-order –pretty=“%h|%p|%d“
\n7469ab1|5f8b0f4 59cdc2d| (HEAD -> master)
\n5f8b0f4|144b377|
\n59cdc2d|144b377| (origin\/master)
\n144b377||
\n„`
\n\"\"<\/p>\n

Ein:
\n„`
\ngit log –first-parent
\n# liefert
\ncommit 7469ab165b778faff283e480a5980dab821b08ef (HEAD -> master)
\nMerge: 5f8b0f4 59cdc2d
\nAuthor: Thomas Wenzlaff
\nDate: Thu Oct 16 18:56:30 2025 +0200<\/p>\n

\u00e4nderungen wegen merge conflict<\/p>\n

commit 5f8b0f431bda9ed15bcd4feb9df48a0cf9c0182f
\nAuthor: Thomas Wenzlaff
\nDate: Thu Oct 16 18:43:12 2025 +0200<\/p>\n

3. Local commit<\/p>\n

commit 144b37719658c67291ad14552c51f9767dcf6f72
\nAuthor: Thomas Wenzlaff
\nDate: Thu Oct 16 18:29:51 2025 +0200<\/p>\n

1. Initial commit
\n„`<\/p>\n

8. Merge ins Remote \u00fcbertragen<\/strong><\/p>\n

Damit wird der fehlerhafte Merge dauerhaft im Remote verankert. <\/p>\n

„`
\ngit push origin master
\ngit log –oneline –graph –all –decorate
\n„`
\nGraph:
\n„`
\n* 7469ab1 (HEAD -> master, origin\/master) \u00e4nderungen wegen merge conflict
\n|\\
\n| * 59cdc2d 2. Remote commit
\n* | 5f8b0f4 3. Local commit
\n|\/
\n* 144b377 1. Initial commit
\n„`<\/p>\n

Jetzt befindet sich der Foxtrot-Merge auch auf dem Remote. <\/p>\n

Die Commitreihenfolge ist invertiert \u2013 origin\/master<\/strong> verliert seine klare First-Parent-Linie.<\/p>\n

9. Kontrolle und Bewertung <\/strong><\/p>\n

Der Graph zeigt nun deutlich die Verzweigung mit verkehrter<\/strong> Merge-Reihenfolge. <\/p>\n

Wenn man den Verlauf mit `–first-parent` betrachtet, ist der Remote-Commit 59cdc2d nicht mehr sichtbar.
\n„`
\ngit log –first-parent
\ncommit 7469ab165b778faff283e480a5980dab821b08ef (HEAD -> master, origin\/master)
\nMerge: 5f8b0f4 59cdc2d
\nAuthor: Thomas Wenzlaff
\nDate: Thu Oct 16 18:56:30 2025 +0200<\/p>\n

\u00e4nderungen wegen merge conflict<\/p>\n

commit 5f8b0f431bda9ed15bcd4feb9df48a0cf9c0182f
\nAuthor: Thomas Wenzlaff
\nDate: Thu Oct 16 18:43:12 2025 +0200<\/p>\n

3. Local commit<\/p>\n

commit 144b37719658c67291ad14552c51f9767dcf6f72
\nAuthor: Thomas Wenzlaff
\nDate: Thu Oct 16 18:29:51 2025 +0200<\/p>\n

1. Initial commit
\n„`
\nDadurch wird die Analyse von Release-Historien oder automatischen Deployments schwierig. <\/p>\n

Mit dieser visualisierten Schrittfolge ist nachvollziehbar, wie ein Foxtrot-Merge<\/strong> entsteht \u2013
\ndurch gleichzeitige lokale Commits und nachfolgendes einfaches `git pull`, das automatisch einen Merge in falscher Elternreihenfolge erzeugt.
\n
\nWas kann man aber nun tun? Wie kann man Foxrot-Merge verhindern?<\/strong><\/p>\n

Die zuverl\u00e4ssigste Methode ist ein Pre-Receive-Hook auf dem Git-Server, der Foxtrot-Merges beim Push automatisch blockiert.
\nGitLab z.B. hat ein offenes Feature-Request f\u00fcr native Foxtrot-Merge-Pr\u00e4vention.<\/p>\n

Um Foxtrot-Merges in Teams zu vermeiden, ben\u00f6tigst du klare Richtlinien, die technische Ma\u00dfnahmen mit organisatorischen Best Practices kombinieren.<\/p>\n

Rebase-Workflow etablieren, als Team-Richtlinie: Immer rebase verwenden<\/strong>, wie auch oben von git ausgegeben wird.<\/p>\n

git config –global pull.rebase true<\/p>\n

# Oder pro Repository<\/p>\n

git config pull.rebase true<\/p>\n

Dies erzwingt automatisch \u00a0git pull –rebase\u00a0<\/strong> statt dem gef\u00e4hrlichen \u00a0git pull<\/strong>.<\/p>\n

Oder
\n# Im Repository konfigurieren<\/p>\n

git config merge.ff only<\/p>\n

Dies erlaubt nur Fast-Forward-Merges, wodurch Foxtrot-Merges unm\u00f6glich werden.<\/p>\n

Best Practices:<\/strong><\/p>\n

– Niemals<\/strong> \u00a0git pull\u00a0 ohne \u00a0–rebase<\/strong>\u00a0 auf Hauptbranches verwenden<\/p>\n

– Niemals<\/strong> \u00a0git merge master\u00a0 in lokale Branches ausf\u00fchren, wenn diese auf \u00a0master\u00a0 gemerged werden sollen<\/p>\n

– Regelm\u00e4\u00dfig<\/strong> \u00a0git fetch<\/strong>\u00a0 gefolgt von \u00a0git rebase origin\/master<\/strong>\u00a0 verwenden<\/p>\n

– Pull-Request-Workflow konsequent einhalten<\/p>\n

Grundlegende Team-Regeln<\/strong><\/p>\n

Niemals direkt auf Master\/Main arbeiten:\u2028 Entwickler sollten ausschlie\u00dflich auf Feature-Branches arbeiten und nie direkt Commits auf \u00a0master\u00a0 oder \u00a0main\u00a0 erstellen. Dies verhindert die Hauptursache von Foxtrot-Merges \u2013 lokale \u00c4nderungen auf dem Hauptbranch gefolgt von einem \u00a0git pull\u00a0.<\/p>\n

Pull-Request-Workflow durchsetzen: \u2028Alle \u00c4nderungen m\u00fcssen \u00fcber Pull Requests in den Hauptbranch gelangen. Konfiguriere Branch-Protection-Rules, die direkte Pushes auf \u00a0master\u00a0 blockieren und Code-Reviews erzwingen.<\/p>\n

Rebase statt Merge f\u00fcr Feature-Branch-Updates:\u2028 Wenn Feature-Branches mit dem aktuellen \u00a0master\u00a0 synchronisiert werden m\u00fcssen, verwende ausschlie\u00dflich<\/em> \u00a0git rebase<\/strong>\u00a0, nicht \u00a0git merge\u00a0:
\n
\ngit fetch origin
\ngit rebase origin\/master<\/strong><\/p>\n

Diese Regel h\u00e4lt die Historie linear und verhindert unn\u00f6tige Merge-Commits.<\/p>\n

Hier im Repo<\/a> das Script, das alle Schritte automatisch ausf\u00fchrt.<\/p>\n","protected":false},"excerpt":{"rendered":"

Der Foxtrott-Merge ist wie Tanzen mit Git \u2013 nur dass hier nicht die F\u00fc\u00dfe stolpern, sondern die Commits. Beide starten synchron, drehen sich elegant umeinander, bis einer pl\u00f6tzlich im falschen Takt mitschreibt. W\u00e4hrend T\u00e4nzer das charmant \u00fcberspielen, verursacht es in Git eine chaotische Merge-Historie. Der Foxtrott bringt Schwung ins Parkett, der Foxtrott-Merge dagegen Unordnung ins … <\/p>\n

\u201eVermeide git Foxtrot-Merge – Schritt f\u00fcr Schritt Anleitung mit L\u00f6sung\u201c <\/span>weiterlesen<\/a><\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[220,4176,2172,1023],"tags":[2184,6214,6240,6237,325,6238,6239,6241],"class_list":["post-22891","post","type-post","status-publish","format-standard","hentry","category-anleitung","category-git","category-kali-linux-2","category-raspberry-pi","tag-anleitung","tag-best-practice","tag-foxtrot","tag-foxtrot-merge","tag-git","tag-merge","tag-pull","tag-tanzen-loesung"],"_links":{"self":[{"href":"http:\/\/blog.wenzlaff.de\/index.php?rest_route=\/wp\/v2\/posts\/22891","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/blog.wenzlaff.de\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/blog.wenzlaff.de\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/blog.wenzlaff.de\/index.php?rest_route=\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"http:\/\/blog.wenzlaff.de\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=22891"}],"version-history":[{"count":0,"href":"http:\/\/blog.wenzlaff.de\/index.php?rest_route=\/wp\/v2\/posts\/22891\/revisions"}],"wp:attachment":[{"href":"http:\/\/blog.wenzlaff.de\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=22891"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/blog.wenzlaff.de\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=22891"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/blog.wenzlaff.de\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=22891"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}