Git push: Cómo subir cambios a GitHub

git push es el comando de Git que permite enviar los commits realizados en un repositorio local hacia un repositorio remoto, como GitHub. Es fundamental para publicar nuestros cambios, mantener sincronizado el repositorio remoto y compartir nuestro trabajo con otros desarrolladores.

1. ¿Qué es git push?

git push es el comando utilizado para enviar los commits del repositorio GIT local a un repositorio remoto.

Por ejemplo, si realizamos cambios en nuestro proyecto y ejecutamos:

git add .
git commit -m "Agrega nueva sección"Lenguaje del código: JavaScript (javascript)

los cambios quedan registrados en nuestro repositorio local.

Sin embargo, todavía no están en GitHub.

Para enviarlos al repositorio remoto utilizamos:

git push

El flujo sería:

Archivos
   ↓
git add
   ↓
Staging Area
   ↓
git commit
   ↓
Repositorio local
   ↓
git push
   ↓
Repositorio remoto (GitHub)

Es importante entender esta diferencia: git commit guarda los cambios en nuestro repositorio local, mientras que git push los envía al repositorio remoto.

1.1. ¿Para qué sirve?

El principal objetivo de git push es sincronizar nuestro repositorio remoto con los commits que tenemos localmente.

Por ejemplo, podemos utilizarlo para:

• Subir nuevos cambios a GitHub.
• Publicar nuevos commits.
• Compartir nuestro trabajo con otros desarrolladores.
• Actualizar un repositorio remoto.
• Publicar una nueva rama.
• Enviar cambios realizados desde VS Code.
• Trabajar en proyectos colaborativos.
• Mantener una copia remota del proyecto.

Un escenario habitual sería:

Desarrollador
     ↓
Modifica archivos
     ↓
git add
     ↓
git commit
     ↓
git push
     ↓
GitHub

2. ¿Cómo funciona?

Para entender git push, debemos diferenciar entre el repositorio local y el repositorio remoto.

Supongamos que tenemos:

Repositorio local
        │
        │ git push
        ↓
Repositorio remoto
     GitHub

Cuando ejecutamos:

git push

Git compara los commits que tenemos localmente con los que existen en el repositorio remoto.

Si nuestro repositorio local tiene commits que todavía no están en GitHub, Git los envía al remoto.

Por ejemplo:

LOCAL                  GITHUB

A ── B ── C            A ── B
          │
       git push
          ↓

A ── B ── C            A ── B ── C

El commit C estaba únicamente en nuestro repositorio local. Después de ejecutar git push, también estará en GitHub.

3. ¿Qué necesitamos antes de utilizarlo?

Antes de ejecutar git push, normalmente necesitamos:

3.1. Tener un repositorio Git local

El proyecto debe estar gestionado por Git.

Podemos comprobarlo con:

git status

3.2. Tener un repositorio remoto configurado

Podemos comprobar los repositorios remotos con:

git remote -v

Por ejemplo:

origin  https://github.com/usuario/proyecto.git (fetch)
origin  https://github.com/usuario/proyecto.git (push)Lenguaje del código: JavaScript (javascript)

En este caso, origin es el nombre que identifica al repositorio remoto.

3.3. Tener al menos un commit

git push envía commits, por lo que primero debemos registrar nuestros cambios:

git add .
git commit -m "Mi primer commit"Lenguaje del código: JavaScript (javascript)

Después podemos ejecutar:

git push

4. Cómo hacer git push paso a paso

Veamos un ejemplo completo desde un proyecto local.

4.1. Abrir el proyecto

Abrimos nuestro proyecto con Visual Studio Code o desde la terminal.

Por ejemplo:

mi-proyecto/
├── index.html
├── style.css
└── script.js

4.2. Modificar un archivo

Supongamos que modificamos index.html.

Guardamos los cambios y comprobamos el estado:

git status

Git podría mostrar:

modified: index.htmlLenguaje del código: CSS (css)

4.3. Agregar los cambios al staging

Ejecutamos:

git add .

También podemos agregar un archivo específico:

git add index.htmlLenguaje del código: CSS (css)

