Curso exprés · No. 17
Git registra cada versión de tu proyecto y deja que todo un equipo cambie los mismos archivos sin sobrescribirse entre sí. Casi todo el miedo que le tenemos viene de palabras desconocidas — commit, branch, rebase — no de una dificultad real. Aprende el puñado de términos y Git pasa de ser una fuente de pavor a la red de seguridad más tranquila que tendrás jamás.
Solo lo esencial · Una imagen por idea · Aprende las palabras
Antes de los comandos, el problema. Una vez que sientes el dolor que el control de versiones elimina, cada función de Git se lee como una respuesta evidente en lugar de jerga arbitraria.
La carpeta llena de archivos _final_v2_FINAL
Un escritorio sepultado en report.doc, report_v2.doc, report_final.doc, report_final_FINAL.doc — nadie sabe cuál es el actual, y la buena versión del martes se perdió para siempre.
Todos hemos vivido la forma manual de guardar versiones: copiar el archivo, añadir un sufijo, cruzar los dedos. Se desmorona al instante — no sabes cuál es el más nuevo, no puedes recuperar una versión que sobrescribiste, y que dos personas editen significa que una de ellas pierde su trabajo. El control de versiones es la herramienta creada para acabar con esto: un proyecto, con todo su historial guardado a salvo y cada versión recuperable.
Git mantiene una línea de tiempo de snapshots
Una cámara que fotografía todo tu proyecto cada vez que dices «save this» — para que puedas volver a ver exactamente cómo se veía todo en cualquier momento del pasado.
Git es el sistema de control de versiones que usa casi todo el mundo. Registra tu proyecto como una serie de snapshots — cada uno una imagen completa de todos tus archivos en un momento que elegiste guardar. El resultado es una línea de tiempo por la que puedes viajar: ver qué cambió, cuándo y quién lo hizo, y volver a cualquier estado pasado. Es un botón de guardar que nunca olvida ni un solo guardado.
Un repository es el proyecto más todo su historial
Un libro que lleva consigo cada borrador que alguna vez fue, encuadernado al final — sostienes el texto actual y el registro completo de cómo llegó hasta ahí, juntos.
Un repository (o repo) es la carpeta de tu proyecto una vez que Git la está siguiendo: los archivos actuales más todo el historial oculto de cada snapshot tomado. Haz clone de un repo y obtienes no solo el código de hoy sino la historia completa. Esta es la unidad en la que trabajas — un repo es «a project Git remembers», y todo lo demás en este curso es algo que haces dentro de uno.
El control de versiones reemplaza la carpeta de copias _final_FINAL con un proyecto y un historial completo y recuperable. Git mantiene ese historial como una línea de tiempo de snapshots.
La palabra más importante de Git es commit — un snapshot guardado en la línea de tiempo. Entiende cómo se hace un commit y entenderás el latido de todo el sistema.
Un commit es un snapshot guardado
Una fotografía de todo tu proyecto en un instante elegido, archivada con una nota que dice qué fue este momento — fijada de forma permanente a la línea de tiempo.
Un commit es un snapshot en el historial de tu proyecto — un estado registrado de los archivos, con un ID único y una nota. Cada commit apunta de vuelta al anterior, formando la cadena que es tu historial. No haces commit constantemente; haces commit en puntos significativos — «added login», «arreglado el bug de la fecha» — para que la línea de tiempo se lea como una secuencia de pasos deliberados, cada uno un lugar al que puedes volver.
La staging area: empaca la caja antes de sellarla
Una caja de envío en tu escritorio: colocas dentro exactamente los artículos para este envío, dejando otros a un lado, y solo entonces la cierras con cinta y la mandas.
Git no toma un snapshot de todo lo que cambiaste de forma automática. Primero eliges qué cambios entran en el siguiente commit mediante staging — añadiéndolos a la staging area, la caja que estás empacando. Luego el commit sella solo esa caja. Este doble paso — hacer staging de lo que va junto, luego commit — es por lo que el historial de Git puede ser limpio: tú decides exactamente qué contiene cada snapshot en lugar de echarlo todo de golpe.
El mensaje es una nota para el futuro
Etiquetar esa caja sellada con lo que hay dentro — para que meses después, alguien que recorre el estante sepa qué guarda cada una sin abrirla.
Cada commit lleva un commit message que explica qué cambió y por qué. Parece una tarea pesada y es oro puro más adelante: cuando estás buscando el cambio que rompió algo, o entendiendo por qué existe una línea, los mensajes son la historia del proyecto. Un buen mensaje («fix timezone bug in invoice export») convierte el historial de un muro de IDs crípticos en un log legible. Escríbelos para la persona que los lea dentro de seis meses — normalmente tú.
HEAD es tu marcador de estás-aquí
El punto de «you are here» en un mapa de la línea de tiempo — marca sobre qué snapshot estás parado en este momento.
HEAD es el puntero de Git hacia dónde estás actualmente en el historial — normalmente el último commit de tu línea de trabajo actual. Cuando haces un nuevo commit, se añade justo después de HEAD, y HEAD avanza hacia él. Rara vez tocas HEAD directamente, pero la palabra aparece por todas partes, y saber que solo significa «mi posición actual en la línea de tiempo» desmitifica casi todo lo que vas a leer.
Un commit es un snapshot guardado. Haces staging de los cambios exactos que van juntos, luego los sellas con un mensaje — y HEAD marca dónde estás parado.
Los branches son donde Git deja de ser un botón de guardar elegante y se convierte en una forma de que muchas personas — o muchas ideas — avancen a la vez sin pisarse.
Un branch es una línea de trabajo paralela
Fotocopiar el manuscrito para garabatear una reescritura audaz en tu copia, mientras el original queda limpio y otros siguen trabajando en él.
Un branch es una línea de desarrollo independiente — tu propia copia de la línea de tiempo donde puedes hacer commits sin afectar el trabajo de nadie más. Inicias un branch para construir una función o probar una idea, haces commit libremente en él, y la versión principal queda intacta hasta que estás listo. El branching es cómo un equipo trabaja en diez cosas a la vez en un repo sin caos: cada quien en su propia línea.
main es la línea de confianza
La edición oficial y archivada del libro en la que todos confían — los borradores ocurren en otro sitio, y solo el trabajo terminado y aprobado se encuaderna en ella.
Por convención, el branch principal se llama main (todavía verás master en repos más antiguos). Está pensado para contener la versión estable y funcional del proyecto — la que enviarías. El trabajo nuevo ocurre en otros branches y solo se une a main una vez que está listo y revisado. Tratar a main como la línea de confianza, nunca como el borrador, es la disciplina sencilla detrás de la mayoría de los flujos de trabajo de equipo saludables.
Cambiar de branch cambia tus archivos
Intercambiar qué borrador está abierto en tu escritorio — el mismo escritorio, pero ahora mostrando una versión completamente distinta del trabajo, al instante.
Cuando haces switch (o check out) de un branch, Git cambia los archivos de tu carpeta para que coincidan con el snapshot de ese branch. Muévete a tu branch de función y tus ediciones aparecen; vuelve a main y desaparecen de la vista (guardadas a salvo, no perdidas). Los branches son baratos e instantáneos en Git, por lo que crear uno por función o arreglo es normal y se fomenta — no es un acto pesado sino un movimiento de cada día.
Un branch es una línea de trabajo paralela donde haces commit libremente sin molestar a nadie. main es la versión de confianza; el trabajo nuevo vive en su propio branch hasta que está listo.
El trabajo que se divide en branches con el tiempo tiene que volver a juntarse. El merging es cómo Git vuelve a unir las líneas — y el conflict es el único momento en que necesita que tú decidas.
El merging vuelve a juntar dos branches
Plegar las ediciones de tu borrador separado de nuevo dentro del manuscrito oficial, para que el libro contenga ahora tanto el original como tu nuevo capítulo.
El merging combina los commits de un branch en otro — normalmente plegando un branch de función terminado de vuelta en main. Git observa qué cambió en cada lado y los entreteje en una sola línea de tiempo que contiene ambos conjuntos de trabajo. La mayoría de las veces esto es automático y sin esfuerzo: los dos branches tocaron archivos distintos o partes distintas, y Git simplemente los cose.
Un conflict son dos ediciones a la misma línea
Dos editores que reescribieron exactamente la misma frase de forma distinta — ninguna máquina puede saber a cuál te referías, así que se detiene y te pregunta.
Un merge conflict ocurre cuando ambos branches cambiaron la misma parte del mismo archivo de maneras incompatibles. Git no puede adivinar qué versión es la correcta, así que se pausa y marca el punto, mostrando ambas versiones lado a lado. Esto no es un error ni un desastre — es Git negándose correctamente a descartar en silencio el trabajo de alguien. Los conflicts dan miedo la primera vez precisamente porque lo que está en juego (no perder trabajo) está claro.
Resolver un conflict es simplemente elegir
Leer ambas frases reescritas, luego escribir la versión final que realmente quieres — quedándote con una, con la otra, o con una mezcla — y seguir adelante.
Resuelves un conflict editando el archivo marcado a la versión que quieres — quédate con la tuya, con la de ellos, o combínalas — y luego haciendo commit del resultado. Ese es todo el misterio: un conflict es Git entregándote una decisión que solo un humano puede tomar, y resolverlo es tomar esa decisión. Los conflicts se vuelven más pequeños y raros cuando los branches son de corta vida y haces merge a menudo, para que los dos lados nunca se separen demasiado.
El merging entreteje dos branches en una sola línea de tiempo. Un conflict son solo dos ediciones a la misma línea — Git negándose a adivinar, y pidiéndote que elijas.
Hasta ahora todo vive en tu máquina. Trabajar con otros — o respaldar tu trabajo — significa conectar tu repo local a uno compartido en la nube.
Local y remote son dos copias
Tu copia de trabajo personal del manuscrito en casa, y la copia maestra compartida en la oficina con la que todo el equipo se mantiene sincronizado.
Git es distribuido: tienes una copia completa del repo en tu máquina (local), y normalmente hay una copia compartida en un servidor (remote) — en un servicio como GitHub o GitLab. Haces todo tu trabajo localmente — rápido, incluso sin conexión — y sincronizas con el remote para compartirlo e incorporar el trabajo de otros. El remote por defecto se llama por convención origin. Dos copias, mantenidas a la par a propósito.
Clone, push, pull, fetch
Fotocopiar la copia maestra de la oficina para llevarla a casa (clone), enviar por correo tus páginas terminadas (push) y recoger las páginas nuevas de todos los demás (pull).
Cuatro palabras mueven el trabajo entre local y remote. Clone hace tu primera copia local de un repo remoto. Push envía tus commits hacia el remote para que otros puedan verlos. Pull trae los nuevos commits de otros hacia tu copia. Fetch descarga lo que es nuevo sin hacerle merge todavía, para que puedas mirar primero. Domina estas cuatro y podrás colaborar — son todo el vocabulario de mantenerse sincronizado.
Los pull requests son cómo los equipos revisan el trabajo
Entregar tu nuevo capítulo a los editores, que lo leen, comentan y aprueban antes de que se encuaderne en el libro oficial.
En plataformas como GitHub, normalmente no haces merge directo en main. Haces push de tu branch y abres un pull request (PR) — una propuesta para hacer merge de tu trabajo, donde los compañeros lo revisan, dejan comentarios y aprueban antes de que se una a main. Es el punto de control donde un segundo par de ojos detecta problemas y el equipo acuerda que un cambio está listo. El PR es donde de verdad ocurre la mayor parte de la colaboración con Git en el mundo real.
Local es tu copia; remote (origin) es la compartida. Clone, push, pull y fetch las mantienen a la par — y un pull request es donde el equipo revisa antes de hacer merge.
El consuelo más profundo de Git es que casi nada se pierde de verdad jamás. Saber leer el historial y dar un paso atrás con seguridad es lo que convierte a Git de temible en tranquilizador.
El log es la historia del proyecto
Hojear la pila fechada y etiquetada de cada borrador — viendo exactamente qué cambió en cada paso y quién lo hizo.
El log es la lista de commits — el historial de tu proyecto en orden, cada uno con su mensaje, autor y hora. Responde «¿qué pasó, y cuándo?» y es el punto de partida para entender cualquier base de código o cazar cualquier bug. Cuando algo se rompe, el log te deja encontrar el commit exacto que lo introdujo, porque cada cambio queda registrado. Un historial que puedes leer es un historial que puedes depurar.
Deshacer con seguridad: revert frente a reset
Dos formas de deshacer un error: añadir al registro una corrección claramente anotada (revert), o arrancar en silencio la última página como si nunca hubiera existido (reset).
Git te da formas seguras de volver atrás. Revert crea un nuevo commit que deshace uno anterior — el error queda en el historial, con su reversión registrada encima, lo cual es honesto y seguro para el trabajo compartido. Reset te mueve de vuelta a un commit anterior, reescribiendo el historial reciente como si esos commits no estuvieran ahí — poderoso, pero peligroso sobre trabajo que otros ya tienen. La regla práctica: revert en público, reset solo en trabajo privado y local.
Rebase reproduce tu trabajo; respeta la regla de oro
En lugar de grapar tu borrador lateral sobre el manuscrito con una costura visible (merge), recopias tus ediciones limpiamente encima de la última versión, como si hubieras partido de ella (rebase).
Rebase es una alternativa a merge: en lugar de unir dos líneas con un merge commit, reproduce tus commits encima de otro branch, creando un historial ordenado y en línea recta. Es estupendo para limpiar tu propio branch antes de compartirlo. Pero reescribe commits, así que la regla de oro es: nunca hagas rebase de un historial que otros ya hicieron pull. Reescribe el historial compartido y desincronizarás a todos. Haz rebase de tu trabajo privado; haz merge para combinar el trabajo compartido.
El log es la historia legible; revert y reset son tus formas de volver atrás. Rebase crea un historial ordenado — pero nunca reescribas un historial que otros ya hicieron pull.
Los comandos de Git son muchos, pero la buena práctica es una lista corta de hábitos. Síguelos y Git seguirá siendo una red de seguridad tranquila en lugar de una emergencia ocasional.
Commits pequeños y enfocados con mensajes claros
Un álbum de fotos donde cada imagen captura un momento claro con un pie de foto — mucho más útil que una sola toma borrosa de todo a la vez.
Haz commit pequeño y a menudo, con cada commit un único cambio coherente y un mensaje que lo explique. Commits diminutos y bien etiquetados hacen que el historial sea legible, los bugs fáciles de rastrear y los deshaceres quirúrgicos — puedes hacer revert de un cambio preciso sin perder el resto. Un commit gigante que vuelca una semana de trabajo mezclado es lo opuesto: imposible de revisar, desenredar o deshacer en parte. La disciplina cuesta segundos y rinde frutos durante toda la vida del proyecto.
Un branch por función, con merge frecuente
Cada nuevo capítulo redactado en su propia copia y plegado de vuelta mientras todavía es pequeño — para que ningún borrador se aleje tanto del libro que reunirlo se vuelva una batalla.
Haz cada pieza de trabajo en su propio branch, mantenlo de corta vida y hazle merge de vuelta con frecuencia. Los branches de larga vida se alejan mucho de main y convierten el merge en una pila dolorosa de conflicts; los branches pequeños con merge frecuente se mantienen fáciles. Combínalo con pull antes de push — incorpora primero los cambios de otros — para integrar continuamente en lugar de chocar al final. Este ritmo es el corazón de un Git de equipo fluido.
- Haz pull de lo último antes de empezar, para construir sobre el trabajo actual. - Trabaja en un branch, nunca directamente sobre un main frágil. - Haz commits pequeños con mensajes claros sobre la marcha. - Haz merge a menudo mientras los branches todavía son cortos, para mantener los conflicts diminutos. - Haz push de tu trabajo y abre un pull request para revisión. - Deshaz con revert en trabajo compartido; nunca hagas rebase de un historial que otros tienen.
- repository / commit / message — el proyecto seguido, un snapshot y su nota. - staging area / HEAD — la caja que empacas antes de hacer commit, y tu marcador de estás-aquí. - branch / main — una línea de trabajo paralela, y la versión de confianza. - merge / conflict — reunir branches, y el choque en la misma línea que resuelves. - local / remote / origin — tu copia, la copia compartida y su nombre por defecto. - clone / push / pull / fetch — los cuatro movimientos que mantienen las copias sincronizadas. - pull request / revert / reset / rebase — revisión, deshacer seguro y reescribir el historial.
- Tu historial se lee como una historia clara de pasos pequeños y con pie de foto. - El trabajo nuevo vive en branches; main siempre funciona. - Haces pull antes de push y merge mientras los branches todavía son pequeños. - Recurres a revert en trabajo compartido y nunca reescribes el historial compartido. - Git se siente como una red de seguridad — experimentas libremente, sabiendo que siempre puedes volver atrás.
Un buen Git son unos pocos hábitos: pull primero, branch tu trabajo, commit pequeño con mensajes claros, merge a menudo, y revisa antes de hacer merge. Los comandos son muchos; la disciplina es corta.