Se pierden cambios de Git, ¿por qué?

Question

Nuestro equipo de desarrollo está usando git y hemos perdido cambios en los archivos al menos dos veces recientemente. Estamos utilizando repositorios privados de Github.

En el caso actual, podemos volver a leer los registros en Github y ver algunas actualizaciones que hice en un archivo. Más tarde, otro miembro del equipo cambió una parte diferente del archivo y parece que destruyó mis cambios. Todavía los tengo a nivel local.

¿Alguien ha experimentado esto? Cualquier causa o solución?

Yo no creo Alguien está haciendo cualquier cambio o algo sofisticado, simplemente tirando y empujando.

Answer 1

Aunque no puedo hablar de su problema específico, lo que puedo decir es que ayer experimenté algo muy similar. Tenía un diseñador rebuscando algunas URL en el código y actualizando algunas imágenes en una aplicación de iPhone en la que estaba terminando, y no me lo contó. Empujé mis cambios que había hecho que tocó en algunos de estos archivos también (puntos diferentes sin embargo), y rechazó como un avance rápido no local. Así que tiré, obtuve conflictos, los resolví y empujé. Problema resuelto. Sin embargo, deshace sus cambios de código en el proceso.

Una cosa que he agregado recientemente a mi flujo de trabajo debido a un problema muy similar al que experimenté ayer, en un repositorio privado de github; es esconder mis cambios que estoy a punto de comprometer, retirar del repositorio y aplicar mi escondite. Si hay conflictos, resuélvalos, luego presiona.

Answer 2

Algo similar le sucedió a mi equipo también.

Lección aprendida: cuando tira, debe tener cuidado con los conflictos de fusión. Si hay conflictos en la extracción, git no realiza cambios fusionados en su repositorio local y debe hacerlo después de resolver el conflicto. De lo contrario, al presionar, sobrescribirá el repositorio remoto con su copia local que NO contiene cambios de personas en el control remoto antes de tirar. Esto explica algunos 'archivos extraños' que puede ver no confirmados, pero está seguro de que no son sus cambios: esto es una indicación de un conflicto de combinación en 'extracción' y - nuevamente - . Debe confirmar estos cambios en local después de resolver el conflicto y luego presione al control remoto.

Si no tiene conflictos al fusionarse en la extracción, no surgen problemas con los cambios perdidos. Debido a que git recupera, se fusiona y se compromete con su copia local, y 'push', propaga estos cambios fusionados a remoto.

Answer 3

He tenido problemas similares donde en el registro general puedo ver los cambios que hice en un archivo, pero cuando reviso el registro específico del archivo, esos cambios no aparecen, solo los de mi compañero de trabajo. Estoy bastante seguro de que esto se debe a que mi compañero de trabajo arruinó la fusión de alguna manera ... Pero todavía me gustaría que esto apareciera en el registro.

Answer 4

Me gustaría agregar mis pocas palabras. Últimamente noté un comportamiento muy extraño en git. Mi equipo tenía grandes problemas por eso. No sé cómo sucedió, pero parece que la historia en mi repositorio es inconsistente.

pequeña ilustración:

cometer XXXXXXXX: se añadió

Línea "bar" para presentar foo.

... trabajo en progreso ...

un montón de confirmaciones más tarde (digamos 100):

Línea "barra" ya no existe en este archivo !!

Investigación:

1.I inspeccionó la historia del archivo con:

git log foo foo y gitk

que incluso en comparación manchas consecutiva de cada commit con la herramienta externa (gvimdiff). Es interesante que encontré dos confirmaciones (llamémoslas YYY y ZZZ). Blob de archivo foo desde commit YYY consistía en "barra" pero blob de ZZZ no.
Cuando inspeccioné commitdiffs de esas confirmaciones con gitk (y gitweb) noté que no hay ninguna operación de eliminar la "barra" de línea en ZZZ. ¿Es posible que haya algún compromiso intermedio y se disuelva en el aire?
O tal vez confirme que ZZZ acaba de eliminar mi línea y la herramienta diff incrustada en git (o gitk) está rota?

2.He buscó para las confirmaciones que podría eliminar esta línea con "git log -S", algo así como:

git log -S'bar' - foo

Resulta que esta línea nunca fue eliminado De hecho, fue agregado dos veces. La primera vez que se introdujo en el proyecto y la segunda vez cuando se volvió a agregar como una corrección de errores urgente.

Me gusta mucho usar git e incluso persuadí a algunos amigos a usarlo, pero si ese tipo de magia continúa sucediendo, tendré que empezar a buscar otras alternativas.

Answer 5

Supongo que hay diferentes configuraciones entre los committers, tal vez alguien falta una configuración autocrlf.

Git de alguna manera considera completamente diferentes dos revisiones del mismo archivo, sobrescribiendo el antiguo con los cambios más recientes de otra rama.

Si una combinación de tres vías (recursiva predeterminada) encuentra dos elementos secundarios completamente diferentes (es decir, debido a una mala configuración de CRLF), el resultado fusionado será el más reciente, sin conflictos.

Answer 6

Tuvimos el mismo problema: Dev A hizo un cambio. Dev B hizo un cambio a otra cosa. Después de que Dev B presionó sus cambios, el cambio que Dev A hizo "desapareció". El cambio que Dev B hizo fue hace unas semanas, pero parecía que nadie había notado la pérdida de los cambios de Dev A hasta ahora.

La verdadera razón por la que el cambio "desapareció" fue que la herramienta que estábamos usando para ver el historial (TFS) estaba mostrando una versión incorrecta del historial. Cuando miramos con diferentes herramientas (SmartGit y SourceTree) vimos lo que realmente sucedió: alguien había sobrescrito el cambio al intentar solucionar un conflicto de fusión y la sobrescritura estaba a la vista.

Por lo tanto, no era git que estaba perdiendo cambios, era la herramienta que estábamos usando y nos daba una vista falsa de la historia. Solo algo para tener en cuenta.

Hemos estado utilizando git desde hace un año y el 99% del tiempo que algo "salió mal" con git, en realidad fue causado por alguien que realmente no entendía git.La única vez que "era idiota" fue un problema CRLF, pero en realidad era porque no sabíamos lo suficientemente bien y (gracias a SO) era fácil de manejar.

Por lo tanto, siempre mire con cuidado y probablemente encontrará que el problema se reduce a alguien que no entiende git y está haciendo algo que no debería tener.