ver tutorial remota rama origin modificados example español comandos cambiar archivos and git gitosis

tutorial - git push dice todo lo actualizado a pesar de que tengo cambios locales



git ver archivos modificados (16)

¿Tal vez estás presionando una nueva sucursal local?

Una nueva rama local debe ser empujada explícitamente:

git push origin your-new-branch-name

Solo una de esas cosas sobre git ... Usted clona un repositorio, crea una sucursal, realiza algunos cambios, presiona ... "Todo está actualizado". Entiendo por qué sucede, pero este flujo de trabajo es extremadamente hostil para los recién llegados.

Tengo un servidor de gitosis remoto y un repositorio git local, y cada vez que hago un gran cambio en mi código, también envío los cambios a ese servidor.

Pero hoy encuentro que a pesar de tener algunos cambios locales y comprometerme con el repositorio local, cuando ejecuto git push origin master dice ''Todo actualizado'', pero cuando uso git clone para verificar los archivos en el servidor remoto, no contiene los últimos cambios. Y solo tengo una rama llamada maestra y un servidor remoto llamado origen.

PD: Esto es lo que git muestra al ejecutar ls-remote, no estoy seguro si ayuda

$ git ls-remote origin df80d0c64b8e2c160d3d9b106b30aee9540b6ece HEAD df80d0c64b8e2c160d3d9b106b30aee9540b6ece refs/heads/master $ git ls-remote . 49c2cb46b9e798247898afdb079e76e40c9f77ea HEAD df80d0c64b8e2c160d3d9b106b30aee9540b6ece refs/heads/master df80d0c64b8e2c160d3d9b106b30aee9540b6ece refs/remotes/origin/master 3a04c3ea9b81252b0626b760f0a7766b81652c0c refs/tags/stage3

Desde tu estado de git, es probable que tengas una situación diferente a la mía.

Pero de todos modos, aquí está lo que me sucedió ... Encontré el siguiente error:

fatal: The remote end hung up unexpectedly Everything up-to-date

El mensaje más informativo aquí es que el control remoto colgó. Resultó que se debe a que excede el tamaño del búfer http post. La solución es aumentarlo con

git config http.postBuffer 524288000

En mi caso, tuve 2 repos remotos.

git remote -v originhttps https://asim_kt@... originhttps https://asim_kt@... origin ssh:[email protected]:... origin ssh:[email protected]:...

Ambos repo fueron iguales. Solo uno era https otro era ssh . Así que eliminar el no deseado, (en mi caso ssh . Ya que usé https porque ssh no funcionaba) solucionó el problema por mí.

Err .. Si eres un novato git ¿estás seguro de que tienes git commit git push antes de git push ? ¡Cometí este error la primera vez!

Hay una manera rápida que encontré. Vaya a su carpeta .git, abra el archivo HEAD y cambie la rama en la que estaba a master. Ej ref: refs/heads/master

Me encontré con esto cuando fusioné una sucursal en Github y continué desarrollándome localmente. Mi solución fue un poco diferente a los otros que se han sugerido.

Primero ramifiqué una nueva rama local de mi antigua sucursal local (que no pude impulsar). Luego empujé la nueva rama local al servidor de origen (Github). Es decir

$ git checkout -b newlocalbranch oldlocalbranch $ git push origin newlocalbranch

Esto hizo que los cambios aparecieran en Github, aunque en newlocalbranch en lugar de oldlocalbranch.

Me he enfrentado a una situación similar; cuando hice los cambios y traté de git push origin master , todo estaba actualizado.

Tuve que git add el archivo modificado y luego git push origin master . Comenzó a funcionar desde entonces.

Mi error fue diferente a todo lo mencionado hasta ahora. Si no tienes idea de por qué tendrías una cabeza separada, entonces probablemente no. Estaba trabajando en piloto automático con git commit y git push , y no había leído la salida de git commit . Resulta que fue un mensaje de error porque olvidé -am.

[colin] ~/github/rentap.js [master] M % git commit ''figured out some more stuff with the forms in views and started figuring out row and mode in models so also made matching routes and controllers'' error: pathspec ''figured out some more stuff with the forms in views and started figuring out row and mode in models so also made matching routes and controllers'' did not match any file(s) known to git. [colin] ~/github/rentap.js [master] M % git push Enter passphrase for key ''/home/colin/.ssh/id_ecdsa'': Everything up-to-date

Se -am poniendo -am donde normalmente hago:

[colin] ~/github/rentap.js [master] M % git commit -am ''figured out some more stuff with the forms in views and started figuring out row and mode in models so also made matching routes and controllers''

Otra posibilidad es que hayas nombrado un directorio en tu archivo .gitignore que fue excluido. Entonces los nuevos commits no serían empujados. Me pasó que nombré un directorio para ignorar "búsqueda", pero ese también era un directorio en mi árbol fuente.

Otra situación que es importante tener en cuenta: el tipo de estado predeterminado para git es que estás trabajando en la rama "principal". Y para muchas situaciones, simplemente pasará tiempo como su rama de trabajo principal (aunque algunas personas se vuelven elegantes y hacen otras cosas).

De todos modos, eso es solo una rama. Entonces, una situación en la que me podría meter es:

Mi rama activa en realidad NO es la rama principal. ... Pero habitualmente hago el comando: git push (y anteriormente había hecho git push origin master , así que es un atajo para ESO).

