No dudes en divulgar nuestra web y códigos con tus amigos, apóyanos para aumentar esta comunidad.
Solución:
Lo que está sucediendo actualmente es que tiene un determinado conjunto de archivos, que ha intentado fusionar anteriormente, pero arrojaron conflictos de fusión. Idealmente, si uno tiene un conflicto de fusión, debería resolverlo manualmente y confirmar los cambios usando git add file.name && git commit -m "removed merge conflicts". Ahora, otro usuario ha actualizado los archivos en cuestión en su repositorio y ha enviado sus cambios al repositorio ascendente común.
Sucede que sus conflictos de combinación de (probablemente) la última confirmación no se resolvieron, por lo que sus archivos no se combinan correctamente y, por lo tanto, el U(unmerged) marca para los archivos. Así que ahora, cuando hagas un git pull, git está arrojando el error, porque tiene alguna versión del archivo, que no se ha resuelto correctamente.
Para resolver esto, tendrá que resolver los conflictos de fusión en cuestión y agregar y confirmar los cambios antes de poder hacer un git pull.
Muestra de reproducción y resolución del problema:
# Note: commands below in format `CUURENT_WORKING_DIRECTORY $ command params`
Desktop $ cd test
Primero, creemos la estructura del repositorio
test $ mkdir repo && cd repo && git init && touch file && git add file && git commit -m "msg"
repo $ cd .. && git clone repo repo_clone && cd repo_clone
repo_clone $ echo "text2" >> file && git add file && git commit -m "msg" && cd ../repo
repo $ echo "text1" >> file && git add file && git commit -m "msg" && cd ../repo_clone
Ahora estamos en repo_clone, y si haces un git pull, arrojará conflictos
repo_clone $ git pull origin master
remote: Counting objects: 5, done.
remote: Total 3 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (3/3), done.
From /home/anshulgoyal/Desktop/test/test/repo
* branch master -> FETCH_HEAD
24d5b2e..1a1aa70 master -> origin/master
Auto-merging file
CONFLICT (content): Merge conflict in file
Automatic merge failed; fix conflicts and then commit the result.
Si ignoramos los conflictos en el clon y hacemos más confirmaciones en el repositorio original ahora,
repo_clone $ cd ../repo
repo $ echo "text1" >> file && git add file && git commit -m "msg" && cd ../repo_clone
Y luego hacemos un git pull, obtenemos
repo_clone $ git pull
U file
Pull is not possible because you have unmerged files.
Please, fix them up in the work tree, and then use 'git add/rm '
as appropriate to mark resolution, or use 'git commit -a'.
Tenga en cuenta que el file ahora está en un estado no fusionado y si hacemos un git status, podemos ver claramente lo mismo:
repo_clone $ git status
On branch master
Your branch and 'origin/master' have diverged,
and have 1 and 1 different commit each, respectively.
(use "git pull" to merge the remote branch into yours)
You have unmerged paths.
(fix conflicts and run "git commit")
Unmerged paths:
(use "git add ..." to mark resolution)
both modified: file
Entonces, para resolver esto, primero debemos resolver el conflicto de fusión que ignoramos anteriormente
repo_clone $ vi file
y establezca su contenido en
text2
text1
text1
y luego agréguelo y confirme los cambios
repo_clone $ git add file && git commit -m "resolved merge conflicts"
[master 39c3ba1] resolved merge conflicts
Está intentando agregar una nueva confirmación más en su rama local mientras su directorio de trabajo no está limpio. Como resultado, Git se niega a hacer el tirón. Considere los siguientes diagramas para visualizar mejor el escenario:
remoto: A <- B <- C <- D
local: A <- B *(* indica que tiene varios archivos que han sido modificados pero no confirmados).
Hay dos opciones para afrontar esta situación. Puede descartar los cambios en sus archivos o retenerlos.
Opción uno: deseche los cambios
Puedes usar git checkout para cada archivo no combinado, o puede usar git reset --hard HEAD para restablecer todos los archivos en su rama a HEAD. Por cierto, HEAD en su sucursal local es B, sin asterisco. Si elige esta opción, el diagrama se convierte en:
remoto: A <- B <- C <- D
local: A <- B
Ahora, cuando tira, puede adelantar su rama con los cambios de master. Después de tirar, su rama se vería como maestra:
local: A <- B <- C <- D
Opción dos: conservar los cambios
Si desea mantener los cambios, primero querrá resolver cualquier conflicto de combinación en cada uno de los archivos. Puede abrir cada archivo en su IDE y buscar los siguientes símbolos:
<<<<<<< CABEZA
// tu versión del código
=======
// la versión del código del control remoto
>>>>>>>
Git te presenta dos versiones de código. El código contenido dentro de los marcadores HEAD es la versión de su sucursal local actual. La otra versión es la que viene del control remoto. Una vez que haya elegido una versión del código (y haya eliminado el otro código junto con los marcadores), puede agregar cada archivo a su área de preparación escribiendo git add. El último paso es confirmar su resultado escribiendo git commit -m con un mensaje apropiado. En este punto, nuestro diagrama se ve así:
remoto: A <- B <- C <- D
local: A <- B <- C '
Aquí he etiquetado la confirmación que acabamos de hacer como C ‘porque es diferente de la confirmación C en el control remoto. Ahora, si intenta tirar, obtendrá un error que no es de avance rápido. Git no puede reproducir los cambios en el control remoto en su rama, porque tanto su rama como el control remoto han divergido del compromiso B del ancestro común. En este punto, si desea extraer, puede hacer otro git merge, o git rebase su rama en el control remoto.
Obtener un dominio de Git requiere ser capaz de comprender y manipular listas enlazadas unidireccionales. Espero que esta explicación le ayude a pensar en la dirección correcta sobre el uso de Git.
Si no desea fusionar los cambios y aún desea actualizar su local, ejecute:
git reset --hard HEAD
Esto restablecerá su local con HEAD y luego extraerá su control remoto usando git pull.
Si ya ha realizado su fusión localmente (pero aún no ha pasado a remoto) y desea revertirlo también:
git reset --hard HEAD~1