Git Push devuelve "Todo actualizado"

Estoy intentando enviar mis files actualizados a un repository remoto en github, operando OSX Snow Leopard usando la versión de Git 1.8.4.2.

He hecho con éxito git init seguido de git add . y git remote add origin https://github.com/me/repo.git . Luego hice un git commit -m "first commit" seguido de git push origin master

Todo esto funcionó muy bien

El problema es que me devuelven un post cuando bash comprometerme y presionar de nuevo. Actualicé algunos files, por ejemplo, hice un commit con un post, y luego ejecuté git push remote origin .

El command funciona, excepto que dice "Todo actualizado". Escaneé media docena de preguntas de desbordamiento de stack con errores similares y muchas de ellas relacionadas con no estar en la bifurcación correcta o estar en modo de cabeza desconectada. Creo que mi caso no es ninguno de los dos.

Aquí está el resultado de git log --graph --all --decorate --pretty=oneline :

 * 6926001f0eed54c05f807eb04ed05fd0584cd2e6 (HEAD, origin/master, master) first commit 

y aquí está git remote show origin

 * remote origin Fetch URL: https://github.com/me/repo.git Push URL: https://github.com/me/repo.git HEAD branch: master Remote branch: master tracked Local ref configunetworking for 'git push': master pushes to master (up to date) 

y aquí está git branch -v

 * master 6926001 first commit 

No estoy seguro de qué otra información puedo proporcionar, pero házmelo saber y actualizaré la pregunta. Soy bastante nuevo en git, ¡gracias por leer!

Editar:

Ejecuté el segundo commit nuevamente y recibí este post:

 # On branch master # Changes not staged for commit: # (use "git add <file>..." to update what will be committed) # (use "git checkout -- <file>..." to discard changes in working directory) # # modified: file1 # modified: file2 # modified: file3 # no changes added to commit (use "git add" and/or "git commit -a") 

Necesita agregar files al "área de preparación" antes de que la git commit haga una nueva confirmación. 1

El "área de preparación" le permite organizar todo de la manera que desee, que a veces no es la misma configuration que necesita en el directory de trabajo (por ejemplo, puede necesitar modificar un file de configuration para probar la parte 1 de una nueva function, pero no querer comprometer ese particular cambio de config-file aún).

En general, es prudente ejecutar el git status antes de git commit con git commit para ver qué está listo para comprometer y qué no está aún configurado. Además, git diff --cached muestra lo que se va a comprometer (compara el commit HEAD con el área de preparación), mientras que git diff sin --cached muestra lo que no se va a comprometer, es decir, lo que aún no está en etapas.

Como atajo, puede usar git commit -a , que automáticamente agrega files que aparecen modified o deleted en la salida de git status . (Pero esto no agrega files "sin seguimiento". De nuevo, vea el resultado del git status de git status ).

Para completar, git diff HEAD que git diff HEAD muestra lo que cometerías si ejecutaras git commit -a . (Estas tres variantes de git diff se enumeran en la documentation de git diff , en la sección EJEMPLOS).

Aquí hay algunas references web sobre el área de preparación:

http://gitready.com/beginner/2009/01/18/the-staging-area.html

http://git-scm.com/book/es/Getting-Started-Git-Basics (este es el libro de Pro Git, que es muy bueno, pero también puede ser bastante confuso, sobre todo porque el propio git puede ser bastante confuso).

https://softwareengineering.stackexchange.com/questions/69178/what-is-the-benefit-of-gits-two-stage-commit-process-staging


1 Técnicamente no es del todo cierto: más precisamente, justo antes de comprometerse, git commit hace una comparación rápida de lo que es comprometer, frente a la confirmación HEAD actual. Si no hay diferencia, se detiene a less que haya especificado --allow-empty . Con -a , "lo que es comprometer" incluye files modificados y eliminados; solo si no hay ninguno, todavía necesitará --allow-empty para hacer una nueva confirmación.