Así que habitualmente estoy empujando la rama principal al repositorio compartido ... lo cual es probablemente una buena cosa limpia, en mi caso ...

¡Pero he olvidado que los cambios en los que he estado trabajando todavía no están en la rama principal!

Entonces, cada vez que pruebo git push , y veo "Todo al día", quiero gritar, pero claro, ¡no es culpa de git! Es mio.

Entonces, en lugar de eso, fusiono mi rama en maestra y luego hago push, y todo vuelve a ser feliz.

Tuve este problema hoy y no tuvo nada que ver con ninguna de las otras respuestas. Esto es lo que hice y cómo lo arreglé:

Un repositorio mío recientemente se mudó, pero tenía una copia local. Me ramifiqué de mi sucursal "maestra" local e hice algunos cambios, y luego recordé que el repositorio se había movido. Utilicé git remote set-url origin https://<my_new_repository_url> para establecer la nueva URL, pero cuando lo git remote set-url origin https://<my_new_repository_url> simplemente decía "Todo al día" en lugar de empujar mi nueva rama al máster.

Terminé resolviéndolo volviendo a basar en origin/master y luego presionando con nombres de ramas explícitos, como este:

$ git rebase <my_branch> origin/master $ git push origin <my_branch>

¡Espero que esto ayude a cualquiera que tenga mi mismo problema!

Usted no estaría trabajando con una cabeza separada por casualidad?

Como en:

lo que indica que su última confirmación no es un encabezado.

$ git log -1 # note the SHA-1 of latest commit $ git checkout master # reset your branch head to your previously detached commit $ git reset --hard <commit-id>

Como se menciona en la página del manual de git checkout (énfasis mío):

A veces es útil poder verificar una confirmación que no se encuentra en la punta de una de sus sucursales .
El ejemplo más obvio es verificar el compromiso en un punto de lanzamiento oficial etiquetado, como este:

$ git checkout v2.6.18

Las versiones anteriores de git no permitían esto y le pedían que creara una bifurcación temporal usando la opción -b , pero a partir de la versión 1.5.0, el comando anterior separa su HEAD de la rama actual y apunta directamente a la confirmación nombrada por la etiqueta ( v2.6.18 en el ejemplo anterior).

Puedes usar todos los comandos de git mientras estás en este estado.
Puede usar git reset --hard $othercommit para seguir moviéndose, por ejemplo.
Puede hacer cambios y crear una nueva confirmación en la parte superior de un HEAD separado .
Incluso puedes crear una fusión usando git merge $othercommit .

El estado en el que te encuentras mientras tu HEAD está separada no está registrado por ninguna rama (lo cual es natural, no estás en ninguna rama).
Lo que esto significa es que puedes descartar tus compromisos y fusiones temporales volviendo a una sucursal existente (por ej., git checkout master ), y una git prune o git gc posteriores los recogerían.
Si lo hizo por error, puede solicitar la rectificación de HEAD donde estaba, por ejemplo

$ git log -g -2 HEAD

Vea la respuesta de VonC más arriba: necesitaba un paso adicional:

$ git log -1 - note the SHA-1 of latest commit $ git checkout master - reset your branch head to your previously detached commit $ git reset --hard <commit-id>

Hice esto, pero cuando traté de volver a git push remoterepo master , decía "error: no git push remoterepo master algunas referencias. Para evitar que perdiera historial, las actualizaciones que no eran de avance rápido se rechazaron, combine los cambios remotos (por ejemplo, ''git''). tire '') antes de volver a presionar.

Así que lo hice ''git pull remoterepo master'', y encontró un conflicto. He git reset --hard <commit-id> otra vez, copié los archivos en conflicto a una carpeta de respaldo, hice git pull remoterepo master otra vez, copié los archivos conflictivos en mi proyecto, hice git commit , luego git push remoterepo master , y esta vez funcionó.

Git dejó de decir "todo está actualizado" y dejó de quejarse de los "adelantos rápidos".

Verifique que no haya engañado su URL remota.

Solo quería mencionar que me encontré con esto después de habilitar Git como CVS en una configuración de compilación local de Jenkins. Parece que Jenkins revisó la confirmación más reciente de la rama que le di y también restableció mi control remoto para que se corresponda con las rutas que le di al repositorio. Tuve que revisar mi rama de características nuevamente y arreglar mi URL remota de origen con ''git remote set-url''. No vaya apuntando una herramienta de compilación a su directorio de trabajo o tendrá un mal momento. Mi control remoto se estableció en una ruta de archivo a mi directorio de trabajo, por lo que, naturalmente, informó todo lo que estaba actualizado cuando intenté realizar cambios con el mismo origen y destino.

$ git push origin local_branch:remote_branch

Explicación

Tuve el mismo error y pasé horas tratando de resolverlo. Finalmente lo encontré. Lo que no sabía es que empujar como este git push origin branch-x intentará buscar branch-x localmente y luego presionar a remote branch-x.

En mi caso, tenía dos URL remotas. Hice un checkout de branch-x a branch-y al intentar enviar desde y localmente a x remote, tuve el mensaje de que todo está actualizado, lo cual es normal porque estaba presionando x del segundo control remoto.

Para resumir, para no caer en este tipo de trampa, debe especificar la referencia de origen y la referencia de destino:

$ git push origin local_branch:remote_branch