4.4. Crear un commit

Ahora registramos los cambios:

git commit -m "Actualiza página principal"Lenguaje del código: JavaScript (javascript)

El commit queda almacenado en nuestro repositorio local.

4.5. Subir los cambios a GitHub

Finalmente:

git push

Git enviará el nuevo commit al repositorio remoto.

4.6. Comprobar los cambios en GitHub

Podemos ingresar al repositorio de GitHub y comprobar que los archivos y el nuevo commit ya aparecen allí.

El proceso completo sería:

git status
git add .
git commit -m "Actualiza página principal"
git pushLenguaje del código: JavaScript (javascript)

Este es probablemente uno de los flujos más utilizados al trabajar con Git y GitHub.

5. git push origin main

El comando git push origin main se utiliza para enviar los commits de nuestra rama local main hacia la rama main del repositorio remoto identificado como origin.

git push origin main

El comando está compuesto por tres partes:

git push    origin    main
   │           │        │
   │           │        └── Rama que queremos subir
   │           └─────────── Repositorio remoto
   └─────────────────────── Acción de enviar cambios

5.1. ¿Para qué sirve git push origin main?

Sirve para subir a GitHub los commits que tenemos en nuestra rama local main.

Por ejemplo, si modificamos nuestro proyecto y hacemos:

git add .
git commit -m "Actualiza página principal"Lenguaje del código: JavaScript (javascript)

el commit queda guardado localmente.

Para enviarlo a GitHub podemos ejecutar:

git push origin main

De esta manera, Git toma los commits de nuestra rama local main y los envía al repositorio remoto origin.

5.2. ¿Qué significa origin?

origin es el nombre que normalmente recibe el repositorio remoto cuando conectamos nuestro proyecto local con GitHub.

Podemos comprobar qué repositorio representa origin mediante:

git remote -v

Por ejemplo:

origin  https://github.com/usuario/mi-proyecto.git (fetch)
origin  https://github.com/usuario/mi-proyecto.git (push)Lenguaje del código: JavaScript (javascript)

En este caso, origin hace referencia al repositorio mi-proyecto de GitHub.

NOTA! Es importante entender que origin no es una palabra obligatoria. Es simplemente un nombre utilizado para identificar el repositorio remoto. Podríamos tener otro nombre, aunque origin es el más habitual.

5.3. ¿Qué significa main?

main es el nombre de la rama a la que queremos enviar nuestros commits.

Por ejemplo, si nuestro proyecto tiene:

main
desarrollo
login
contacto

y estamos trabajando en main, podemos utilizar:

git push origin main

Esto significa: «Envía los commits de mi rama local main al repositorio remoto origin, en su rama main.»

También podemos comprobar en qué rama estamos actualmente con:

git branch

Si aparece:

* main

significa que estamos trabajando en la rama main.

5.4. Ejemplo práctico

Supongamos que tenemos un proyecto web conectado a un repositorio de GitHub llamado mi-web.

Modificamos index.html y queremos subir el cambio.

Primero comprobamos el estado:

git status

Agregamos el archivo:

git add index.htmlLenguaje del código: CSS (css)

Creamos el commit:

git commit -m "Actualiza página de inicio"Lenguaje del código: JavaScript (javascript)

Y finalmente lo enviamos a GitHub:

git push origin main

El flujo sería:

index.html
    ↓
git add
    ↓
git commit
    ↓
Rama local main
    ↓
git push origin main
    ↓
Rama main en GitHubLenguaje del código: CSS (css)

Por lo tanto, podemos recordar fácilmente que:

• git push = enviar cambios
• origin = repositorio remoto
• main = rama que queremos enviar

Y todo junto:

git push origin main

significa enviar los commits de la rama local main al repositorio remoto origin.

6. git push -u origin main

El comando:

git push -u origin main

Se utiliza normalmente la primera vez que queremos publicar nuestra rama local main en el repositorio remoto.

La opción -u establece una relación entre la rama local main y la rama remota origin/main. De esta manera, Git recuerda qué rama remota debe utilizar para futuros push y pull.

