Cómo enviar cambios a github sin tirar

5 minutos de lectura

avatar de usuario
Oleksandr Matrosov

Desarrollé un proyecto que fue desarrollado por otros desarrolladores. Envié mi código a los desarrolladores anteriores para realizar cambios en su código, pero dijeron que nunca habían trabajado con git, por lo que agregaron cambios al proyecto y ahora es la versión real pero no bajo el control de versiones.

Entonces, ya tengo confirmaciones en github y necesito impulsar esta nueva versión.

Lo que hice:

  1. git init
  2. git remote add origin
  3. git add .
  4. git push origin master

Pero hay un problema: no puedo enviar nuevos cambios antes de actualizar el repositorio local. Si actualizo mi repositorio, devolverá todos los archivos que los desarrolladores anteriores han eliminado.

¿Cómo presiono la versión actual sin extraer datos de git?

  • Actualizar desde el control remoto no hará que pierdas archivos, siempre y cuando los tengas en tus confirmaciones locales.

    – Alex

    10/10/2013 a las 18:57

avatar de usuario
anshul goyal

Puedes hacer un empujón forzado.

git push -f origin branch_name

El empuje forzado borrará todo el historial de confirmaciones de la rama del repositorio remoto y lo reemplazará en su rama.

Verifique las respuestas para hacer push forzados en “¿Cómo fuerzo correctamente un push de Git?”. El empuje forzado puede tener consecuencias no deseadas como se menciona en “Git: cómo ignorar el avance rápido y revertir el origen [branch] para confirmar antes?”, así que verifique lo mismo.

El empuje forzado será una forma incorrecta de empujar cosas en su caso, ya que ya tiene confirmaciones anteriores en GitHub, y esto borrará el historial de confirmaciones para confirmaciones anteriores.

Por lo tanto, para preservar su historial de confirmaciones, puede hacer lo siguiente:

Elimine todos los archivos del repositorio de git y luego agregue los nuevos archivos aquí y luego confirme los archivos actualizados:

git rm -rf .
cp -r path/to/updated/code/* .
git add .

haciendo un git status ahora le dirá qué archivos modificaron los otros desarrolladores, y un git diff mostrará qué modificaciones hay.

Si un archivo ha permanecido sin cambios, entonces git rm y git add anularán el efecto de cada uno.

Los archivos que esos desarrolladores eliminaron permanecen eliminados desde que ejecutó el git rm para ellos pero no git add.

Una vez que esté satisfecho de que estos son los cambios, puede confirmar usando

git commit -m "Merged new code"

Errores potenciales:

  1. Solo ha cambiado el modo de archivo (755 644), según el código que le hayan enviado los otros desarrolladores.
  2. Perderá su archivo .gitignore con git rm -rf . (y de manera similar .gitattributes y otros archivos similares). Restablezca HEAD para cada uno de esos archivos usando git reset HEAD .gitignore antes del compromiso.
  3. Caracteres de terminación de línea diferentes (en caso de que se utilicen entornos de desarrollo diferentes), así que verifíquelos adecuadamente.

  • Soy uno de los votantes negativos. Voté en contra porque OP tiene una fuente controlada por versión existente que debe actualizarse para incluir cambios que no están actualmente en el control de versión y que fueron realizados por otras personas. Tomar la fuente actual sin VC, crear una sola confirmación y sobrescribir el historial existente es la peor solución posible para las ediciones actuales que no se rastrean. Hay momentos en que los empujones forzados son útiles o necesarios, pero este no es uno de esos casos. Como dice mi comentario anterior, la forma adecuada de manejar esta situación es crear nuevas confirmaciones, no borrar las antiguas.

    – cjc343

    11/10/2013 a las 17:15

  • @ cjc343 Inicialmente asumí que OP quería un nuevo repositorio (me confundí con los pasos que estaba haciendo para git init). ¡Gracias! He actualizado mi respuesta ahora.

    – Anshul Goyal

    11/10/2013 a las 19:48


avatar de usuario
manojlds

Parece que otras personas trabajaron en su proyecto fuera del control de versiones, es decir, en archivos y carpetas desnudos.

Le sugiero que clone el repositorio, copie (y, por lo tanto, reemplace) el contenido clonado con el nuevo contenido, confirme e impulse estos cambios.

Los comandos actuales de git init etc. que está utilizando para crear repositorios completamente nuevos, que no es lo que desea.

  • Crear una nueva confirmación con las diferencias entre el estado de repositorio actual y el estado de origen actual parece la mejor solución posible para esta situación. Es muy simple y mantiene el historial mientras registra los cambios realizados por otros correctamente.

    – cjc343

    10/10/2013 a las 19:47

  • Creo que el siguiente enlace ofrece una mejor manera stackoverflow.com/questions/10510462/…

    – Mani

    14/10/2015 a las 13:56

avatar de usuario
Deepam Gupta

Guión:

En mi caso, el escenario era que tenía una sucursal feature1 en el que hice compromisos y después de probarlos los fusioné para dominar.

Pero un día, cometí un error y sin mucha prueba de cambios en feature1, fusioné el código para dominar. Y luego mi compañero de equipo notó que hay un error. Pero no había tiempo para resolverlo para ese día, pero el master La rama necesita tener un código de trabajo.

Hacer un reinicio de Git

hice un git log en mi local, copié el commit id del compromiso que sabía que funcionaba bien. Y luego hizo un reinicio por git reset --hard <commit id>.

De esta manera volvimos al compromiso que estaba funcionando. Pero cuando intentamos git push origin master este compromiso, git dijo que hiciera un git pull primero. Pero si hiciéramos eso, entonces volveríamos a ir a la última confirmación que tenía el bicho.

Solución – Empuje forzado

en lugar de simplemente git push origin masterlo hicimos

git push --force origin <commit id>:master

PRECAUCIÓN: Empuje forzado borra todo el historial de confirmaciones que estaban por encima de la confirmación empujada forzada y llevarán esta confirmación a la parte superior. Usar Empuje forzado con cuidado.

Para saber más sobre las soluciones a algunos problemas en los que puede sumergirse:

  1. git push –force y cómo manejarlo
  2. ¿De dónde provienen los ID de confirmación?
  3. No confundas entre fusionar y reorganizar

PROPINA: Mientras se compromete, confirme con un mensaje significativo de lo que hizo en ese compromiso. Ayuda.

Namasté🙏

¿Ha sido útil esta solución?