.gitattributes y estrategia de fusión individual para un file

Tengo un master y una twig de testing de mi aplicación (web). Estos proyectos son casi los mismos, a exception de un file que configura la aplicación, digamos "configuration".

Cada vez que fusiono una twig en la otra, me gustaría que esa twig mantenga su versión de configuration. Es decir, git no debería intentar fusionar los cambios en ese file.

Seguí las instrucciones del libro de progit (http://progit.org/book/pt-br/ch7-2.html) y creé un file .gitattributes, con la línea "setup merge = ours". Sin embargo, esto no funciona, ni con fusiones rápidas, no si presento conflictos.

(Para ser preciso:

$: 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 

Resultado esperado: la installation contiene la palabra "maestro", en cambio, Git realiza una combinación FF y la configuration es "testing".

Tuve el mismo error y se puede resolver simplemente definiendo un controller de fusión "nuestro" en .git / config:

 [merge "ours"] name = "Keep ours merge" driver = true 

Como true siempre devuelve 0, el file temporal que contiene el estado actual no cambiará y se mantendrá como la versión final.

Puede leer más sobre el controller de combinación aquí: http://www.kernel.org/pub/software/scm/git/docs/gitattributes.html#_defining_a_custom_merge_driver

Apéndice:

Esto funciona cada vez que se llama realmente al controller y esto parece ocurrir solo cuando hay commits cambiando los mismos files (git el atributo merge). Si hay cambios en una sola twig, no se llamará al controller.

Descubrí que si modificaba los files en ambas twigs y confirmaba las modificaciones en cada twig, y ​​luego probaba la fusión, invocaba el controller de fusión y escuchaba mis .gitattributes que especifican merge=ours . Después de esto, los dos files siempre difieren en las dos twigs y, por lo tanto, siempre se invocará el controller de combinación, por lo que no es necesario que tenga un controller de combinación personalizado que toque el file. Solo fue necesario modificar ambos al principio.

El controller de combinación solo se invoca en casos no triviales, es decir, si tanto el maestro como la testing han tocado la configuration (y primero debe definir el controller de combinación ours ):

 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 

Habiendo dicho eso, me pregunto si es sensato tener una configuration en el repository. Si realmente lo quiere bajo el control de la versión, podría usar submodules o la estrategia de fusión del subtree para mantener los files comunes sincronizados.

Tener una secuencia de commands borrón y count nueva en lugar de twigs separadas. El script puede ser diferente dependiendo de la máquina en la que se encuentre.