Una vez establecida esta relación, podemos utilizar simplemente:

git push

sin tener que escribir nuevamente origin main.

6.1. ¿Para qué sirve la opción -u?

La opción:

-u

es una forma abreviada de:

--set-upstreamLenguaje del código: JavaScript (javascript)

Su función es establecer la rama remota de seguimiento (upstream) para nuestra rama local.

Cuando ejecutamos:

git push -u origin main

le estamos indicando a Git: «Sube mi rama local main al remoto origin y recuerda que main debe seguir a origin/main.»

Podemos visualizarlo así:

Rama local                    Rama remota

   main  ───────────────────→  origin/main
             seguimiento

6.2. ¿Por qué después podemos utilizar solamente git push?

Porque al utilizar -u, Git guarda la relación entre ambas ramas.

Después de ejecutar:

git push -u origin main

Git ya sabe que nuestra rama local main está asociada con:

origin/main

Por eso, cuando posteriormente ejecutamos:

git push

Git ya sabe a qué repositorio y a qué rama debe enviar los nuevos commits.

Sin esa relación configurada, Git puede no saber cuál es el destino predeterminado y puede solicitar que indiquemos explícitamente el remoto y la rama.

6.3. Diferencia entre git push -u origin main y git push origin main

La diferencia principal está en que -u establece la relación de seguimiento.

git push origin main

Significa: Envía la rama local main al remoto origin.

Mientras que:

git push -u origin main

Significa: Envía la rama local main al remoto origin y establece origin/main como rama de seguimiento.

Por lo tanto:

Comando	¿Envía los cambios?	¿Establece upstream?
git push origin main	Sí	No
git push -u origin main	Sí	Sí

Por eso, cuando publicamos una rama por primera vez, es habitual utilizar:

git push -u origin main

y después simplemente:

git push

7. Cómo subir una nueva rama con git push

Cuando creamos una nueva rama en Git, esta existe inicialmente solo en nuestro repositorio local. Para que también esté disponible en GitHub, debemos publicarla mediante git push.

Esto es muy habitual cuando trabajamos en una nueva funcionalidad, corregimos un error o queremos realizar cambios sin modificar directamente la rama main.

7.1. Crear una nueva rama

Podemos crear una rama y cambiar a ella utilizando:

git switch -c nueva-funcionalidadLenguaje del código: JavaScript (javascript)

Por ejemplo:

git switch -c formulario-contactoLenguaje del código: JavaScript (javascript)

Ahora estamos trabajando en la rama formulario-contacto.

Podemos comprobarlo con:

git branch

Y veremos algo similar a:

  main
* formulario-contacto

El * indica la rama en la que estamos actualmente.

7.2. Realizar los cambios

Ahora podemos modificar los archivos de nuestro proyecto.

Por ejemplo:

mi-proyecto/
├── index.html
├── style.css
└── contacto.html

Después de realizar los cambios, los agregamos al staging:

git add .

7.3. Crear un commit

Registramos los cambios:

git commit -m "Agrega formulario de contacto"Lenguaje del código: JavaScript (javascript)

En este punto, el commit está guardado en nuestra rama local formulario-contacto, pero todavía no hemos creado esa rama en GitHub.

7.4. Subir la nueva rama a GitHub

Para publicar la rama utilizamos:

git push -u origin formulario-contacto

Aquí:

• git push → envía los commits al repositorio remoto.
• -u → establece la relación de seguimiento entre la rama local y la remota.
• origin → identifica nuestro repositorio remoto.
• formulario-contacto → es la rama que queremos publicar.

El resultado será conceptualmente:

Repositorio local                    GitHub

main                                 main
  │                                    │
  └── formulario-contacto ─────────→ formulario-contacto

7.5. Continuar trabajando en la rama

Una vez que utilizamos:

git push -u origin formulario-contacto

Git ya conoce la relación entre nuestra rama local y la rama remota.

Por eso, después de realizar nuevos cambios, podemos utilizar simplemente:

git add .
git commit -m "Actualiza formulario"
git pushLenguaje del código: JavaScript (javascript)

No es necesario volver a escribir:

