Jan
Ich habe einen Master- und einen Testzweig meiner (Web-)Anwendung. Diese Projekte sind fast gleich, außer einer Datei, die die Anwendung einrichtet, sagen wir “setup”.
Immer wenn ich einen Zweig mit dem anderen zusammenführe, möchte ich, dass dieser Zweig seine Version des Setups behält. Das heißt, git sollte nicht versuchen, die Änderungen an dieser Datei zusammenzuführen.
Ich folgte dem Anleitung aus dem Pro Git-Buch und erstellte eine .gitattributes-Datei mit der Zeile “setup merge=ours”. Dies funktioniert jedoch nicht – weder bei Fast-Forward-Merges noch wenn ich Konflikte einführe.
(Um genau zu sein:
$: mkdir gitest
$: cd gittest
$: git init
$: echo "setup merge=ours" >> .gitattributes
$: echo "master" >> setup
$: git add setup .gitattributes
$: git commit -a -m ...
$: git branch test
$: git checkout test
$: echo "test" >> setup
$: git commit -a -m ...
$: git checkout master
$: git merge test
Erwartetes Ergebnis: setup enthält das Wort „master“, stattdessen führt git eine ff-Zusammenführung durch und setup ist „test“.)
Jorge E. Cardona
Ich hatte den gleichen Fehler und er kann gelöst werden, indem einfach ein “unserer” Merge-Treiber in .git/config definiert wird:
[merge "ours"]
name = "Keep ours merge"
driver = true
Da true immer 0 zurückgibt, wird die temporäre Datei mit dem aktuellen Status nicht geändert und bleibt die endgültige Version.
Hier können Sie mehr über Merge-Treiber lesen: http://www.kernel.org/pub/software/scm/git/docs/gitattributes.html#_defining_a_custom_merge_driver
Nachtrag:
Dies funktioniert immer dann, wenn der Treiber tatsächlich aufgerufen wird, und dies scheint nur dann der Fall zu sein, wenn Commits dieselben Dateien ändern (git das Merge-Attribut). Bei Änderungen in einem einzelnen Zweig wird der Treiber nicht aufgerufen.
Ich stellte fest, dass, wenn ich die Dateien in beiden Zweigen änderte und die Änderungen an jedem Zweig festlegte und dann die Zusammenführung versuchte, der Zusammenführungstreiber aufgerufen und auf meine abgehört wurde .gitattributes was angibt merge=ours. Danach unterscheiden sich die beiden Dateien immer in den beiden Zweigen und daher wird der Merge-Treiber immer aufgerufen, sodass ich keinen benutzerdefinierten Merge-Treiber benötigte, der die Datei berührt. Beides musste zunächst nur modifiziert werden.
Uwe Kleine-König
Der Merge-Treiber wird nur in nicht trivialen Fällen aufgerufen, dh wenn sowohl Master als auch Test Setup berührt haben (und Sie den Merge-Treiber definieren müssen ours Erste):
git init
git config merge.ours.name '"always keep ours" merge driver'
git config merge.ours.driver 'touch %A'
echo "setup merge=ours" >> .gitattributes
echo "master" >> setup
git add setup .gitattributes
git commit -a -m ...
git branch test
git checkout test
echo "test" >> setup
git commit -a -m ...
git checkout master
echo "more content" >> setup
git commit -a -m ...
git merge test
Allerdings frage ich mich, ob es überhaupt sinnvoll ist, Setup im Repository zu haben. Wenn Sie es wirklich unter Versionskontrolle haben möchten, können Sie Submodule oder die Subtree-Merge-Strategie verwenden, um gemeinsame Dateien synchron zu halten.
Haben Sie ein schmieriges sauberes Skript anstelle von separaten Zweigen. Das Skript kann je nach Computer unterschiedlich sein.
9314700cookie-check.gitattributes & individuelle Zusammenführungsstrategie für eine Dateiyes
mögliches Duplikat von Wie weise ich Git an, immer meine lokale Version für konfliktbehaftete Zusammenführungen einer bestimmten Datei auszuwählen?
– Karl Bielefeldt
29. März 2011 um 1:44 Uhr
Ich habe die Git-Quelle durchgesehen und kann nicht sehen, wie
merge=oursmal gearbeitet. Ich glaube, jemand hat das geschrieben, ohne es zu versuchen. Diese andere Antwort bietet eine kompliziertere Lösung, aber mit dem Bonus, dass sie tatsächlich zu funktionieren scheint.– Karl Bielefeldt
29. März 2011 um 1:47 Uhr
Das scheint tatsächlich zu funktionieren! Danke Karl. Als leichte Modifikation dieser Antwort: Einfach “exit 0” als Merge-Treiber zu setzen, ist einfacher als ein dediziertes Bash-Skript, das genau das tut.
– Jan
29. März 2011 um 15:21 Uhr