Git – “no se puede bloquear la referencia está en” en git Pull

Veo el siguiente error cuando hago git pull en mi terminal en intellij. Varios desarrolladores actualizan constantemente el proyecto y estoy seguro de que algo no está sincronizado, pero no puedo entender qué es.

error: cannot lock ref 'refs/remotes/origin/feature/SOMETHING-1234': is at e131d16d4b4b8c32e3d16d28559baf2e4d18b012 but expected 090916d9bee669944a2ea55703f25a4ebee7d51a
 ! 090916d9b..e131d16d4  feature/SOMETHING-1234 -> origin/feature/SOMETHING-1234  (unable to update local ref)

¿Cuál podría ser el problema aquí? Cómo puedo solucionar esto ? La rama de características anterior ha sido creada por otro desarrollador y no quiero eliminarla.

Nota: esto es un duplicado, pero la otra pregunta no tiene una respuesta aceptada, así que estoy publicando una aquí. El problema ocurre porque alguien creó una rama (feature/SOMETHING-1234 en su ejemplo anterior) que difiere solo en caso de un nombre que su Git ya recogió. Por ejemplo, es posible que tenga feature/something-1234 o FEATURE/SOMETHING-1234mientras que ahora tienen feature/SOMETHING-1234.

Git cree que los nombres que difieren solo en mayúsculas y minúsculas, como a contra Ason diferentes nombres. esto funciona correctamente Algo de tiempo. Falla en algunos sistemas operativos¹ Algo de tiempo. Cuando falla, como es en su caso, tiene síntomas extraños como el que está viendo ahora.

En este caso, una forma de posiblemente curarlo es eliminar el archivo (local) .git/refs/remotes/origin/feature/something-1234—puede escribirlo todo en minúsculas, independientemente de las partes que tengan mayúsculas; vea la nota al pie 1—justo antes de correr git fetch. Su Git volverá a crear esto con el caso proporcionado por el otro Git. Tenga en cuenta, sin embargo, que el problema puede reaparecer, tal vez incluso de inmediato, especialmente si el otro Git es uno que poder almacenar ambos nombres (por ejemplo, ambos feature/something-1234 y feature/SOMETHING-1234) en todo momento.

Para curar el problema de forma más permanente, es necesario borrar el nombre duplicado excepto para el caso en el otro Git. Es decir, si un GitHub Git tiene ramas nombradas tanto feature/SOMETHING-1234 y feature/something-1234, usted y sus colegas deben reunirse y acordar cuál de estos dos nombres conservar y cuál eliminar. Luego puede y debe eliminar el “incorrecto” y asegurarse de nunca volver a crearlo.

(Creo que hay trabajo en curso en Git que solucionará este problema para todos, pero aún no se ha publicado).

¹Técnicamente, este es un problema específico del sistema de archivos en estos días, en lugar de un problema específico del sistema operativo. Sin embargo, normalmente ocurre en los sistemas de archivos de Windows y MacOS, que están configurados para conservar mayúsculas y minúsculas, pero para plegar mayúsculas y minúsculas. Es decir, si crea un archivo llamado ReadMeluego solicite al sistema que abra un archivo llamado readme o READMEabre el existente ReadMe archivo.

Otros sistemas de archivos, incluidos los habituales que se utilizan en hosts Linux, como los que ejecutan GitHub, tratan readme, ReadMey README como tres archivos diferentes. Por lo tanto, estos sistemas pueden almacenar y almacenarán los tres archivos al mismo tiempo. Los sistemas de archivos plegables en Windows y MacOS literalmente no poder almacenar tres de estos archivos.

Actualmente, Git utiliza un esquema híbrido, en el que árbitros o referencias—sucursal, etiqueta y otros nombres— se almacenan en uno o ambos de dos lugares: un archivo de tabla de texto sin formato simple que tiene todas las referencias en una línea junto con su ID de hash, o una ID de hash por archivo, con el nombre del archivo. nombre coincidiendo con el nombre de referencia. Cuando las referencias difieren solo en mayúsculas y minúsculas, el mecanismo de almacenamiento por archivo solo funciona correctamente en sistemas de archivos que pueden almacenar ambos nombres. Sin embargo, el mecanismo de un archivo grande funciona correctamente incluso en el sistema de archivos habitual de Windows y MacOS, ya que todas las entradas están en un archivo llamado .git/packed-refs.

Tenga en cuenta que si aparece una referencia en ambos .git/packed-refs y un archivo individual, la versión del archivo individual anula la .git/packed-refs versión.

Abrí la terminal y uso el siguiente comando y funciona para mí. Después de escribir este comando, sigue tirando de todas las ramas sin error.

git remote prune origin