git push -u origin formulario-contacto

7.6. Ejemplo completo

Supongamos que tenemos un proyecto y queremos desarrollar una sección de contacto sin modificar directamente main.

Primero creamos la rama:

git switch -c contactoLenguaje del código: JavaScript (javascript)

Realizamos nuestros cambios y los guardamos:

git add .
git commit -m "Agrega sección de contacto"Lenguaje del código: JavaScript (javascript)

Publicamos la rama:

git push -u origin contacto

A partir de ese momento tendremos la rama disponible tanto localmente como en GitHub:

                 GitHub
                   │
                 main
                   │
                   └── contacto
                        ↑
                        │
                 git push
                        │
                  Repositorio
                     local

Posteriormente podemos continuar haciendo commits en contacto y subirlos simplemente con:

git push

Una vez terminada la funcionalidad, esta rama puede utilizarse para crear un Pull Request en GitHub y posteriormente integrarse en main.

Importante: crear una rama con git switch -c no la publica automáticamente en GitHub. Para que aparezca en el repositorio remoto debemos hacer un git push, normalmente usando -u la primera vez.

8. ¿Cómo saber qué cambios voy a subir?

Antes de ejecutar git push, es recomendable comprobar qué cambios tenemos, qué archivos están preparados para el commit y qué commits todavía no fueron enviados a GitHub.

Esto nos permite evitar subir accidentalmente cambios que no queríamos publicar.

Es importante tener en cuenta que git push no sube directamente los archivos modificados. El comando envía los commits que todavía no están en el repositorio remoto. Por eso, para saber qué vamos a subir, debemos revisar primero nuestros cambios y después los commits pendientes.

8.1. Comprobar el estado con git status

El primer comando que podemos utilizar es:

git status

Por ejemplo:

On branch main
Changes not staged for commit:
  modified:   index.html
  modified:   style.cssLenguaje del código: CSS (css)

Esto nos indica que index.html y style.css fueron modificados, pero todavía no están preparados para el próximo commit.

Si hacemos:

git add .

y volvemos a ejecutar:

git status

podríamos ver:

Changes to be committed:
  modified:   index.html
  modified:   style.cssLenguaje del código: CSS (css)

Ahora esos cambios están en el staging y podrán formar parte del próximo commit.

8.2. Revisar exactamente qué cambios hicimos con git diff

Para comprobar qué modificamos antes de hacer git add, podemos utilizar:

git diff

Por ejemplo:

git diff

nos mostrará las diferencias entre nuestra versión actual y la versión que tenemos registrada.

Esto es especialmente útil para detectar cambios que quizá no queríamos incluir.

También podemos revisar los cambios que ya están preparados en el staging mediante:

git diff --staged

De esta manera podemos distinguir:

git diff
    ↓
Cambios todavía no preparados

git diff --staged
    ↓
Cambios preparados para el próximo commit

8.3. Comprobar qué commits todavía no están en GitHub

Después de crear un commit, podemos comprobar si tenemos commits locales que todavía no fueron enviados al remoto.

Por ejemplo:

git log origin/main..main

Este comando muestra los commits que existen en nuestra rama local main, pero todavía no están en origin/main.

Supongamos que obtenemos:

commit a82f31
Author: Manuel
Message: Actualiza página principal

commit 91bc42
Author: Manuel
Message: Agrega formulario de contacto

Esto significa que tenemos dos commits locales que todavía podemos enviar mediante:

git push

8.4. Un ejemplo completo

Supongamos que modificamos:

index.html
style.css
script.jsLenguaje del código: CSS (css)

Primero comprobamos:

git status

Revisamos exactamente qué modificamos:

git diff

Decidimos que queremos incluir todos los cambios:

git add .

Antes de crear el commit podemos comprobar nuevamente qué está preparado:

git diff --staged

Después creamos el commit:

git commit -m "Actualiza página principal"Lenguaje del código: JavaScript (javascript)

Ahora podemos comprobar qué commits locales todavía no fueron enviados:

git log origin/main..main

Si aparece nuestro nuevo commit, significa que está listo para ser enviado a GitHub.

