Git y GitHub
El registro del entrenamiento. Control de versiones para quien nunca lo ha usado, y una red de seguridad para cuando algo sale mal.
puede permitirse dar el siguiente
sin miedo.
Por qué existe Git
Todo el mundo ha tenido una carpeta con proyecto_final.zip, proyecto_final_v2.zip y proyecto_final_BUENO_este_sí.zip. Git es la respuesta profesional a ese problema: un sistema que guarda el historial completo de tu proyecto y te permite volver a cualquier punto anterior.
Pero su valor real no es el archivo: es la libertad de romper cosas. Cuando sabes que puedes volver atrás en dos segundos, experimentas. Y experimentar es exactamente lo que hace falta para aprender a programar.
Conviene separar dos cosas que se confunden constantemente. Git es el programa que corre en tu ordenador y gestiona el historial. GitHub es una empresa que aloja copias de esos historiales en internet. Puedes usar Git sin GitHub perfectamente. Lo contrario, no.
Los cuatro conceptos que hay que entender
Git tiene fama de difícil, y en parte lo es: su interfaz es notoriamente inconsistente. Pero el modelo mental de debajo es pequeño y coherente. Con estas cuatro ideas se cubre casi todo el uso diario.
1 · El repositorio
Una carpeta con una subcarpeta oculta .git dentro. Ahí vive todo el historial. Si borras .git, se pierde el historial pero no tus archivos actuales.
2 · Las tres zonas
Este es el concepto que más cuesta y el que más aclara. Un archivo puede estar en tres sitios:
- Directorio de trabajo — lo que ves y editas.
- Área de preparación (staging) — lo que has marcado para incluir en la próxima fotografía.
- Repositorio — las fotografías ya guardadas.
El área de preparación existe para que puedas guardar sólo parte de tus cambios. Al principio parece un paso de más; con el tiempo se agradece.
3 · El commit
Una fotografía del proyecto en un instante, con un mensaje que explica qué cambió y por qué. Un buen mensaje de commit es un regalo a tu yo futuro. arreglos varios no lo es.
4 · Las ramas
Una rama es simplemente un puntero móvil a un commit. Nada más. Crear una rama es instantáneo porque no copia archivos: sólo crea una etiqueta. Entender esto desmonta el 90% del misterio de Git.
El flujo diario
En la práctica, el 95% del uso de Git son estos cinco comandos:
# ¿qué ha cambiado?
git status
# marcar cambios para guardar
git add .
# guardar con un mensaje
git commit -m "Añade formulario de contacto"
# subir a GitHub
git push
# traer cambios de GitHub
git pullEso es todo durante los primeros meses. Las ramas, los merges y el rebase llegarán cuando trabajes con otras personas o quieras probar algo grande sin tocar lo que funciona.
Cuando algo sale mal
Va a pasar. Todo el mundo rompe algo en Git al principio, y el primer instinto —borrar la carpeta y volver a clonar— funciona sorprendentemente bien más veces de las que uno admitiría.
Pero hay un dato tranquilizador: en Git es muy difícil perder algo de verdad una vez que has hecho commit. Casi todo se puede recuperar. El problema no es la pérdida, es saber qué comando escribir, y para eso existe una web entera dedicada a "he hecho X, ¿cómo lo deshago?" que está en las fuentes de abajo.
Regla de supervivencia
Haz commit a menudo y con mensajes descriptivos. Un historial con muchos commits pequeños es fácil de arreglar. Un historial con un commit gigante cada dos semanas, no.
GitHub: qué aporta
Una copia de seguridad remota, un lugar donde colaborar, y —esto importa más de lo que parece— tu carta de presentación pública. Un perfil de GitHub con proyectos reales y commits regulares dice más que cualquier currículum.
Además, GitHub Pages publica cualquier repositorio con HTML como una web real y gratuita, con dominio propio si quieres. Es la vía más corta que existe entre "he hecho algo" y "está en internet".