Git & GitHub – DÍA 3

Conectar Git con GitHub: repositorios remotos, push, pull, HTTPS vs SSH, token personal

1. Objetivo del día

Hoy aprenderás a:

crear tu primer repositorio en GitHub
conectarlo con tu repositorio local
subir (push) tus commits
descargar cambios del remoto (pull)
entender remotes (origin)
elegir entre HTTPS o SSH
configurar token o clave SSH
evitar errores comunes al subir contenido

Si hoy consigues subir tu repositorio → Día 3 completado.

2. Crear tu cuenta en GitHub (si no la tienes)

https://github.com

Una vez creada, inicia sesión.

3. Crear un repositorio en GitHub

Dentro de GitHub:

New Repository → New

Selecciona:

Repository name: (ej. mis-scripts)
Description: opcional
Visibility:
- PRIVATE → recomendado para scripts personales
- PUBLIC → solo si no hay ninguna clave o dato sensible

⚠️ No marques “Add README”
Porque ya tienes tu repo local y queremos vincularlo sin conflictos.

Pulsa Create Repository.

Se abrirá una página con instrucciones.

⚠️ Muy importante: ¿Público o privado? (Evitar desastres)

Antes de empezar un repositorio en GitHub, debes tener clarísimo esto:

✔ Repositorio PÚBLICO

Cualquiera en Internet puede ver tu contenido.
NO subas jamás:

contraseñas
tokens
claves SSH
API keys
archivos .env
configuraciones sensibles
IPs internas
información personal
datos de tu empresa

Una vez subido queda para siempre en el historial.

✔ Repositorio PRIVADO

Solo tú (y quien invites) podrá verlo.
Ideal para scripts personales, pruebas, automatizaciones o documentación interna.

RECOMENDACIÓN TOTAL:
👉 Para este curso y tus scripts personales: repos PRIVADOS.

✔ .gitignore para evitar problemas

Crea un archivo:

nano .gitignore

Y añade:

*.log
*.tmp
.env
config/*.json
credenciales/

Para que Git ignore todo eso.

¿Qué es el archivo `.gitignore` y por qué debes usarlo?

El archivo .gitignore sirve para indicar a Git (en tu ordenador) qué archivos debe ignorar por completo, evitando que se añadan a un commit y que, por tanto, terminen subidos a GitHub.

Lo usas para impedir que se suban a un repositorio:

archivos sensibles
ficheros temporales
logs
configuraciones locales
carpetas generadas por editores o herramientas

GitHub no interpreta el .gitignore:
Git lo aplica antes de subir nada, así que lo colocas en tu repositorio local.

Dónde se coloca

En la raíz del repositorio, es decir, en el mismo sitio donde hiciste:

git init

Ejemplo:

mi-proyecto/
 ├─ script.py
 ├─ README.md
 └─ .gitignore

Efecto real

Si un archivo está listado en .gitignore, Git no lo añadirá, incluso aunque hagas:

git add .

Así evitas errores graves como subir .env con claves, o logs internos de tu empresa.

Ejemplo recomendado de `.gitignore`

Crea el archivo:

nano .gitignore

Y añade:

*.log
*.tmp
.env
config/*.json
credenciales/

⚠ Importante

.gitignore solo ignora archivos que aún no se hayan añadido antes.
Si ya hiciste commit de algo sensible, debes retirarlo del historial de Git:

git rm --cached fichero

4. Elegir método de autenticación: HTTPS o SSH

✔ Opción 1 — HTTPS (más fácil para principiantes)

Cuando hagas git push te pedirá usuario y un token personal, no contraseña.

Necesitas crear un token si no tienes uno:

GitHub → Settings → Developer settings → Personal access tokens → Fine-grained tokens
Crea un token con permisos:

repo → lectura/escritura

Guárdalo en un gestor de contraseñas (NO lo pongas en un repo).

✔ Opción 2 — SSH (más profesional)

Recomendado si usas Linux, macOS o WSL.

Generar clave:

ssh-keygen -t ed25519 -C "tuemail@example.com"

Copiar clave pública:

cat ~/.ssh/id_ed25519.pub

Ir a GitHub:

Settings → SSH and GPG keys → New SSH Key

Pegar la clave.

Listo.

5. Conectar tu repositorio local con GitHub

Supongamos que estás dentro de tu repo local:

cd mis-scripts

Ahora añade el remoto “origin”:

Si usas HTTPS:

git remote add origin https://github.com/TU_USUARIO/mis-scripts.git

Si usas SSH:

git remote add origin git@github.com:TU_USUARIO/mis-scripts.git

Comprobar:

git remote -v

Debe mostrar: si es https

origin   https://github.com/usuario/mis-scripts.git (fetch)
origin   https://github.com/usuario/mis-scripts.git (push)

o lo siguiente si es ssh

origin   git@github.com/usuario/mis-scripts.git (fetch)
origin   git@github.com/usuario/mis-scripts.git (push)

6. Subir tu trabajo por primera vez (push inicial)

Si tu rama principal se llama main (actual estándar):

git push -u origin main

Si tu repo tiene master:

git push -u origin master

El parámetro -u crea el vínculo entre tu rama local y la remota.

✔ ¿Tu rama se llama `main` o `master`? (Muy importante antes del primer push)

GitHub usa main como rama principal por defecto, pero en tu ordenador Git puede crear master dependiendo de la versión o de tu configuración.

Por eso, antes de hacer el primer push, debes comprobar qué rama tienes realmente.

Ver tu rama actual

Ejecuta:

git branch

Verás algo así:

* main

* master

El asterisco indica tu rama activa.

Hacer el push inicial según tu rama

Si tu rama es `main`:

git push -u origin main

Si tu rama es `master`:

git push -u origin master

El parámetro -u crea el vínculo entre la rama local y la remota.
Después de esto, ya podrás usar simplemente:

git push

Tip: ¿Debo cambiar de `master` a `main`?

No es obligatorio.

Puedes seguir usando master sin problema.
Si quieres modernizarlo más adelante, puedes renombrarla, pero no afecta a este mini tutorial.

7. Descargar cambios del remoto (pull)

Si tú o alguien más modifica el repo en GitHub:

git pull

Esto sincroniza los cambios desde GitHub a tu equipo.

8. Ver y gestionar los remotos

Ver remotos:

git remote -v

Eliminar un remoto:

git remote remove origin

Cambiar URL (útil si pasas de HTTPS a SSH):

git remote set-url origin git@github.com:usuario/repositorio.git

9. Flujo real local ↔ remoto

El ciclo profesional es:

git status
git add .
git commit -m "mensaje claro"
git push

Y si hay cambios externos:

git pull

10. Problemas comunes y soluciones (MUY IMPORTANTE)

❌ “Authentication Failed”

→ Estás usando contraseña (GitHub YA NO PERMITE contraseñas).
Solución: usar token o SSH.

❌ “Repository not found”

→ La URL está mal o el repositorio es privado.
Solución: revisa el git remote -v.

❌ “Error: failed to push some refs”

→ Hay cambios en GitHub que no tienes localmente.
Solución:

git pull --rebase
git push

❌ Subí por error un archivo con claves

Solución:

Borrarlo:

git rm archivo
git commit -m "Elimino archivo sensible"
git push

Y rotar inmediatamente esa clave (porque pudo quedar en el historial).
Si fue público: tratar como comprometida.

✅ Flujo real entre tu máquina y GitHub (local ↔ remoto)

Cuando trabajas con Git, hay dos direcciones posibles:

Tú subes cambios a GitHub
Tú bajas cambios desde GitHub

Aquí tienes el resumen práctico que usarás siempre.

🔼 Cuando tú haces cambios en local → subir a GitHub

Cada vez que edites algo en tu máquina:

git add .
git commit -m "mensaje claro"
git push

Con esto GitHub queda actualizado con tu trabajo.

🔽 Cuando los cambios vienen desde GitHub → traerlos a tu máquina

Si editaste algo directamente en GitHub, hiciste un merge allí, o alguien más tocó el repo:

git pull

Esto sincroniza tu copia local con la rama remota.

⚠️ Si hay cambios en ambos sitios a la vez

Si tú has hecho commits y también hay cambios nuevos en GitHub, Git no te dejará hacer push hasta que te sincronices:

git pull --rebase
git push

--rebase reordena tus commits para evitar un merge innecesario y mantener el historial limpio.

🧩 Tabla resumen para no liarse

Situación	Qué hacer	Comando
Tú has cambiado cosas en tu máquina y quieres subirlas	Subir cambios al remoto	`git push`
Hay cambios en GitHub que tú no tienes	Traer cambios del remoto	`git pull`
Hay cambios en GitHub y tú también hiciste commits	Sincronizar y luego subir	`git pull --rebase` → `git push`

11. Práctica guiada (20–30 minutos)

Crear repositorio en GitHub (privado).
Conectar tu repo local: git remote add origin <URL>
Subir tus commits: git push -u origin main (o master)
Modificar un archivo en GitHub (web).
Descargar el cambio: git pull
Modificar algo en local y volver a subir: git add . git commit -m "Cambio local" git push

12. Checklist del Día 3

Repo creado en GitHub
Remote añadido (origin)
Push inicial completado
Pull funcionando
Autenticación configurada (HTTPS o SSH)
No subes archivos sensibles
Entiendes push/pull de verdad

Si todo está marcado → Día 3 superado.

13. Ejercicio sugerido

Crea un repositorio privado en GitHub llamado:

mis-utilidades

En tu PC:

crear un directorio local mis-utilidades/
inicializar Git
conectar con GitHub
subir varios scripts
modificar uno en GitHub
sincronizar con pull
hacer commit de un cambio local
hacer push

Este es el flujo profesional del 90% del trabajo diario.

14. Día 3 completado

🎉 ¡Ya estás en la nube!
Tus scripts ya no viven solo en tu PC: tienes control de versiones local y remoto.

Mañana entramos a un tema increíblemente útil:

👉 Día 4 – Ramas (branches): crear, unir, resolver conflictos simples como un profesional.

Aquí es donde Git se convierte en tu mejor aliado.