Finalmente:

git push

8.5. Flujo recomendado antes de hacer git push

Una forma sencilla de revisar nuestros cambios antes de subirlos es:

git status
git diff
git diff --staged
git log origin/main..main
git push

No siempre necesitamos ejecutar todos estos comandos, pero este proceso nos permite revisar progresivamente:

¿Qué archivos cambié?
        ↓
   git status

¿Qué modifiqué exactamente?
        ↓
     git diff

¿Qué voy a incluir en el commit?
        ↓
 git diff --staged

¿Qué commits todavía no están en GitHub?
        ↓
git log origin/main..main

        ↓
     git push

La idea fundamental es que antes de hacer git push debemos pensar en términos de commits: los archivos modificados se incorporan a un commit mediante git add y git commit, y son esos commits los que posteriormente git push envía al repositorio remoto.

9. ¿Qué ocurre si git push es rechazado?

Cuando ejecutamos git push, Git intenta enviar nuestros commits desde el repositorio local hacia el repositorio remoto, por ejemplo, GitHub.

Si Git muestra un mensaje indicando que el push fue rechazado (rejected), significa que Git no puede incorporar nuestros cambios al repositorio remoto de la manera que estamos intentando hacerlo.

Uno de los motivos más habituales es que el repositorio remoto tiene commits que nosotros todavía no tenemos en nuestro repositorio local.

9.1. ¿Por qué Git rechaza el push?

Imaginemos que nuestro repositorio local y GitHub comenzaron con la misma historia:

LOCAL                 GITHUB

A ── B                A ── B

Nosotros hacemos un nuevo commit:

LOCAL                 GITHUB

A ── B ── C           A ── B

Pero otra persona, o incluso nosotros mismos desde GitHub, agregamos otro commit al repositorio remoto:

LOCAL                 GITHUB

A ── B ── C           A ── B ── D

Ahora las historias son diferentes.

Si intentamos:

git push

Git puede rechazar el envío porque subir C directamente podría sobrescribir o ignorar el commit D que ya existe en GitHub.

Por eso podemos recibir un mensaje similar a:

! [rejected]        main -> main
error: failed to push some refsLenguaje del código: CSS (css)

9.2. ¿Qué debemos hacer si el push es rechazado?

En primer lugar, no debemos utilizar inmediatamente git push --force para intentar solucionar el problema.

Lo habitual es traer primero los cambios que existen en el repositorio remoto.

Podemos utilizar:

git pull

Esto descarga los cambios remotos e intenta integrarlos con nuestra rama local.

Después, si la integración se realiza correctamente, podemos volver a ejecutar:

git push

El flujo sería:

git push
   ↓
Push rechazado
   ↓
git pull
   ↓
Integrar cambios
   ↓
git push
   ↓
GitHub actualizado

9.3. ¿Qué pasa si aparece un conflicto?

En algunos casos, git pull puede provocar un conflicto de Git si nuestros cambios y los cambios remotos modificaron las mismas partes de un archivo.

Por ejemplo:

LOCAL                  GITHUB

index.html             index.html
   │                       │
   └── cambio A            └── cambio BLenguaje del código: CSS (css)

Git no puede decidir automáticamente cuál de los dos cambios debe conservar.

En ese caso tendremos que resolver el conflicto manualmente, agregar los archivos resueltos y completar la integración.

Después podremos volver a ejecutar:

git push

9.4. Ejemplo práctico

Supongamos que tenemos:

LOCAL:     A ── B ── C
GITHUB:    A ── B ── DLenguaje del código: HTTP (http)

Intentamos:

git push

Git lo rechaza porque GitHub tiene el commit D, que todavía no tenemos localmente.

Entonces podemos ejecutar:

git pull

Si no hay conflictos, Git integra los cambios y podremos volver a hacer:

git push

El objetivo será que ambas historias queden sincronizadas:

LOCAL                  GITHUB

A ── B ── D ── C       A ── B ── D ── C

9.5. ¿Por qué no conviene hacer git push --force?

Un push rechazado no significa necesariamente que debamos forzar el envío.

