Realizar commits y pushes hacia GitHub

Una vez que has clonado un repositorio de GitHub a tu máquina local, puedes comenzar a realizar cambios en los archivos. Para que estos cambios se reflejen en el repositorio remoto, necesitas seguir un flujo de trabajo que involucra hacer commits localmente y luego enviarlos (push) a GitHub.

El flujo de trabajo básico

El proceso para enviar cambios a GitHub sigue generalmente estos pasos:

1. Modificar archivos en tu repositorio local
2. Añadir los archivos modificados al área de preparación (staging)
3. Hacer commit de los cambios en tu repositorio local
4. Enviar (push) los commits al repositorio remoto en GitHub

Vamos a explorar cada uno de estos pasos en detalle.

1. Modificar archivos

Lo primero que necesitas hacer es realizar cambios en los archivos de tu repositorio local. Esto puede incluir:

• Crear nuevos archivos
• Modificar archivos existentes
• Eliminar archivos
• Renombrar o mover archivos

Puedes realizar estos cambios usando cualquier editor de código o herramienta que prefieras.

2. Añadir archivos al área de preparación

Una vez que has realizado cambios, necesitas indicarle a Git qué cambios quieres incluir en el próximo commit. Esto se hace añadiendo los archivos al "área de preparación" (staging area).

# Añadir un archivo específico
git add archivo.txt

# Añadir múltiples archivos
git add archivo1.txt archivo2.js

# Añadir todos los archivos modificados
git add .

# Añadir todos los archivos de un tipo
git add *.js

# Añadir interactivamente (seleccionar partes específicas)
git add -p

Después de añadir los archivos, puedes verificar el estado con:

git status

Esto te mostrará qué archivos están en el área de preparación (listos para commit) y cuáles aún tienen cambios sin preparar.

3. Hacer commit de los cambios

Una vez que has añadido los archivos al área de preparación, puedes crear un commit que registre estos cambios en el historial del repositorio local:

git commit -m "Mensaje descriptivo del commit"

Buenas prácticas para mensajes de commit

Un buen mensaje de commit debe:

1. Ser claro y descriptivo
2. Usar el modo imperativo ("Añade función" en lugar de "Añadida función")
3. Tener una primera línea breve (50 caracteres o menos)
4. Opcionalmente, incluir más detalles después de una línea en blanco

Ejemplo de un buen mensaje de commit:

git commit -m "Implementa autenticación con Google OAuth

- Añade endpoint para manejar la redirección de OAuth
- Integra el SDK de Google para verificar tokens
- Actualiza la documentación de autenticación"

Commits con mensaje en editor

Si omites la opción -m, Git abrirá tu editor de texto configurado para que escribas un mensaje más detallado:

git commit

Atajos útiles

# Añadir y hacer commit en un solo paso (solo para archivos ya rastreados)
git commit -am "Mensaje del commit"

# Modificar el último commit (si aún no has hecho push)
git commit --amend

4. Enviar (push) los cambios a GitHub

Después de hacer uno o más commits locales, puedes enviarlos al repositorio remoto en GitHub:

git push origin main

Donde:

• origin es el nombre del repositorio remoto (por defecto cuando clonas)
• main es el nombre de la rama que estás enviando

Primera vez que haces push

Si es la primera vez que envías una rama local a GitHub, es buena práctica establecer la relación de seguimiento (tracking):

git push -u origin main

La opción -u (o --set-upstream) configura la rama local para que "siga" a la rama remota. Después de esto, puedes usar simplemente git push sin argumentos adicionales.

Verificar antes de push

Antes de hacer push, es buena idea verificar qué commits vas a enviar:

# Ver los commits que están en tu rama local pero no en la remota
git log origin/main..HEAD

# O de forma más compacta
git log --oneline origin/main..HEAD

Flujo de trabajo completo: Ejemplo práctico

Veamos un ejemplo completo del flujo de trabajo:

# 1. Asegúrate de estar en la rama correcta
git checkout main

# 2. Actualiza tu repositorio local con los cambios remotos
git pull origin main

# 3. Crea una nueva rama para tu característica
git checkout -b feature/nueva-funcionalidad

# 4. Realiza cambios en los archivos
echo "Nueva funcionalidad" >> archivo.txt

# 5. Verifica los cambios
git status

# 6. Añade los cambios al área de preparación
git add archivo.txt

# 7. Haz commit de los cambios
git commit -m "Implementa nueva funcionalidad"

# 8. Envía la rama al repositorio remoto
git push -u origin feature/nueva-funcionalidad

# 9. (Opcional) Crea un Pull Request en GitHub
# Esto se hace desde la interfaz web de GitHub

Trabajar con ramas

Es una buena práctica crear ramas separadas para diferentes características o correcciones:

