El comando Git push en Git

El comando git push en Git se utiliza para cargar cambios locales en un repositorio remoto. De esta manera, los commit locales se ponen a disposición de otros colaboradores del proyecto, quienes pueden recuperarlos a través de una búsqueda e incorporarlos a sus respectivos repositorios locales.

En el modo estándar, git push envia solo los cambios nuevos, ya que Git sabe qué commit ya están presentes en el repositorio remoto.

$ git status
On branch main
Your branch is ahead of 'origin/main' by 2 commit.
(use "git push" to publish your local commits)

$ git push
Enumerating objects: 7, done.
Counting objects: 100% (7/7), done.
Delta compression using up to 16 threads
Compressing objects: 100% (4/4), done.
Writing objects: 100% (4/4), 612 bytes | 612.00 KiB/s, done.
Total 4 (delta 3), reused 0 (delta 0), pack-reused 0
remote: Resolving deltas: 100% (3/3), completed with 3 local objects.
To https://server.com/project.git
e953fe1..cf9735f  main -> main

Antes y después del push

Al ejecutar git push sin especificar ningún argumento, solo los nuevos commit se enviarán al repositorio remoto conectado a la rama actualmente en uso en la working copy local.

Sin embargo, es posible dar varios argumentos al comando para elegir exactamente qué enviar al repositorio remoto.

$ git tag v1.2.3

$ git push --tags
Total 0 (delta 0), reused 0 (delta 0), pack-reused 0
To https://server.com/projecto.git
* [new tag]         v1.2.3 -> v1.2.3

El push de etiquetas a un repositorio remoto debe indicarse explícitamente a través del argumento --tags, que envía todas las etiquetas nuevas presentes en el repositorio local al repositorio remoto.

$ git status
On branch main
Your branch is up to date with 'origin/main'.

$ git branch new-feature

$ git branch
* main
  new-feature

$ git push --all
Total 0 (delta 0), reused 0 (delta 0), pack-reused 0
To https://server.com/projecto.git
* [new branch]      new-feature -> new-feature

Con el argumento --all se produce el upload de todos los branch presentes en el repository locale hacia el repository remoto.

$ git remote -vv
backup   git@gitlab.com:elle.uca/aulab-demo.git (fetch)
backup   git@gitlab.com:elle.uca/aulab-demo.git (push)
origin   https://github.com/elleuca/aulab-demo.git (fetch)
origin   https://github.com/elleuca/aulab-demo.git (push)

$ git status
On branch main
Your branch is up to date with 'origin/main'.

$ git branch -vv
* main 35aad79 [origin/main] Initial commit

$ git push backup
Enumerating objects: 3, done.
Counting objects: 100% (3/3), done.
Writing objects: 100% (3/3), 642 bytes | 642.00 KiB/s, done.
Total 3 (delta 0), reused 3 (delta 0), pack-reused 0
To gitlab.com:elle.uca/aulab-demo.git
* [new branch]      main -> main

Obviamente, es posible indicar, si tienes varios repositorios remotos y varios branch, el branch específico para enviar y el remote al cual enviarlo ejecutando el comando en la forma git push <remoto> <branch>.

Para que no nos cojan desprevenidos en caso de necesidad, veamos cómo actuar en caso de que sea necesario cambiar el historial después de que ya hayamos hecho el push al repositorio remoto.

Por ejemplo, supongamos que estamos en la situación en la que queremos hacer un commit que modifique un archivo preexistente y agregue otro, que es necesario para que el cambio realizado en nuestro proyecto tenga sentido. Sin embargo, por error, hemos incluido en el commit solo el archivo con las modificaciones.

$ git status
On branch main
Your branch is up to date with 'origin/main'.

Changes to be committed:
  modified:   page.html

Untracked files:
  public/new-logo.png

$ git commit -m "update logo" && git push
[main d5c0b92] update logo

Dado que, en realidad, el commit no representa el cambio real deseado, podría ser útil efectuar la amend del commit en lugar de agregar un segundo commit.

De esta forma, sin embargo, la historia del repositorio local cambia con respecto a la del repositorio remoto (con la amend, de hecho, prácticamente reemplazamos un snapshot por otro snapshot). Para alinear los repositorios locales y remotos, podemos hacer el push con el argumento --force.

$ git add public/new-logo.png

$ git commit --amend --no-edit
[main 5fb65cb] update logo

$ git status
On branch main
Your branch and 'origin/main' have diverged,
and have 1 and 1 different commits each, respectively.
  (use "git pull" to merge the remote branch into yours)

$ git push --force
Enumerating objects: 8, done.
Counting objects: 100% (8/8), done.
Delta compression using up to 16 threads
Compressing objects: 100% (5/5), done.
Writing objects: 100% (5/5), 39.00 KiB | 19.50 MiB/s, done.
Total 5 (delta 2), reused 0 (delta 0), pack-reused 0
remote: Resolving deltas: 100% (2/2), completed with 2 local objects.
To https://server.com/projecto.git
+ 7b82870...5fb65cb main -> main (forced update)

Es necesario tener mucho cuidado al usar el argumento --force del comando git push ya que, en este caso, Git asume que es la intención precisa del usuario sobrescribir completamente el historial de la rama remota, reemplazándolo con el del brach local. De hecho, no se puede descartar que entre nuestro primer push y el segundo algún otro colaborador del proyecto no hiciera a su vez otros push.

Para minimizar las pérdidas no deseadas, siempre es últil:

• efectuar el fetch y pull de las modificaciones remotas en el propio branch locale antes de hacer un push con force
• utilizar --force-with-lease en vez de --force: de esta manera se usa una modalidad especial del push con force que, en la práctica advierte si está apunto de eliminiar del repository remoto commit de otros (que podrán entonces volver a la copia local antes de volver a intentarlo)