Utilizar:

git push --force

puede sobrescribir la historia que existe en el repositorio remoto y provocar que se pierdan commits que ya estaban publicados.

Por eso, ante un push rechazado, la primera opción normalmente es traer e integrar los cambios remotos, resolver los posibles conflictos y luego volver a hacer push.

RESUMEN: Un git push rechazado generalmente significa que el repositorio remoto tiene cambios que nuestra copia local todavía no tiene o que Git no puede integrar automáticamente. En lugar de forzar el envío, debemos analizar el motivo, traer los cambios y resolver cualquier conflicto antes de volver a ejecutar git push.

10. git push –force: cómo forzar un push

Normalmente, Git evita que hagamos un push cuando nuestros cambios podrían sobrescribir o modificar la historia que ya existe en el repositorio remoto. Sin embargo, en determinadas situaciones podemos necesitar forzar el envío de nuestros cambios, indicándole a Git que acepte nuestra historia local aunque sea diferente de la que existe en GitHub.

Para hacerlo podemos utilizar:

git push --force

o su forma abreviada:

git push -f

Es un comando potente y que debe utilizarse con mucha precaución, especialmente cuando trabajamos en ramas compartidas con otros desarrolladores, ya que puede reemplazar commits que existen en el repositorio remoto.

10.1. ¿Para qué sirve git push –force?

git push --force permite forzar la actualización de una rama remota utilizando nuestra historia local, incluso cuando Git normalmente rechazaría el push.

Un escenario habitual ocurre cuando modificamos la historia de nuestra rama utilizando git rebase, git reset u otras operaciones que cambian los commits existentes.

Por ejemplo, podemos tener:

LOCAL:

A ── B ── D

GITHUB:

A ── B ── C

Las historias ya no coinciden.

Si intentamos:

git push

Git puede rechazar el envío.

Si estamos seguros de que queremos que el remoto adopte nuestra historia local, podemos utilizar:

git push --force

El resultado podría ser:

GITHUB:

A ── B ── D

El commit C deja de formar parte de la historia de esa rama remota.

10.2. ¿Cuándo puede ser necesario utilizarlo?

Un caso frecuente es después de realizar un rebase.

Por ejemplo:

git rebase -i HEAD~3

Durante un rebase podemos modificar, combinar, eliminar o reorganizar commits.

Como consecuencia, los hashes de los commits pueden cambiar.

Por ejemplo:

Antes:

A ── B ── C ── D


Después del rebase:

A ── B ── X ── Y

Aunque los cambios puedan ser equivalentes, para Git se trata de una historia diferente.

Si esa rama ya estaba publicada en GitHub, un git push normal puede ser rechazado. En determinadas circunstancias podemos necesitar:

git push --force

10.3. Ejemplo práctico

Supongamos que tenemos una rama llamada desarrollo que ya publicamos en GitHub:

git push -u origin desarrollo

Después decidimos reorganizar los últimos commits:

git rebase -i HEAD~3

Una vez terminado el rebase, intentamos:

git push

y Git rechaza el envío porque nuestra historia local ya no coincide con la historia remota.

Si comprobamos que el resultado es correcto y estamos seguros de que queremos reemplazar la historia remota de esa rama, podríamos utilizar:

git push --force

También podemos indicar explícitamente el remoto y la rama:

git push --force origin desarrollo

10.4. ¿Qué riesgos tiene git push –force?

El principal riesgo es que podemos sobrescribir commits que actualmente existen en el repositorio remoto.

Por ejemplo:

GITHUB:

A ── B ── C ── D

Mientras que nuestro repositorio local tiene:

LOCAL:

A ── B ── X

Si hacemos:

git push --force

podríamos terminar con:

GITHUB:

A ── B ── X

Los commits C y D dejan de formar parte de la historia de esa rama.

Por eso no es recomendable utilizar git push --force indiscriminadamente, especialmente sobre main o sobre ramas en las que trabajan varias personas.

10.5. ¿Es mejor utilizar –force-with-lease?

En muchas situaciones es preferible utilizar:

git push --force-with-leaseLenguaje del código: JavaScript (javascript)