# Crear y cambiar a una nueva rama
git checkout -b nombre-de-rama

# Hacer cambios, añadirlos y hacer commit
git add .
git commit -m "Mensaje descriptivo"

# Enviar la rama a GitHub
git push -u origin nombre-de-rama

Sincronizar una rama con la rama principal

Si estás trabajando en una rama durante un tiempo, es buena idea mantenerla actualizada con los cambios de la rama principal:

# Estando en tu rama de característica
git fetch origin
git merge origin/main

# O usando rebase (crea un historial más limpio)
git fetch origin
git rebase origin/main

Autenticación para push

Cuando haces push a GitHub, necesitarás autenticarte:

Con HTTPS

Si estás usando URLs HTTPS, Git te pedirá tu nombre de usuario y contraseña de GitHub. Sin embargo, GitHub ya no acepta contraseñas directas para operaciones Git, por lo que necesitarás:

1. Crear un token de acceso personal en GitHub:
   • Ve a Settings > Developer settings > Personal access tokens
   • Genera un nuevo token con los permisos necesarios
   • Usa este token como contraseña cuando Git lo solicite
2. Configurar el almacenamiento de credenciales para no tener que ingresar el token cada vez:

   git config --global credential.helper cache  # Temporal
   # o
   git config --global credential.helper store  # Permanente
   

Con SSH

Si estás usando URLs SSH y has configurado correctamente tus claves SSH en GitHub, no necesitarás ingresar credenciales para hacer push.

Solución de problemas comunes

"Updates were rejected"

Problema: Tu push es rechazado porque el repositorio remoto tiene cambios que no tienes localmente.

Mensaje de error: ! [rejected] main -> main (fetch first)

Solución:

# Obtener los cambios remotos
git pull origin main

# Resolver conflictos si los hay
# ...

# Intentar push nuevamente
git push origin main

Conflictos al hacer pull

Problema: Al hacer pull, hay conflictos entre tus cambios locales y los remotos.

Solución:

1. Resolver los conflictos manualmente en los archivos afectados
2. Añadir los archivos resueltos: git add .
3. Completar el merge: git commit
4. Hacer push: git push origin main

"Permission denied"

Problema: No tienes permisos para hacer push al repositorio.

Solución:

1. Verifica que tienes acceso de escritura al repositorio
2. Comprueba tu autenticación (token o clave SSH)
3. Si es un repositorio de otro usuario, considera hacer fork y enviar un pull request

"Non-fast-forward updates were rejected"

Problema: Has reescrito el historial local (con rebase o amend) y ahora no coincide con el remoto.

Solución:

1. Si estás seguro de lo que haces: git push --force-with-lease origin main
2. O mejor, evita reescribir el historial de ramas compartidas

Buenas prácticas

1. Pull antes de push

Siempre actualiza tu repositorio local antes de hacer push para minimizar conflictos:

git pull origin main
git push origin main

2. Commits pequeños y frecuentes

Haz commits pequeños y enfocados en un solo cambio lógico. Esto facilita la revisión y el seguimiento de problemas.

3. Mensajes de commit descriptivos

Escribe mensajes claros que expliquen el "qué" y el "por qué" del cambio, no solo el "cómo".

4. Usa ramas para características

Desarrolla nuevas características en ramas separadas en lugar de trabajar directamente en la rama principal.

5. Revisa tus cambios antes de commit

Usa git diff --staged para revisar exactamente qué cambios estás a punto de confirmar.

6. No hagas commit de archivos generados

Usa .gitignore para excluir archivos generados, dependencias, configuraciones locales, etc.

7. Verifica el estado después de cada operación

Usa git status frecuentemente para entender el estado actual de tu repositorio.

Herramientas visuales

Si prefieres una interfaz gráfica para realizar estos procesos, hay varias opciones:

• GitHub Desktop: Cliente oficial de GitHub con interfaz simple
• GitKraken: Interfaz gráfica potente con visualización de ramas
• Sourcetree: Cliente visual gratuito de Atlassian
• Visual Studio Code: Editor de código con integración Git incorporada
• IntelliJ IDEA/WebStorm/PyCharm: IDEs con excelente soporte para Git

Conclusión

Dominar el flujo de trabajo de commits y pushes es fundamental para colaborar efectivamente usando Git y GitHub. A medida que te familiarices con estos comandos, podrás trabajar más eficientemente y contribuir a proyectos de forma organizada.

Recuerda que Git es una herramienta poderosa con muchas opciones y capacidades. No dudes en explorar la documentación oficial o recursos adicionales para profundizar en aspectos específicos que sean relevantes para tu flujo de trabajo.

En la próxima lección, aprenderemos sobre Markdown, el lenguaje de marcado que se utiliza para documentar proyectos en GitHub a través de archivos README y otros documentos.