Resolución de conflictos de Git merge


Se ha clonado un repositorio Git en varias máquinas locales de desarrolladores. Se han realizado algunos cambios en el código del repositorio. Ahora estamos recibiendo el error:

error: Your local changes to the following files would be overwritten by merge:

        public_html/sites/file
        public_html/sites/file1.txt
        public_html/sites/file2.txt
Please, commit your changes or stash them before you can merge.
Aborting

He leído bastantes hilos en línea, y se han sugerido varias opciones diferentes. Se ejecutó un enfoque:

 git stash
 git pull
 git stash pop

Creo que entiendo el principio básico del escondite. Mi pregunta es, ¿es esta una buena solución, y podría toparme con algún problema usando este enfoque? Tengo un entendimiento razonable de desarrollo web en general, pero soy un usuario bastante básico de Git y no tendría mucha capacidad para salir de problemas en este punto.

Author: g_thom, 2011-10-08

4 answers

git stash es perfectamente legítimo, aunque como dijo Greg, por alguna razón arreglar los conflictos puede ser extraño. Pero todavía son arreglables, en realidad no fubar nada. El comando que sé para volver a aplicar el alijo es git stash apply, aunque pop puede ser una alternativa de la que no estoy al tanto (o podría hacer algo diferente, no lo sé, por lo que probablemente quieras usar apply.)

¿Hay alguna razón por la que no desee confirmar esos cambios antes de fusionarlos? En general, eso es lo correcto.

Otra opción es:

git stash
git checkout -b newwork
git stash apply
git commit ...

Esto crea una nueva rama, que le permitirá obtener su maestro actualizado sin conflictos, (checkout master de nuevo, luego tire o fetch + merge). Luego puede fusionar su rama de nuevo con (mientras todavía está en master) git merge newwork. Puede resolver los conflictos en master, mientras conserva el trabajo en newwork sin ningún conflicto. Esto es un poco más seguro si te preocupan los conflictos que realmente arruinan las cosas, pero en general, los conflictos son solo parte del proceso, así que no te preocupes demasiado por ellos.

 15
Author: kylben,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2013-01-22 13:18:50

Es una buena práctica siempre confirmar cualquier cambio local antes de extraer (fusionar) nuevo código. Si no confirmas, entonces Git no sabe cómo quieres administrar tus cambios locales. Combinar solo con un árbol de trabajo limpio.

Puede haber conflictos en la fusión, debido a que los mismos archivos se cambian localmente y por otra persona. En mi experiencia, resolver conflictos desde una operación real merge es un poco más simple que resolver el mismo conflicto desde un alijo operación pop .

 6
Author: Greg Hewgill,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2011-10-08 02:53:51

Tengo otra solución:

git reset --hard FETCH_HEAD

Funciona en casi todos los casos.

 4
Author: Narga,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2015-07-09 08:01:49

Primero debes:

git checkout -- public_html/sites/file
git checkout -- public_html/sites/file1.txt
git checkout -- public_html/sites/file2.txt

Siguiente paso:

git pull origin master
 2
Author: MrBii,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2014-04-17 11:14:21