Esta opción también permite realizar un push forzado, pero incorpora una comprobación adicional: Git verifica que el estado remoto sea el que esperamos antes de sobrescribirlo.

Por ejemplo:

git push --force-with-leaseLenguaje del código: JavaScript (javascript)

Esto proporciona una protección adicional frente a una situación como esta:

Tú                  Otro desarrollador

      ┌── trabaja ──┐
      ↓             ↓
   haces rebase   hace un commit
      ↓             ↓
   force push      GitHub

Si el repositorio remoto cambió de una manera que no esperabas, --force-with-lease puede rechazar el push en lugar de sobrescribir esos cambios.

Por eso, como regla general:

git push --force-with-leaseLenguaje del código: JavaScript (javascript)

suele ser una alternativa más segura que:

git push --force

cuando realmente necesitamos reescribir la historia remota.

10.6. ¿Cuándo NO utilizar git push –force?

Debemos evitarlo especialmente cuando:

• Trabajamos sobre main compartida.
• Otros desarrolladores están trabajando sobre la misma rama.
• No sabemos por qué Git rechazó nuestro push.
• No hemos comprobado qué cambios existen en el repositorio remoto.
• Podemos solucionar el problema integrando primero los cambios remotos.

Si simplemente recibimos un rejected, no debemos asumir que la solución es git push --force. Primero debemos averiguar por qué fue rechazado.

11. ¿Cómo revertir un git push?

Cuando hacemos un git push, los commits que tenemos en nuestro repositorio local pasan a estar disponibles en el repositorio remoto, por ejemplo, en GitHub. Si posteriormente descubrimos que uno de esos commits contiene un error, podemos deshacer sus cambios sin necesidad de eliminar el commit de la historia.

La forma más segura y habitual de hacerlo es utilizar git revert.

NOTA! Es importante aclarar que no existe un comando git unpush para «deshacer» un git push. Lo que hacemos es revertir el commit que ya fue publicado y después volver a utilizar git push para enviar ese nuevo cambio a GitHub.

11.1. ¿Cómo revertir un commit que ya subimos a GitHub?

Supongamos que tenemos este historial:

A ── B ── C

El commit C contiene un cambio que queremos deshacer y ya lo hemos enviado a GitHub mediante:

git push

Primero podemos consultar el historial:

git log --oneline

Por ejemplo:

c82f31d Actualiza página de inicio
91bc42a Agrega formulario de contacto

Si queremos deshacer c82f31d, ejecutamos:

git revert c82f31d

Git creará un nuevo commit que revierte los cambios realizados por c82f31d.

El historial quedará aproximadamente así:

A ── B ── C ── D
          ↑     ↑
       cambio  revert

El commit original C sigue existiendo en el historial, pero D contiene la operación que deshace sus cambios.

Finalmente, debemos subir el nuevo commit:

git push

11.2. ¿Puedo revertir varios commits?

Sí. Podemos revertir diferentes commits, aunque cuando se trata de varios cambios conviene analizar el historial antes de realizar la operación.

También podemos utilizar:

git revert <hash>Lenguaje del código: HTML, XML (xml)

para cada commit que necesitemos revertir.

Si los commits están relacionados, debemos prestar atención al orden y a los posibles conflictos que puedan producirse.

11.3. ¿Qué pasa si aparece un conflicto al hacer git revert?

Al revertir un commit, Git puede encontrar conflictos si posteriormente se modificaron las mismas partes de los archivos.

En ese caso, Git nos indicará que debemos resolverlos manualmente.

Después de solucionar los archivos afectados:

git add .

y podemos continuar la operación con:

git revert --continueLenguaje del código: JavaScript (javascript)

Una vez completado el revert, podemos subir el nuevo commit:

git push

11.4. ¿Y si quiero eliminar completamente el commit de GitHub?

Eso es diferente de revertir un commit.

Si lo que queremos es eliminar el commit de la historia y reescribir la rama, podemos recurrir a herramientas como git reset y posteriormente a un push forzado:

git push --force-with-leaseLenguaje del código: JavaScript (javascript)

