Ich habe einen Git-Zweig (z. B. den Hauptzweig) und möchte einen anderen Entwicklungszweig einbinden. Oder muss ich das?
Um zu entscheiden, ob ich diesen Zweig wirklich zusammenführen möchte, würde ich gerne eine Art Vorschau sehen, was die Zusammenführung bewirken wird. Vorzugsweise mit der Möglichkeit, die Liste der Commits zu sehen, die angewendet werden.
Bislang ist das Beste, was mir einfällt merge --no-ff --no-commit und dann diff HEAD .
Ich möchte den Git-Merge-Befehl nicht als Vorstufe zur Überprüfung widersprüchlicher Dateien verwenden. Ich möchte keine Zusammenführung durchführen, sondern mögliche Probleme vor der Zusammenführung erkennen - Probleme, die die automatische Zusammenführung vor mir verbergen könnte. Die Lösung, nach der ich gesucht habe, ist, wie ich Git dazu bringen kann, eine Liste von Dateien auszuspucken, die in beiden Zweigen geändert wurden, die in der Zukunft zusammengeführt werden, relativ zu einem gemeinsamen Vorgänger. Sobald ich diese Liste habe, kann ich andere Dateivergleichstools verwenden, um die Dinge weiter auszukundschaften. Ich habe mehrfach gesucht und noch immer nicht gefunden, was ich in einem nativen Git-Befehl suche.
Hier ist meine Lösung, falls sie jemandem da draußen hilft:
In diesem Szenario habe ich einen Zweig namens QA, der seit der letzten Produktionsversion viele Änderungen enthält. Unsere letzte Produktionsversion ist mit "15.20.1" gekennzeichnet. Ich habe einen weiteren Entwicklungszweig namens new_stuff, den ich mit dem QA-Zweig zusammenführen möchte. Sowohl QA als auch new_stuff verweisen auf Commits, die dem Tag 15.20.1 "folgen" (wie von gitk gemeldet).
git checkout QA
git pull
git diff 15.20.1 --name-only > QA_files
git checkout new_stuff
git pull
git diff 15.20.1 --name-only > new_stuff_files
comm -12 QA_files new_stuff_filesHier sind einige Diskussionen, die aufzeigen, warum ich an diesen speziellen Dateien interessiert bin:
Wie kann ich Git Merge vertrauen?
https://softwareengineering.stackexchange.com/questions/199780/how-far-do-you-trust-automerge
CodeJaeger ist eine Gemeinschaft für Programmierer, die täglich Hilfe erhalten..
Wir haben viele Inhalte, und Sie können auch Ihre eigenen Fragen stellen oder die Fragen anderer Leute lösen.
22 Stimmen
Ich würde nur
git mergeygit reset --keep HEAD@{1}wenn mir das Ergebnis nicht gefällt.4 Stimmen
Beachten Sie, dass die Liste der Commits mit ihrem Diff nicht notwendigerweise die ganze Geschichte erzählt - wenn die Zusammenführung nicht trivial ist, und besonders wenn es Konflikte gibt, könnte das tatsächliche Ergebnis der Zusammenführung ein wenig interessant sein.
0 Stimmen
Das Problem dabei ist, dass man nur schwer erkennen kann, welche Änderungen tatsächlich vorgenommen wurden.
2 Stimmen
Ihre ursprüngliche Methode tut genau das. Der Punkt meines Kommentars ist, dass es zwar schön und gut ist, einzelne Diffs zu betrachten, aber bei einem komplexen Merge kann es zu überraschenden Ergebnissen kommen, selbst wenn alle zusammengeführten Commits unabhängig voneinander gut sind.
3 Stimmen
@Jan: Aus einigen Gründen,
git reset --keep HEAD@{1}zurückgegebenfatal: Cannot do a keep reset in the middle of a merge.Hilfe?0 Stimmen
@Siku-Siku.Com: Der Befehl geht davon aus, dass die Zusammenführung abgeschlossen und das Ergebnis commited wurde. Ich glaube, die Meldung über Konflikte sagt Ihnen sowohl, wie Sie die Zusammenführung beenden als auch wie Sie sie abbrechen können.
1 Stimmen
Mögliche Duplikate von Gibt es eine Option git-merge --dry-run?
11 Stimmen
Warum gibt es nicht eine
--previewOption in git-merge?0 Stimmen
Ich glaube, die korrekteste Antwort, die ich auf diese Frage gesehen habe, ist hier: stackoverflow.com/a/6283843/1695680