Abre cualquier computador de trabajo y busca la carpeta de un proyecto que haya durado más de dos meses. Casi siempre aparece lo mismo:
propuesta.docx · propuesta_v2.docx ·
propuesta_final.docx · propuesta_final_CORREGIDA.docx ·
propuesta_final_ESTE_SI.docx
Ese sistema funciona, más o menos, hasta el día en que alguien pregunta algo perfectamente razonable: «¿qué le cambiaste entre la tercera y la cuarta, y por qué?». Y no hay forma de responder. La información existió, pero nadie la guardó: los archivos conservan el resultado de cada cambio y pierden el cambio y su motivo.
Un control de versiones no guarda copias del archivo. Guarda los cambios, en orden, cada uno con su explicación y su autor. Esa es toda la diferencia, y es la razón por la que se puede volver atrás sin haber previsto que ibas a necesitarlo.
Git es un programa que se instala en tu computador y vigila una carpeta. Cuando tú se lo pides, toma una fotografía completa del estado de esa carpeta -todos los archivos a la vez, no uno- y la guarda en el historial junto a tu nombre, la fecha y una frase que tú escribes explicando qué hiciste.
Esa fotografía se llama commit, y es la unidad de todo lo demás. Desde el momento en que existe puedes volver a ella, compararla con cualquier otra o recuperar de ella un solo archivo. Sin haber hecho ninguna copia.
La carpeta que Git vigila. Al convertirla en repositorio, Git
crea dentro una subcarpeta oculta llamada .git donde guarda
todo el historial.
Si borras esa subcarpeta, la carpeta vuelve a ser una carpeta normal y se pierde el historial completo. Los archivos siguen ahí.
Una fotografía del proyecto entero en un momento dado, con un mensaje que explica qué cambió.
No es «guardar el archivo»: guardar es cosa de tu editor. Un commit es decir «este estado del proyecto merece quedar en el historial».
La lista de todos los commits, del más reciente al más antiguo.
Es lo que convierte la carpeta en algo que se puede auditar: quién tocó qué, qué día y con qué razón.
Git no es GitHub, y confundirlos hace perder la primera semana. Git es el programa que llevas instalado y funciona sin internet: puedes trabajar un año entero con historial completo sin crear ninguna cuenta en ningún sitio. GitHub es una página web donde se guarda una copia del repositorio para compartirlo con otras personas. Existen otras -GitLab, Bitbucket, o un servidor propio- y todas hablan con el mismo Git.
Lo verás en la lección 6. Las lecciones 1 a 5 no necesitan conexión.
Git es gratuito y de código abierto. La versión publicada cuando se escribió esta lección es la 2.55.0; cualquier versión reciente te sirve para el curso completo.
Descarga el instalador desde git-scm.com y acepta las opciones que vienen marcadas. Trae de regalo Git Bash, una terminal que entiende los mismos comandos que Linux y macOS, así que todo lo que veas en este curso te va a funcionar igual.
Al terminar, abre Git Bash desde el menú de inicio.
Abre la aplicación Terminal y escribe git
--version. Si no lo tienes, macOS te ofrece instalarlo solo. También
puedes instalarlo con Homebrew: brew install git.
Una línea en la terminal:
sudo apt update && sudo apt install git.
git --versiongit version 2.55.0
Git firma cada commit con un nombre y un correo. No los adivina: hay que
dárselos una sola vez, y quedan guardados para todos los repositorios de tu usuario.
Eso es lo que significa --global.
git config --global user.name "Ana Gomez"
git config --global user.email "ana.gomez@empresa.com"
git config --global init.defaultBranch main
# Para ver como quedo:
git config --global --listuser.name=Ana Gomez user.email=ana.gomez@empresa.com init.defaultBranch=main
La tercera línea no es un capricho, y casi ningún tutorial la
explica bien. La documentación oficial de git init dice que el
nombre de la rama inicial es «currently master, but this will change to main
when Git 3.0 is released»: es decir, hoy Git todavía crea
master. GitHub, en cambio, llama main a la rama
principal de los repositorios nuevos.
Si no configuras nada, terminas con una rama master en tu equipo y
una main en GitHub, y el primer intento de subir falla con un mensaje
que no explica esto. Esa línea lo evita de una vez y para siempre.
Intenta responder antes de voltear cada tarjeta.
Git no sabe qué hay dentro de los archivos: guarda cambios en
texto, sea código, un contrato, una plantilla de cotización, un
.csv de precios o la configuración de un servidor.
Donde no rinde igual es con archivos binarios grandes -un
.docx, un .xlsx, un video-: los guarda, pero no
puede mostrarte qué línea cambió, porque por dentro no son texto.
Por eso muchos equipos llevan en Git lo que es texto y dejan lo demás en la
nube de archivos.
Existen programas con ventanas -GitHub Desktop, la vista de control de código de Visual Studio Code, GitKraken- y son perfectamente válidos.
Este curso enseña los comandos porque son los mismos en todas partes: en tu equipo, en el de un compañero y en un servidor al que entras por SSH y que no tiene ventanas. Quien entiende los comandos usa cualquier ventana; al revés no funciona.
La nube de archivos sincroniza el último estado, y esa es justo su virtud y su límite: si alguien borra medio documento y se sincroniza, ese es el estado bueno para ella.
Git no sincroniza: acumula. Cada commit sigue ahí, con su mensaje, y volver a uno de hace tres meses es un comando, no un ticket de soporte.
¿Qué guarda exactamente un commit?
Te quedas sin internet una semana. ¿Puedes seguir usando Git?
.git de tu
equipo. La conexión solo hace falta para compartirlo con otras personas.¿Por qué se configura init.defaultBranch main?
master y que cambiará a main en Git 3.0.
Configurarlo evita empezar con dos nombres distintos en el equipo y en
GitHub.Ya tienes Git instalado y firmado con tu nombre. En la siguiente lección conviertes una carpeta real en repositorio, haces tu primer commit y aprendes lo único que Git no perdona: dejar entrar al historial un archivo con contraseñas.
Siguiente: Tu primer repositorio
Continuar