Pero esta estrategia debe utilizarse con mucha precaución, especialmente en ramas compartidas.

Para la mayoría de los casos en los que simplemente queremos deshacer un cambio que ya publicamos, git revert es una alternativa mucho más segura.

12. Errores frecuentes

Aunque git push es un comando sencillo, es habitual encontrarnos con diferentes errores cuando comenzamos a trabajar con repositorios remotos. Algunos aparecen porque GitHub tiene cambios que todavía no tenemos localmente, mientras que otros están relacionados con la rama, la autenticación o la configuración del repositorio remoto.

A continuación veremos los errores más frecuentes y qué podemos hacer en cada caso.

Error	Causa habitual	Posible solución
rejected	El remoto tiene cambios que no tenemos	git pull y luego git push
Everything up-to-date	No hay nuevos commits para enviar	Comprobar git status
src refspec main does not match any	Rama inexistente o sin commits	Comprobar git branch y crear un commit
not a git repository	No estamos dentro de un repositorio Git	Entrar en la carpeta correcta o usar git init
No configured push destination	No hay remoto configurado	Configurar git remote
Authentication failed	Problema de autenticación	Revisar las credenciales/autenticación
Permission denied	No tenemos permisos	Comprobar los permisos del repositorio
remote contains work	El remoto tiene commits nuevos	Traer e integrar los cambios
Push rechazado después de rebase	Se modificó la historia	Evaluar --force-with-lease

12.1. ¿Qué hacer cuando git push da un error?

Ante un error de git push, lo recomendable es leer primero el mensaje que proporciona Git y determinar cuál es la causa.

Un flujo de comprobación puede ser:

git status
git branch
git remote -v
git log

Con estos comandos podemos comprobar:

• En qué estado está nuestro repositorio.
• En qué rama estamos.
• Qué repositorio remoto tenemos configurado.
• Qué commits existen en nuestra historia.

Y, dependiendo del problema, podremos tomar la acción correspondiente.

NOTA! La recomendación más importante es no utilizar git push --force como solución automática ante un error. Primero debemos identificar por qué Git rechazó el push; en muchos casos, la solución correcta simplemente consiste en traer los cambios remotos, integrarlos y volver a hacer push.

13. Buenas prácticas

Buena práctica	¿Por qué es importante?
Revisar los cambios antes de hacer push	Permite comprobar qué archivos fueron modificados y evitar subir cambios no deseados.
Hacer commits claros y descriptivos	Facilita entender qué se modificó en cada versión del proyecto.
Hacer git pull antes de trabajar en equipo	Ayuda a tener los cambios más recientes del repositorio remoto y reduce conflictos.
Verificar la rama antes de hacer push	Evita enviar cambios accidentalmente a main u otra rama incorrecta.
Usar ramas para nuevas funcionalidades	Permite trabajar de forma aislada sin afectar directamente la rama principal.
Evitar git push --force innecesariamente	Puede sobrescribir cambios que ya están en el repositorio remoto.
Preferir --force-with-lease cuando sea necesario	Es una alternativa más segura cuando realmente necesitás sobrescribir el historial remoto.
No subir información sensible	Contraseñas, tokens, claves API y otros secretos nunca deberían llegar a GitHub.
Comprobar el repositorio remoto	git remote -v permite confirmar que estás enviando los cambios al repositorio correcto.
Hacer pushes frecuentes	Mantiene el repositorio remoto actualizado y reduce la cantidad de cambios acumulados.
Revisar los commits pendientes antes del push	git log origin/main..main permite saber qué commits locales todavía no fueron enviados.
No usar --force para solucionar un rejected sin analizarlo	Un rechazo normalmente indica que el remoto tiene cambios que primero deberían integrarse.

13.1. Una recomendación especialmente importante

Para alguien que está aprendiendo Git, destacaría estas 3 reglas principales:

1. Revisá los cambios antes de hacer git push.
2. Verificá siempre en qué rama estás.
3. No uses git push --force como solución automática a un error.

Esto ayuda a evitar muchos de los problemas más habituales al trabajar con Git y GitHub.