Git y GitHub desde cero: guía completa para principiantes

Respuesta rápida

Git es un sistema de control de versiones que guarda instantáneas de tu código para que puedas volver atrás cuando quieras. GitHub es la plataforma en la nube donde subes esos proyectos, colaboras con otros y muestras tu trabajo. Juntos son el estándar del 93% de los programadores del mundo.

1. Introducción

Por qué Git y GitHub son esenciales en el desarrollo de software

Voy a ser sincero contigo.

Cuando empecé a programar, no tenía ni idea de qué era eso de "control de versiones". Yo hacía lo que creo que hace casi todo el mundo al principio: guardaba mi proyecto con nombres como mi_app_final_v2_ultimo.py o proyecto_definitivo_corregido.zip. Y funcionaba… hasta que dejaba de funcionar.

Recuerdo una vez, concretamente, que pasé tres días trabajando en una funcionalidad. La probé, la mejoré, la rompí, la arreglé. Todo iba genial. Pero una noche, sin querer, borré una parte del código que era importante. Y no me di cuenta hasta el día siguiente. Intenté recuperarlo, pero ya era tarde. Mi editor de código no guarda el historial de todo lo que escribes. Y yo no tenía copia de seguridad.

¿Mi solución en ese momento? Empezar de nuevo desde cero. Volver a escribir líneas que ya había escrito. Horas y horas tiradas a la basura.

Ahí fue cuando un amigo, con más experiencia, me preguntó: "¿No usas Git?". Yo me quedé en blanco. Me explicó por encima qué era y esa misma semana me puse a aprenderlo. No te voy a mentir: al principio me pareció complicado. Comandos raros, una terminal que me daba miedo, conceptos como "ramas" o "commits" que sonaban muy técnicos. Pero una vez que le cogí el truco, todo cambió.

Git es, básicamente, un sistema que guarda instantáneas de tu proyecto cada vez que tú se lo pides. Es como tener un botón de "guardar partida" en un videojuego. Si haces algo mal, si rompes todo, si te arrepientes de un cambio, puedes volver atrás. Puedes cargar esa partida guardada y seguir desde ahí como si nada hubiera pasado. Y lo mejor de todo: guarda quién hizo cada cambio, cuándo y por qué.

GitHub, por otro lado, es el sitio donde puedes subir todo ese trabajo a la nube. No es lo mismo que Git. Si Git es el motor, GitHub es el garaje donde aparcas el coche. En GitHub tu código está seguro, accesible desde cualquier ordenador, y lo puedes compartir con quien quieras. Además, funciona como una red social para programadores: puedes seguir a otros, ver sus proyectos, colaborar en ellos y mostrar los tuyos.

Y no son cosas raras o de nicho. Es lo que se usa en el mundo real.

Los datos son muy claros. En la encuesta más grande del sector, más del 93% de los programadores usan Git. Y casi el 90% usan GitHub. Eso significa que, si quieres dedicarte a la programación, da igual qué lenguaje aprendas: JavaScript, Python, Java, C++ o lo que sea. Git y GitHub van a estar ahí. Son como saber usar un teclado o un editor de código. No es una opción, es parte del trabajo.

Además, tener tu código en GitHub tiene ventajas que igual no habías pensado:

• Copia de seguridad automática. Si tu ordenador se rompe o te lo roban, no pierdes nada.
• Trabajar desde cualquier sitio. Puedes seguir tu proyecto en casa, en clase, en la biblioteca o en el ordenador de un amigo.
• Colaborar sin líos. Otra persona puede modificar el mismo archivo que tú sin pisar tu trabajo. Git se encarga de mezclar los cambios.
• Un portafolio real. Cuando busques prácticas o tu primer trabajo, tener GitHub con proyectos subidos es como tener un currículum vivo.

Por eso quiero escribir este artículo. Porque me hubiera encantado tener algo así cuando empecé. Algo que me explicara todo paso a paso, sin dar nada por sentado, con un lenguaje normal y sin rollos técnicos innecesarios.

Qué vas a encontrar aquí (y cómo te va a ayudar)

Al final de este artículo, sabrás:

• Cómo instalar Git y configurarlo en tu ordenador.
• Cómo guardar versiones de tu proyecto (los famosos commits).
• Cómo funcionan las ramas, que es una de las cosas más útiles y que más miedo da al principio.
• Cómo subir tu código a GitHub y tenerlo siempre seguro.
• Cómo colaborar en proyectos de otros (y que otros colaboren en los tuyos) sin pelearte con nadie.
• Y algunos trucos avanzados que te harán la vida más fácil.

Para quién está escrito esto (spoiler: probablemente para ti)

Este artículo lo escribo pensando en alguien como yo cuando empecé. O como tú si estás leyendo esto.

Va dirigido sobre todo a principiantes. A personas que llevan poco tiempo programando, que están aprendiendo su primer lenguaje (Python, JavaScript, Java, el que sea) y que empiezan a darse cuenta de que guardar archivos sueltos no es suficiente. Quizás ya te ha pasado eso de "me funcionaba ayer y hoy no sé qué hice". Si es así, estás en el sitio correcto.

También es para autodidactas. Para los que aprendéis por vuestra cuenta, viendo vídeos, leyendo foros, probando cosas. Ese tipo de aprendizaje es maravilloso, pero a veces te saltas pasos importantes. Yo mismo lo hice. Aprendí a programar viendo tutoriales y nunca nadie me habló de Git hasta que me estrellé. No quiero que te pase lo mismo.

Y por supuesto, va para estudiantes de programación. Da igual si estás en la universidad, en un ciclo formativo, en un bootcamp o simplemente en tu habitación. En todos sitios se usa Git y GitHub. Pero no siempre te lo explican bien. A veces piensan que ya lo sabes, o te lo cuentan demasiado rápido, o se saltan cosas que para ellos son obvias pero para ti no. Aquí no voy a darlo nada por sentado.

No necesitas saber nada de Git ni de GitHub para empezar. Eso lo aprendemos aquí. Solo necesitas tener un ordenador, ganas de entender cómo funciona esto, y un poco de paciencia. Los primeros comandos pueden parecer raros, pero en dos tardes ya los usas sin pensar.

Una última cosa antes de continuar. No te preocupes si no entiendes algo a la primera. Yo tuve que leer varias veces algunos conceptos. Las ramas, por ejemplo, me costaron. Los conflictos también. Es normal. La programación es así: entiendes una cosa, luego otra, y un día todo encaja.

Vale, ¿empezamos?

2. Primera parte: Git (conceptos fundamentales)

Vamos a empezar por el principio. Por lo más básico. Por lo que necesitas entender antes de escribir ni un solo comando.

Porque una cosa es aprender a usar algo, y otra muy diferente es entender por qué lo usas. Cuando entiendes el porqué, todo lo demás tiene mucho más sentido.

Así que aquí vamos.

3.1. ¿Qué es Git?

Voy a intentar explicarlo de la forma más sencilla que se me ocurre.

Imagina que estás escribiendo un trabajo para clase. Un trabajo largo, de esos de 50 páginas. Cada día añades cosas, corriges errores, cambias párrafos de sitio. Un buen día, tu profesor te dice que la versión que le diste la semana pasada era mejor, que vuelvas atrás. Pero tú ya has cambiado tantas cosas que no recuerdas cómo era aquella versión antigua.

¿Qué harías en esa situación?

Sin un sistema de control de versiones, lo más probable es que empezaras a llorar. O a intentar recuperar manualmente lo que habías borrado. O a maldecir al profesor. Pero con un sistema de control de versiones, simplemente le dirías: "Ahora mismo voy a por ella".

Git es exactamente eso: un sistema de control de versiones.

Un sistema de control de versiones es una herramienta que guarda el estado de tu proyecto en diferentes momentos del tiempo. Cada vez que tú se lo pides, Git toma una "foto" de todos tus archivos y la guarda en su memoria. Esa foto incluye exactamente cómo estaban las cosas en ese instante: qué líneas de código había, qué archivos existían, todo.

Luego, si cometes un error o si quieres volver a un estado anterior, puedes hacerlo. Git te deja viajar en el tiempo. Puedes ver cómo era tu proyecto hace tres días, hace una semana o hace un mes. Y si te gusta más esa versión, puedes quedarte con ella.

Ahora, hay una palabra que aparece mucho cuando hablamos de Git y que al principio me liaba bastante: "distribuido". Dicen que Git es un sistema de control de versiones distribuido. ¿Qué significa eso?

Te lo explico.

Hay otros sistemas de control de versiones que no son distribuidos. En esos sistemas, hay un único servidor central donde está el código. Si ese servidor se cae o se pierde la información, todo el mundo se queda sin trabajo. Es como tener una única copia de tu trabajo en la nube y no tenerla en tu ordenador. Si la nube falla, pierdes todo.

Git es diferente. En Git, cada persona que trabaja en un proyecto tiene una copia completa del historial en su propio ordenador. No depende de un servidor central. Si el servidor remoto (por ejemplo, GitHub) se cae o desaparece, tú sigues teniendo tu copia local con todo el historial. Puedes seguir trabajando, puedes seguir guardando versiones, puedes seguir haciendo lo que necesites. Cuando el servidor vuelva a funcionar, lo actualizas y listo.

Eso es lo que significa "distribuido". Que no hay un único punto de fallo. El poder está repartido entre todos.

Diferencia entre Git y GitHub

Esto es algo que he tenido que explicar muchísimas veces. Y no es para menos, porque los nombres se parecen y mucha gente piensa que son lo mismo.

Pero no lo son. Y entender la diferencia es importante.

Git es el sistema de control de versiones. Es la herramienta que instalo en mi ordenador y que me permite guardar instantáneas de mi proyecto, crear ramas, fusionar cambios, volver atrás en el tiempo, etc. Git funciona sin internet. No necesito estar conectado a nada para usarlo. Todo lo que hace Git ocurre en mi máquina.

GitHub es una plataforma en internet que usa Git por debajo. GitHub no es Git, sino un sitio donde puedo subir mis repositorios de Git para tenerlos en la nube. GitHub me da una interfaz web bonita para ver mi código, me permite colaborar con otras personas, gestionar errores, revisar cambios, y muchas cosas más. Pero GitHub necesita internet.

Piensa en esta analogía: Git es como un motor de coche. El motor hace que el coche se mueva, funciona de maravilla. GitHub es como la carretera. La carretera no es el motor, pero te da un lugar donde circular. Puedes tener un motor sin carretera (Git sin GitHub) y puedes tener una carretera sin motor (GitHub sin Git no tendría sentido). Pero juntos son mucho más potentes.

En este artículo, primero vamos a aprender Git en nuestro ordenador. Sin nubes, sin internet, sin cosas raras. Luego, cuando ya domines lo básico, subiremos todo a GitHub. Ese orden tiene mucho sentido, porque si entiendes cómo funciona Git localmente, usar GitHub será muchísimo más fácil.

Historia: creado por Linus Torvalds

Puede que este nombre te suene. O puede que no. Pero créeme, es importante.

Linus Torvalds es el creador de Linux. Linux es el sistema operativo que usan millones de servidores en todo el mundo, y también el corazón de Android. Básicamente, Linus es una de las personas más importantes en la historia de la informática.

A principios de los años 2000, Linus y su equipo necesitaban un sistema de control de versiones para gestionar el desarrollo de Linux. En aquel momento usaban uno llamado BitKeeper. Pero en 2005, la empresa que creó BitKeeper decidió quitarles el acceso gratuito. Linus se quedó sin herramienta.

¿Y qué hizo? Pues lo que mejor sabe hacer: crear una él mismo.

En abril de 2005, Linus Torvalds empezó a escribir Git. Y en muy poco tiempo, ya tenía un sistema funcional. Lo diseñó pensando en tres cosas:

1. Velocidad: trabajar con Git tenía que ser rápido, incluso con proyectos enormes como Linux.
2. Sencillez: el diseño interno tenía que ser simple y robusto.
3. Distribuido: como ya te expliqué, que no dependiera de un servidor central.

Y la verdad es que lo consiguió. Git se convirtió rápidamente en el estándar. Hoy en día, prácticamente todos los proyectos de software usan Git. Y sigue evolucionando. De hecho, es muy probable que mientras lees esto, haya salido una nueva versión de Git con mejoras o correcciones.

Así que cuando usas Git, no estás usando cualquier herramienta. Estás usando algo creado por una de las mentes más brillantes del software. Y lo mejor de todo: es gratuito y de código abierto. Cualquier persona puede ver cómo funciona por dentro, e incluso contribuir a mejorarlo.

3.2. Instalación y configuración

Vale, ya tenemos la teoría. Sabemos qué es Git, por qué es importante, y quién lo creó. Ahora toca ensuciarnos las manos.

Vamos a instalar Git en tu ordenador.

No te preocupes. Es más fácil de lo que parece. Y una vez que lo tengas instalado, no tendrás que volver a hacerlo. Es solo una vez.

Instalación en Windows

Si usas Windows, el proceso es muy sencillo.

1. Abre tu navegador y busca "Git para Windows" o ve directamente a la página oficial (no voy a poner enlaces, pero lo encuentras fácil).
2. Haz clic en el botón de descarga. Se bajará un archivo .exe.
3. Ejecutas el archivo y sigues los pasos del instalador. La mayoría de las opciones por defecto están bien. No necesitas cambiar nada raro.
4. Cuando termines, tendrás una nueva aplicación instalada: Git Bash. Esto es una terminal especial que entiende los comandos de Git.

Un consejo: durante la instalación, te preguntará qué editor quieres usar para escribir los mensajes de los commits. Puedes dejar el que viene por defecto (Vim) o cambiarlo a algo más amigable como Notepad++. Si no sabes lo que es Vim, quizás quieras cambiarlo. Pero no te preocupes demasiado, porque nosotros usaremos siempre la opción -m para escribir mensajes directamente en el comando, sin abrir editores.

Instalación en macOS

Si tienes un Mac, lo tienes aún más fácil. Abre la terminal (la buscas con Spotlight o en Aplicaciones > Utilidades) y escribes:

brew install git

Esto funciona si tienes Homebrew instalado. Si no lo tienes, no te preocupes. Otra opción es que macOS ya traiga Git preinstalado. Para comprobarlo, escribe en la terminal:

git --version

Si ves un número de versión, ya lo tienes. Si no, el sistema te sugerirá instalarlo automáticamente.

Instalación en Linux

Si usas Linux (como Ubuntu, Debian, Fedora, etc.), Git suele venir ya instalado. Pero por si acaso, abre la terminal y escribe:

sudo apt-get install git

Eso es para Ubuntu y Debian. Si usas Fedora, sería:

sudo dnf install git

Y si usas otra distribución, seguro que el comando es parecido. Lo buscas en Google y lo encuentras en dos segundos.

Verificar que todo funciona

Una vez instalado, hagamos una comprobación rápida.

Abre tu terminal (Git Bash en Windows, la terminal normal en Mac o Linux) y escribe:

git

Si ves una lista larga de comandos y opciones, enhorabuena. Git está instalado y funcionando.

Si quieres saber qué versión tienes, escribe:

git --version

o también:

git -v

Y si alguna vez no recuerdas cómo se usa un comando, puedes pedir ayuda escribiendo:

git -h

Eso te mostrará una pequeña guía de ese comando. Es muy útil cuando empiezas y no te acuerdas de todo.

Comandos básicos de terminal

Antes de seguir, hay algo que necesitamos cubrir. Y sé que puede dar un poco de pereza, pero es importante.

Vamos a hablar de la terminal.

La terminal es esa pantalla negra (o blanca, según cómo la tengas configurada) donde escribes comandos en lugar de hacer clic con el ratón. Al principio da un poco de miedo, porque no hay botones ni ventanas. Solo texto. Pero te prometo que en dos días te acostumbras.

Voy a enseñarte los comandos que más vas a usar. Son muy pocos. Con estos puedes moverte por tu ordenador y crear carpetas y archivos sin problemas.

• ls (en Mac y Linux) o dir (en Windows): Muestra la lista de archivos y carpetas del lugar donde estás.
• cd nombre_carpeta: Entras dentro de una carpeta. Por ejemplo, cd Desktop te lleva al escritorio.
• cd ..: Subes un nivel. Sales de la carpeta en la que estás.
• pwd: Te dice en qué ruta te encuentras. Muy útil si te has perdido.
• mkdir nombre_carpeta: Crea una carpeta nueva. Por ejemplo, mkdir mi_proyecto.
• touch nombre_archivo (en Mac/Linux) o type nul > nombre_archivo (en Windows): Crea un archivo vacío.
• rm nombre_archivo: Borra un archivo. Cuidado con este, no va a la papelera.
• rm -r nombre_carpeta: Borra una carpeta y todo lo que hay dentro.
• clear (en Mac/Linux) o cls (en Windows): Limpia la pantalla de la terminal.

No necesitas memorizarlos ahora. Los irás usando y te acordarás sin darte cuenta. Pero te recomiendo que practiques un poco. Crea carpetas, muévete, borra cosas (que no sean importantes). La terminal es una herramienta muy potente, y cuanto antes le pierdas el miedo, mejor.

Configuración de usuario con git config

Ahora viene un paso obligatorio. Sin esto, Git no te va a dejar hacer nada.

Git necesita saber quién eres. Cada vez que guardas una versión de tu proyecto, Git guarda también el nombre y el email de la persona que hizo ese guardado. Así, si trabajas con más gente, se puede saber quién hizo cada cambio.

Vamos a configurar tu identidad.

git config --global user.name "Tu Nombre"

git config --global user.email "[email protected]"

Eso es todo. El --global significa que esta configuración se aplica a todos los proyectos que hagas en este ordenador. Si algún día necesitas usar un nombre diferente en un proyecto concreto (por ejemplo, para trabajar en algo de clase con un compañero), puedes quitarlo y configurarlo solo para ese proyecto. Pero de momento, con el global es suficiente.

¿Cómo compruebo que lo he hecho bien? Puedes ver toda tu configuración escribiendo:

git config --list

Deberías ver tu nombre y tu email entre un montón de cosas más. No te preocupes por el resto.

Y un consejo: el email que pongas aparecerá en los commits. Si te preocupa la privacidad, GitHub (que ya veremos más adelante) te permite usar un email especial que no revela tu cuenta real. Pero por ahora, usa el que tengas.

3.3. Primeros pasos con Git

Ya tenemos todo listo. Git instalado, configuración hecha, y conocemos los comandos básicos de la terminal. Es hora de crear nuestro primer repositorio.

¿Qué es un repositorio? Pues básicamente es una carpeta especial que Git vigila. Dentro de esa carpeta, Git guardará todo el historial de cambios que hagamos.

Inicialización de repositorios (git init)

Vamos a crear una carpeta para nuestro proyecto. Desde la terminal:

mkdir mi_primer_proyecto
cd mi_primer_proyecto

Ahora, dentro de esa carpeta, escribimos el comando mágico:

git init

La terminal te responderá algo como: Initialized empty Git repository in ...

¿Qué ha pasado? Git ha creado una carpeta oculta llamada .git dentro de tu proyecto. No la veas a simple vista (los archivos que empiezan con punto son ocultos), pero está ahí. Dentro de esa carpeta, Git guardará todo su historial. No toques nada dentro de .git a menos que sepas muy bien lo que haces.

Si quieres verificar que el repositorio se ha creado, puedes escribir:

ls -a

Y verás la carpeta .git en la lista.

Ya tenemos nuestro primer repositorio. Pero está vacío. No tiene ningún archivo, y por lo tanto, ningún guardado.

Ciclo básico: git add, git commit, git status, git log

Vamos a crear un archivo. En nuestro proyecto, dentro de la carpeta mi_primer_proyecto, creamos un archivo de código. Por ejemplo, uno en Python:

touch hola.py

Si usas Windows y no funciona touch, puedes crear el archivo desde el editor de código o con type nul > hola.py.

Abrimos ese archivo en nuestro editor favorito (VS Code, Sublime, el que uses) y escribimos algo, por ejemplo:

print("Hola mundo")

Guardamos el archivo y volvemos a la terminal.

Ahora es cuando empieza lo bueno.

Escribe:

git status

Este comando es tu mejor amigo. Te dice qué está pasando en tu repositorio. En este momento, te dirá algo como: "Archivos sin seguimiento: hola.py". Eso significa que Git ha detectado el archivo, pero aún no lo está vigilando.

Para que Git empiece a vigilar un archivo, tenemos que añadirlo al área de preparación (también llamada "stage"). Se hace con:

git add hola.py

Si quieres añadir todos los archivos de una vez (los que están en la carpeta y los que crees después), puedes usar:

git add .

Ahora, si vuelves a escribir git status, verás que hola.py ha cambiado de color y aparece como "cambios listos para commit".

¿Y qué es un commit? Pues es la foto de la que hablaba antes. Hacer un commit significa: "Git, toma una foto de cómo están los archivos ahora mismo y guárdala para siempre".

Se hace así:

git commit -m "Mi primer commit"

El -m significa "message" (mensaje). Entre comillas escribes un texto corto que describa qué has cambiado. Es muy importante que los mensajes sean claros. Más adelante, cuando mires el historial, los mensajes te dirán qué pasó en cada momento.

Si todo va bien, Git te responderá con algo como: "1 file changed, 1 insertion(+)". Eso significa que ha guardado el archivo correctamente.

¿Quieres ver el historial de commits que has hecho? Usa:

git log

Te mostrará una lista con todos tus commits. Cada commit tiene:

• Un hash (un código largo y raro, como a3f2b9c...). Es la identificación única de ese commit.
• El autor (el nombre y email que configuraste).
• La fecha y la hora.
• El mensaje que escribiste.

Si tu terminal se llena de información y quieres salir, presiona la tecla q.

Más adelante te enseñaré formas más bonitas de ver el log. Pero de momento, con esto es suficiente.

Uso de .gitignore

¿Te acuerdas del archivo .DS_Store que aparecía en el ejemplo del libro? Es un archivo que macOS crea automáticamente en cada carpeta para guardar cosas como la posición de los iconos. No es parte de tu proyecto, pero Git lo detecta y te sugiere que lo añadas.

Eso es molesto. Y puede pasar con muchos archivos: archivos temporales, cachés, archivos de configuración local, claves secretas que no quieres subir a internet...

La solución es un archivo muy especial llamado .gitignore.

Creas un archivo llamado exactamente .gitignore (con el punto al principio) en la raíz de tu proyecto:

touch .gitignore

Lo abres con tu editor y escribes las reglas de qué quieres ignorar. Por ejemplo, para ignorar los .DS_Store, escribes:

**/.DS_Store

Eso significa: en cualquier carpeta (**/), ignora cualquier archivo llamado .DS_Store.

Puedes ignorar también archivos por su extensión:

*.log
*.tmp

O carpetas enteras:

carpeta_temporal/

O archivos específicos:

secreto.txt

Lo importante es que el archivo .gitignore sí debe ser añadido al repositorio. Porque todos los que trabajen en el proyecto deben ignorar las mismas cosas.

Así que:

git add .gitignore
git commit -m "Añado .gitignore para ignorar archivos temporales"

A partir de ahora, Git no te va a molestar con esos archivos. Y cuando hagas git status, tu repositorio estará "limpio", con solo los archivos que realmente importan.

3.4. Ramas (branches)

Hasta ahora todo ha sido muy lineal. Un commit, luego otro, luego otro. Como una línea recta. Pero lo que hace realmente potente a Git es la capacidad de crear ramas.

Concepto de rama: main, develop, feature/login

Una rama es como una línea de tiempo alternativa. Imagina que tienes tu proyecto principal, que funciona y está bonito. Pero quieres probar algo nuevo. Algo grande. Algo que quizás no funcione.

Si hicieras esos cambios directamente en tu proyecto principal, podrías romperlo. Y luego no podrías volver atrás fácilmente.

Las ramas solucionan esto.

Crear una rama es como decir: "Git, quiero hacer una copia de mi proyecto en este punto, pero en una línea de tiempo separada. Voy a experimentar allí, sin tocar el original".

La rama principal, por defecto, se llamaba master antes. Pero en los últimos años se ha cambiado a main. En GitHub también se usa main. Nosotros vamos a usar main.

Si quieres cambiar el nombre de tu rama principal en proyectos nuevos (recomendado), puedes ejecutar:

git config --global init.defaultBranch main

Si ya tienes un repositorio con master y quieres renombrarlo a main, usas:

git branch -m master main

Ahora, creamos una nueva rama para probar una funcionalidad. Por ejemplo, algo relacionado con inicio de sesión:

git branch login

Esto crea la rama, pero no nos mueve a ella. Para moverse se usa git switch (o git checkout, que es más antiguo, pero switch es más claro):

git switch login

Si quieres crear la rama y moverte a ella de una vez:

git switch -c login

Ahora estamos en la rama login. Cualquier commit que hagamos aquí no afecta a main. Podemos crear archivos, modificarlos, borrarlos... todo en nuestra burbuja.

Comandos: git branch, git switch, git merge

Veamos los comandos básicos para manejar ramas:

• git branch: muestra todas las ramas y marca con un asterisco en la que estás.
• git branch nombre_rama: crea una nueva rama.
• git switch nombre_rama: te mueve a esa rama.
• git switch -c nombre_rama: crea y se mueve a la nueva rama.
• git branch -d nombre_rama: borra una rama (si ya se ha fusionado).
• git branch -D nombre_rama: borra una rama aunque no se haya fusionado (peligro, se pierden commits).

Una vez que hemos terminado de trabajar en una rama, queremos fusionar los cambios con la rama principal. Eso se hace con:

git switch main
git merge login

El primer comando nos mueve a la rama principal. El segundo dice: "main, tráete todos los cambios que hay en login".

Si no ha habido conflictos, Git hará el merge automáticamente y creará un commit de fusión.

Conflictos: cómo surgen y cómo resolverlos

Los conflictos ocurren cuando dos ramas han modificado la misma línea del mismo archivo. Git no sabe cuál de las dos versiones es la correcta, y te pide que decidas tú.

Imagina que en main alguien escribió:

print("Hola desde main")

Y en login alguien escribió:

print("Hola desde login")

Cuando intentes hacer git merge login, Git te dirá: "CONFLICTO. No puedo decidir".

Abrirás el archivo y verás algo como esto:

<<<<<<< HEAD
print("Hola desde main")
=======
print("Hola desde login")
>>>>>>> login

Eso es Git diciéndote: "esto es lo que hay en tu rama actual (HEAD), esto es lo que hay en la rama que quieres fusionar. Decide tú".

Para resolverlo, simplemente editas el archivo, borras las marcas (<<<<<<<, =======, >>>>>>>), y dejas el código que quieras. Puedes quedarte con una versión, con la otra, o incluso mezclarlas:

print("Hola desde main y login")

Guardas el archivo, lo añades al stage:

git add archivo_en_conflicto.py

Y luego haces el commit (sin -m, porque Git te pedirá que confirmes el mensaje del merge):

git commit

Git abrirá un editor (puede ser Vim, no te asustes). Para salir y guardar, normalmente es :wq o si es el editor por defecto, cierras la pestaña. Pero si te lías, puedes usar git commit -m "Soluciono conflicto en archivo.py".

Y listo. Conflicto resuelto.

Los conflictos dan miedo al principio, pero te prometo que con la práctica se vuelven rutinarios. Y la mayoría de las veces, si trabajas con orden y comunicándote con tu equipo, apenas aparecen.

3.5. Herramientas adicionales de Git

Hay algunos comandos que no usas todos los días, pero cuando los necesitas, te salvan la vida.

Etiquetas (git tag)

Las etiquetas (tags) son como post-its que pegas en un commit para recordarlo fácilmente. Por ejemplo, cuando lanzas una versión 1.0 de tu aplicación, le pones una etiqueta.

git tag v1.0

Si quieres etiquetar un commit antiguo (buscas su hash con git log):

git tag v0.5 a3f2b9c

Para ver todas las etiquetas:

git tag

Para ver los detalles de una etiqueta:

git show v1.0

Para moverse a la etiqueta (como si fuera un commit):

git checkout v1.0

Para borrar una etiqueta:

git tag -d v1.0

Las etiquetas son muy útiles para versiones. No uses etiquetas para cualquier cosa, reservarlas para momentos importantes.

Cambios temporales (git stash)

Imagina que estás trabajando en una rama, tienes cambios sin terminar, y de repente te llaman para arreglar un error urgente en otra rama. No quieres perder tu trabajo, pero tampoco quieres hacer un commit de algo a medias.

Solución: git stash.

git stash

Git guarda todos tus cambios sin terminar en una pila (un almacén temporal). Tu repositorio se limpia como si no hubieras hecho nada. Ahora puedes cambiar de rama tranquilo.

Cuando vuelvas a tu rama y quieras recuperar los cambios:

git stash pop

Eso aplica los cambios y los borra del almacén. Si quieres aplicarlos pero mantenerlos en el almacén:

git stash apply

Para ver todos los guardados temporales:

git stash list

Y para borrar un stash específico:

git stash drop stash@{0}

O borrarlos todos:

git stash clear

Desplazamiento entre commits (git checkout, git reset, git reflog)

A veces necesitas volver atrás en el tiempo. Git te lo permite.

Para ver un commit anterior sin perder el trabajo actual (modo lectura):

git checkout hash_del_commit

Te mueves a ese punto. Los archivos vuelven a ser como eran entonces. Para volver al final:

git checkout main

Para borrar commits posteriores y moverte a un punto concreto (peligroso, pero útil):

git reset --hard hash_del_commit

Esto borra todo lo que haya después de ese commit. No se puede recuperar fácilmente (bueno, sí, con git reflog).

El comando salvador: git reflog

¿Qué pasa si haces un reset --hard y te arrepientes? git reflog.

git reflog muestra todos los movimientos que has hecho en Git. Cada vez que haces un commit, un reset, un checkout, queda registrado. Es como un diario de todo lo que has hecho.

Buscas el hash del punto al que quieres volver (aunque ya no aparezca en git log) y haces:

git reset --hard ese_hash

Y recuperas lo que creías perdido.

Usa git reset --hard con cuidado. Pero si lo usas, recuerda que git reflog puede sacarte de casi cualquier problema.

Comparación de versiones (git diff)

¿Quieres ver exactamente qué has cambiado en un archivo antes de hacer commit?

git diff

Te muestra línea por línea lo que has añadido (en verde, con un +) y lo que has borrado (en rojo, con un -).

Para comparar dos commits:

git diff hash_a hash_b

Para ver solo los nombres de los archivos que han cambiado:

git diff --name-only hash_a hash_b

git diff es como un "muéstrame lo que he hecho". Lo usarás mucho.

3.6. Comandos avanzados

Estos comandos no los usarás cada día. Pero cuando los necesites, te alegrarás de saber que existen.

git cherry-pick

Imagina que tienes una rama con varios commits, pero solo quieres traerte UNO de ellos a tu rama actual. No todos. Uno.

git cherry-pick hash_del_commit

Git aplica ese cambio específico como un nuevo commit en tu rama. Es como decir: "de esa rama, me quedo solo con esa idea".

Si algo sale mal:

git cherry-pick --abort

git rebase

git rebase es más complejo y delicado. Básicamente, reescribe la historia. Puedes usarlo para:

• Mover el punto de inicio de tu rama a otro lugar.
• Ordenar, fusionar o eliminar commits antiguos.
• Mantener un historial más limpio y lineal.

El comando básico:

git rebase main

Estando en tu rama, esto dice: "toma mi rama y muévela para que empiece desde el final de main".

Si hay conflictos, los resuelves y luego:

git rebase --continue

Si quieres abortar:

git rebase --abort

La versión interactiva (-i) te deja reordenar commits:

git rebase -i HEAD~3

Eso te permite trabajar con los últimos 3 commits.

Advertencia: no hagas rebase en commits que ya hayas subido a un repositorio compartido. Puedes liarla mucho. Usa rebase solo en ramas locales o cuando estés solo en la rama.

Otros comandos útiles

git blame: Para saber quién escribió cada línea de un archivo.

git blame archivo.py

Muestra línea por línea: autor, fecha, hash del commit, y el código. Muy útil para encontrar quién metió ese bug.

git revert: Al revés que reset. revert no borra el commit, sino que crea un nuevo commit que hace lo contrario.

git revert hash_del_commit

Es más seguro en repositorios compartidos, porque no reescribe la historia.

git bisect: Para encontrar qué commit introdujo un bug. Haces una búsqueda binaria: marcas un commit "bueno" y otro "malo", y Git va probando commits intermedios hasta encontrar el culpable.

git bisect start
git bisect bad   # el actual está mal
git bisect good hash_bueno

Luego vas probando y dices git bisect good o git bisect bad. Al final, te dice qué commit lo rompió.

Resumen de la primera parte

Hasta aquí hemos cubierto:

• Qué es Git y por qué cambia la forma de programar.
• La diferencia entre Git y GitHub.
• Cómo instalar Git en cualquier sistema operativo.
• Los comandos básicos de terminal que necesitas.
• Cómo configurar tu identidad.
• Tu primer repositorio, tus primeros commits, y cómo ver el historial.
• Cómo ignorar archivos con .gitignore.
• El superpoder de las ramas: crearlas, moverse, fusionarlas y resolver conflictos.
• Herramientas extra: etiquetas, stash, checkout, reset, reflog, diff.
• Comandos avanzados: cherry-pick, rebase, blame, revert, bisect.

Con todo esto, ya eres capaz de usar Git en tu día a día. Puedes trabajar solo, guardar tu progreso, experimentar sin miedo, y volver atrás cuando algo salga mal.

En la siguiente parte, vamos a dar el salto a la nube. Vamos a conectar todo esto con GitHub. Y ahí es donde empieza la verdadera magia de la colaboración.

Pero antes de seguir, tómate un descanso. Tómate un café, estírate las piernas, y luego volvemos.

Cuando estés listo, pasamos a la segunda parte.

4. Segunda parte: GitHub

Hasta ahora hemos estado jugando en nuestro propio jardín. Todo lo que hicimos con Git estaba en nuestro ordenador. Los commits, las ramas, los merges, los conflictos... todo local. Nadie más podía verlo.

Eso está muy bien para aprender. Pero la vida real no es así.

En el desarrollo de software real, trabajamos con otras personas. O queremos tener una copia de seguridad en la nube. O simplemente queremos enseñar lo que hemos hecho.

Para todo eso necesitamos GitHub.

Vamos a ello.

4.1. Introducción a GitHub

Plataforma en la nube basada en Git

Ya lo adelanté antes, pero lo repito porque es muy importante: GitHub no es Git. Son dos cosas diferentes que se complementan.

Git es la herramienta que instalamos en nuestro ordenador. Es el motor. Es la que guarda los commits, maneja las ramas, etc. GitHub es una página web (una plataforma) donde podemos subir nuestros repositorios de Git para tenerlos en la nube.

Cuando subes tu repositorio a GitHub, no pierdes nada de Git. Sigue siendo un repositorio de Git. Puedes clonarlo, puedes ver su historial, puedes hacer commits, puedes crear ramas... todo igual. La diferencia es que ahora también tienes una copia en internet a la que pueden acceder otras personas (si tú quieres).

Piensa en GitHub como un Dropbox o Google Drive para programadores, pero mucho más potente. No solo guarda archivos, sino que entiende de commits, de ramas, de colaboración.

GitHub se fundó en 2008 y hoy es la plataforma de desarrollo colaborativo más grande del mundo. Millones de programadores la usan. Empresas como Google, Microsoft, Netflix, Twitter, y prácticamente todas las startups tecnológicas tienen sus proyectos en GitHub.

¿Y lo mejor? Es gratis para proyectos públicos y para equipos pequeños con repositorios privados. Puedes tener todos los repositorios públicos que quieras sin pagar nada. Y si quieres que solo lo vean ciertas personas, también puedes tener repositorios privados gratis, con algunas limitaciones. Para empezar, es más que suficiente.

Repositorios públicos y privados

Cuando creas un repositorio en GitHub, tienes que decidir si va a ser público o privado.

Repositorio público: cualquier persona en internet puede ver tu código. Pueden leerlo, copiarlo, estudiarlo, e incluso proponer cambios (veremos cómo más adelante). Si estás aprendiendo, tener repositorios públicos es genial porque puedes enseñar lo que haces. Muchos empleadores miran GitHub para ver proyectos de candidatos.

Repositorio privado: solo tú y las personas que invites pueden ver el código. Es perfecto para proyectos personales que no quieres compartir, o para trabajos de clase, o para cosas que aún no están listas para enseñar.

No hay una opción mejor que otra. Depende de lo que necesites. Yo te recomiendo que empieces con repositorios públicos. Te obliga a escribir código más limpio (porque lo ve todo el mundo) y puedes ir construyendo tu portafolio.

Para crear tu primer repositorio en GitHub, necesitas una cuenta. Te registras (solo necesitas email, nombre de usuario y contraseña) y ya estás dentro.

Una vez dentro, verás un botón verde que dice "New". Ahí puedes crear tu repositorio. Le pones un nombre (por ejemplo, "mi-primer-repositorio"), eliges si es público o privado, y puedes marcar la opción de añadir un archivo README.md (ahora no, pero pronto entenderás por qué es importante).

Y ya tienes tu repositorio en GitHub. Pero está vacío. O solo tiene el README. ¿Cómo subimos nuestro proyecto local? Necesitamos conectar nuestro ordenador con GitHub de forma segura.

Autenticación SSH: generación y configuración

Aquí viene una de las partes que más miedo da al principio. Pero te prometo que no es tan complicado como parece.

¿Qué es SSH?

SSH son siglas de "Secure Shell". Básicamente, es una forma segura de conectar dos ordenadores a través de internet. En nuestro caso, conectaremos nuestro ordenador (el local) con los servidores de GitHub (el remoto).

La gracia de SSH es que usa claves: una clave privada (que nunca sale de tu ordenador) y una clave pública (que le das a GitHub). Cuando intentes conectar, GitHub comprueba que tu clave pública coincide con tu clave privada, y si es así, te deja pasar.

Es como una cerradura (clave pública) y una llave (clave privada). Le das la cerradura a GitHub, y tú te quedas con la llave. Solo tú puedes abrir la puerta.

Vamos a generar nuestras claves SSH.

Paso 1: Abre la terminal

Abre tu terminal (Git Bash en Windows, la terminal normal en Mac o Linux).

Paso 2: Genera la clave

Escribe:

ssh-keygen -t rsa -b 4096 -C "[email protected]"

(Usa el mismo email que usaste para configurar Git)

Te preguntará dónde guardar la clave. Por defecto, en ~/.ssh/id_rsa. Puedes pulsar Enter para aceptar.

Luego te preguntará si quieres poner una contraseña (passphrase). Puedes dejarla vacía si quieres, aunque para más seguridad es mejor poner una. Si pones contraseña, cada vez que uses SSH te la pedirá.

Paso 3: Encuentra tu clave pública

La clave pública es el archivo que termina en .pub. Normalmente en ~/.ssh/id_rsa.pub. Para verla:

cat ~/.ssh/id_rsa.pub

(En Windows, si usas Git Bash, funciona igual)

Te saldrá un texto largo que empieza por "ssh-rsa" y termina con tu email. Eso es tu clave pública. La copias entera.

Paso 4: Añade la clave a GitHub

Entras a GitHub, vas a tu foto de perfil (arriba a la derecha) -> Settings -> SSH and GPG keys -> New SSH Key.

Le pones un título (por ejemplo, "Mi ordenador personal") y pegas la clave pública. Le das a Add SSH Key.

Paso 5: Prueba la conexión

En la terminal, escribe:

ssh -T [email protected]

Si te sale algo como "Hi [tu_usuario]! You've successfully authenticated", ¡enhorabuena! Estás conectado.

Si te pregunta "Are you sure you want to continue connecting?", escribe "yes" y Enter.

Ya está. Tu ordenador y GitHub se reconocen. A partir de ahora, puedes hacer git push y git pull sin tener que poner tu usuario y contraseña cada vez.

4.2. Trabajo con repositorios remotos

Ahora que tenemos la conexión SSH funcionando, vamos a conectar nuestro proyecto local con un repositorio en GitHub.

Comandos: git remote, git push, git pull, git fetch

Primero, necesitamos un repositorio en GitHub. Si no lo has creado aún, crea uno nuevo (vacío, sin README, sin gitignore). Le pones un nombre, por ejemplo "mi-proyecto-local".

Una vez creado, GitHub te mostrará una página con instrucciones. Nos interesa la parte que dice "…or push an existing repository from the command line".

Verás algo como:

git remote add origin [email protected]:tu_usuario/mi-proyecto-local.git
git branch -M main
git push -u origin main

Vamos a explicar cada comando.

git remote add origin [URL]

git remote es el comando para gestionar conexiones con repositorios remotos. add significa que añadimos una nueva conexión. origin es el nombre que le damos a ese remoto (puede ser cualquier nombre, pero origin es el estándar). Y la URL es la dirección SSH de tu repositorio (la copias de GitHub).

Este comando le dice a Git: "Oye, cuando te diga origin, quiero que te conectes a este repositorio de GitHub".

git push

git push es el comando para subir tus commits locales al repositorio remoto.

La primera vez, usamos git push -u origin main. El -u (de upstream) establece la conexión por defecto. Así, después, solo con git push ya sabe a dónde tiene que subir.

Si más adelante creas otras ramas y quieres subirlas:

git push origin nombre_rama

git pull

git pull es lo contrario a push. Sirve para descargar los cambios que hay en el remoto y fusionarlos con tu trabajo local.

Imagina que alguien más ha subido cambios a GitHub. Tú en local no los tienes. Antes de hacer tu propio push, deberías hacer:

git pull

Esto descarga los cambios y hace un merge automático (si no hay conflictos).

git fetch

git fetch es parecido a pull, pero sin fusionar. Solo descarga la información de lo que hay en el remoto, pero no toca tus archivos locales.

Es útil para ver qué ha cambiado antes de decidir si quieres aplicar esos cambios.

git fetch
git log origin/main   # para ver commits que están en remoto pero no en local

Después, puedes hacer git merge origin/main para traerte esos cambios.

Clonar repositorios (git clone)

¿Y si no tienes un proyecto local, pero quieres empezar a trabajar en un proyecto que ya está en GitHub? Para eso existe git clone.

git clone hace dos cosas a la vez:

1. Descarga el repositorio remoto a tu ordenador.
2. Crea la conexión remota automáticamente (con el nombre origin).

Es muy sencillo. Encuentras la URL SSH de cualquier repositorio (botón verde "Code" en GitHub), y en tu terminal escribes:

git clone [email protected]:usuario/repositorio.git

Se creará una carpeta con el nombre del repositorio, y dentro tendrás todos los archivos y todo el historial de Git. Es como si hubieras estado trabajando en él desde el principio.

Esto es lo que hacen los programadores cuando se unen a un proyecto nuevo: clonan el repositorio, se crean su copia local, y empiezan a trabajar.

Sincronización entre local y remoto

Este es el flujo típico de trabajo con Git y GitHub cuando trabajas en equipo (o incluso solo, pero con respaldo en la nube):

1. Trabajas en local: modificas archivos, creas commits, creas ramas, etc.
2. Antes de subir, haces git pull para traerte los cambios que otros hayan podido subir mientras tanto.
3. Si hay conflictos, los resuelves en local (igual que con ramas normales).
4. Haces git push para subir tus commits.

Si trabajas solo, el paso 2 a veces no es necesario (porque no hay otros). Pero es buena práctica hacerlo siempre.

Y si estás empezando un proyecto desde cero, el flujo es:

1. Creas repositorio en GitHub.
2. En local: git remote add origin URL, git push -u origin main.
3. A partir de ahí, el flujo normal.

4.3. Colaboración en GitHub

Hasta ahora, cuando hablábamos de colaboración, era dentro de un equipo con permisos: todos pueden hacer push directamente a main (o a otras ramas). Pero en GitHub, la colaboración también funciona de otra forma muy potente: forks y pull requests.

Esto es especialmente importante para proyectos de código abierto, donde no cualquier persona puede hacer push directamente.

Bifurcaciones (forks)

Un fork es una copia de un repositorio que se crea en tu propia cuenta de GitHub.

Imagina que ves un proyecto en GitHub que te gusta, y quieres añadir una funcionalidad o corregir un error. Pero no eres el dueño. No puedes hacer push directamente porque no tienes permisos.

¿Qué haces? Haces un fork.

El botón "Fork" está en la esquina superior derecha de cualquier repositorio público. Al hacer clic, GitHub crea una copia completa del repositorio en tu cuenta. Es tu repositorio ahora. Puedes hacer lo que quieras con él: clonarlo, crear ramas, hacer commits, push...

El fork es como decir: "me gusta este proyecto, voy a crear mi propia versión para experimentar".

Luego, si haces cambios interesantes, puedes proponer que se incorporen al proyecto original. Ahí es donde entran las Pull Requests.

Pull Requests: flujo completo

Una Pull Request (o PR) es una solicitud para que el dueño de un repositorio original integre los cambios que has hecho en tu fork (o en una rama separada).

El flujo completo es:

Paso 1: Fork el repositorio que te interesa.

Paso 2: Clona tu fork en local:

git clone [email protected]:tu_usuario/repositorio-forkeado.git

Paso 3: Crea una rama para tu cambio (buena práctica, aunque no obligatorio):

git switch -c mi-mejora

Paso 4: Haz tus cambios en los archivos, y luego commit:

git add .
git commit -m "Añado una funcionalidad genial"

Paso 5: Sube tu rama a tu fork:

git push origin mi-mejora

Paso 6: Abre la Pull Request

En GitHub, entras a tu fork. Verás un mensaje que dice que acabas de subir una rama y un botón verde "Compare & pull request". Haces clic.

Aparece una pantalla donde puedes escribir un título y una descripción explicando qué has hecho. Luego haces clic en "Create pull request".

Paso 7: El dueño revisa

El dueño del repositorio original recibirá una notificación. Puede revisar tus cambios, hacer comentarios, pedirte modificaciones, o aceptarlos.

Paso 8: Merge

Si el dueño acepta, hará clic en "Merge pull request". Tus cambios pasan a formar parte del proyecto original. ¡Enhorabuena! Has contribuido a un proyecto de código abierto.

Las Pull Requests son el corazón de la colaboración en GitHub. Grandes proyectos como React, Vue, o el propio código de GitHub se manejan así.

Conflictos en pull requests

Claro, los conflictos también pueden aparecer en las Pull Requests.

Imagina que tú haces un fork de un proyecto y empiezas a trabajar. Mientras tanto, el proyecto original avanza. El dueño ha aceptado otros cambios. Cuando tú abres tu Pull Request, puede que tus cambios y los del proyecto original toquen las mismas líneas.

GitHub te lo dirá claramente: "This pull request has conflicts that must be resolved".

Hay dos formas de resolverlo:

Opción 1: Desde GitHub (conflictos simples)

GitHub tiene un editor online donde puedes resolver conflictos directamente. Haces clic en "Resolve conflicts", editas los archivos, eliminas las marcas (<<<<<<<, =======, >>>>>>>), guardas y marcas como resuelto. Luego haces clic en "Commit merge".

Opción 2: En local (más control)

Te traes los cambios del repositorio original a tu fork:

git remote add upstream [email protected]:dueño/repositorio-original.git
git fetch upstream
git switch mi-mejora
git merge upstream/main

Resuelves conflictos en local, haces commit, y subes a tu fork:

git push origin mi-mejora

La Pull Request se actualizará automáticamente y ya no tendrá conflictos.

Sincronización de forks con el repositorio original

Cuando haces un fork, ese fork se queda congelado en el momento en que lo creaste. Pero el proyecto original sigue avanzando. Si quieres mantener tu fork actualizado (por ejemplo, antes de abrir una Pull Request o para seguir trabajando sobre la última versión), necesitas sincronizarlo.

El método más limpio es:

Paso 1: Añade el repositorio original como un remoto más

git remote add upstream [email protected]:dueño/repositorio-original.git

Paso 2: Descarga los cambios del original

git fetch upstream

Paso 3: Actualiza tu rama main local

git switch main
git merge upstream/main

Paso 4: Sube los cambios a tu fork

git push origin main

Tu fork ya está sincronizado.

Si estabas trabajando en una rama mi-mejora y quieres actualizarla también con lo último de main:

git switch mi-mejora
git merge main

Y resuelves conflictos si los hay.

GitHub también tiene un botón "Sync fork" en la interfaz web, pero hacerlo desde la terminal te da más control y te ayuda a practicar.

4.4. Herramientas complementarias de GitHub

GitHub no es solo para guardar código y hacer pull requests. Tiene muchas herramientas integradas que lo convierten en una plataforma completa para desarrollar software.

GitHub Pages (hosting gratuito de páginas web)

¿Sabías que puedes usar GitHub para tener tu propia página web gratis?

GitHub Pages te permite alojar sitios web estáticos (HTML, CSS, JavaScript) directamente desde tu repositorio. No necesitas pagar hosting ni configurar servidores.

Hay dos tipos de páginas:

Página personal: creas un repositorio llamado tu_usuario.github.io. Todo lo que subas ahí se verá en https://tu_usuario.github.io. Es perfecto para tu portafolio o tu blog personal.

Página de proyecto: en cualquier repositorio, puedes habilitar Pages en la configuración. Elige la rama (normalmente main o gh-pages) y la carpeta (raíz o /docs). Tu página estará en https://tu_usuario.github.io/nombre-repositorio.

¿Cómo se activa?

1. Ve a la configuración de tu repositorio (Settings).
2. Busca la sección "Pages" (en el menú de la izquierda).
3. Elige la rama que quieres usar (por ejemplo, main).
4. Guarda.

En unos segundos, tu página está publicada.

Puedes usar HTML y CSS normales, o incluso generadores de sitios estáticos como Jekyll (que GitHub soporta nativamente).

Es ideal para:

• Portafolio personal
• Documentación de tu proyecto
• Página de presentación de una app
• Juegos pequeños en JavaScript
• Prácticas de maquetación web

Todo gratis, todo desde Git.

GitHub Actions (automatización CI/CD)

GitHub Actions es una herramienta para automatizar tareas dentro de tu repositorio. Puedes hacer que cada vez que pase algo (un push, una pull request, un nuevo issue...), se ejecute un flujo de trabajo.

Por ejemplo, puedes configurar:

• Que cada vez que hagas push, se ejecuten pruebas automáticas (tests).
• Que cuando crees una pull request, se revise el estilo del código.
• Que cuando subas una etiqueta (tag) con formato v*, se despliegue tu página web automáticamente.
• Que cada día a las 12:00 se ejecute un script para actualizar datos.

Todo esto se define con YAML (un formato de texto sencillo) dentro de una carpeta especial en tu repositorio: .github/workflows/.

Un ejemplo básico: un flujo que imprime "Hola mundo" cada vez que haces push.

Creas el archivo .github/workflows/hola.yml:

name: Hola Mundo

on: [push]

jobs:
  saludar:
    runs-on: ubuntu-latest
    steps:
      - name: Saluda
        run: echo "¡Hola mundo desde GitHub Actions!"

Cuando subes este archivo a tu repositorio, cada push ejecutará ese trabajo. Lo verás en la pestaña "Actions" de tu repositorio.

Las posibilidades son enormes. Puedes ejecutar scripts en Python, Node.js, compilar código, desplegar en la nube, enviar notificaciones a Discord o Telegram, etc.

Además, GitHub tiene un marketplace con miles de acciones pre-hechas que puedes reutilizar. No necesitas inventar todo desde cero.

Uso de Issues, etiquetas y milestones

Si trabajas en un proyecto mínimamente serio (incluso si es solo tú), necesitas organizar las tareas. GitHub tiene un sistema de seguimiento de problemas llamado Issues.

Issues son como "tareas" o "reportes de error". Cualquier persona (dependiendo de los permisos) puede abrir un issue para decir: "Esto está roto" o "Propongo añadir esta funcionalidad".

Un issue tiene:

• Título
• Descripción (con formato Markdown)
• Persona asignada (quién debe resolverlo)
• Etiquetas
• Hito (milestone)
• Comentarios (donde se discute)

Etiquetas (labels) sirven para clasificar issues. Las más comunes:

• bug: algo que no funciona.
• enhancement: una mejora o funcionalidad nueva.
• documentation: falta documentación.
• good first issue: para principiantes.
• help wanted: se necesita ayuda.
• duplicate: ya existe otro issue igual.

Puedes crear tus propias etiquetas con colores personalizados.

Milestones (hitos) son como metas. Por ejemplo: "Versión 1.0", "Mejoras de rendimiento", "Sprint de marzo". Agrupas issues que quieres resolver antes de alcanzar ese hito.

También puedes crear project boards (tableros estilo Trello) para organizar issues en columnas como "Por hacer", "En progreso", "Hecho".

Todo esto es increíblemente útil cuando trabajas en equipo (o incluso cuando trabajas solo, para no perder el hilo de lo que tienes pendiente).

Resumen de la segunda parte

Hemos cubierto:

• Qué es GitHub y cómo se diferencia de Git.
• Cómo crear repositorios públicos y privados.
• Autenticación SSH: claves públicas y privadas, configuración.
• Comandos remotos: git remote, git push, git pull, git fetch.
• Clonar repositorios con git clone.
• El flujo de sincronización entre local y remoto.
• Colaboración avanzada: forks, pull requests, resolución de conflictos en PR, sincronización de forks.
• Herramientas complementarias: GitHub Pages para webs gratis, GitHub Actions para automatizar tareas, e Issues con etiquetas y milestones para organizar el trabajo.

Con todo esto, ya puedes trabajar en cualquier proyecto de GitHub, solo o en equipo, y sacarle partido a muchas de las funcionalidades que ofrece la plataforma.

En la siguiente parte (que será la tercera y última), hablaremos de buenas prácticas, flujos profesionales como GitFlow, comandos avanzados y herramientas gráficas. Pero antes de seguir, practica lo que has aprendido. Crea un repositorio, sube código, haz un fork de algún proyecto pequeño y abre tu primera pull request. Te prometo que la primera vez es emocionante.

Cuando estés listo, continuamos.

5. Buenas prácticas y flujos profesionales

Hasta ahora hemos aprendido a usar Git y GitHub. Sabemos hacer commits, crear ramas, resolver conflictos, subir código, hacer pull requests... Todo muy bien.

Pero hay una diferencia entre saber usar una herramienta y usarla bien. Y en el mundo profesional, eso marca la diferencia.

Imagina que aprendes a conducir. Sabes dónde está el volante, cómo cambiar de marcha, cómo frenar. Pero eso no te convierte en un buen conductor. Un buen conductor sabe cuándo cambiar de carril, cómo anticiparse al tráfico, cuándo usar las luces largas.

Con Git y GitHub pasa lo mismo.

En esta sección vamos a hablar de flujos de trabajo profesionales y de buenas prácticas. Cosas que no son obligatorias, pero que te harán la vida mucho más fácil si las sigues.

5.1. GitFlow

Hay muchas formas de organizar el trabajo con Git. Desde algo muy simple ("todos trabajan en main y rezan para no romper nada") hasta sistemas muy complejos con decenas de ramas y reglas estrictas.

La más famosa de todas es GitFlow.

GitFlow fue creada por Vincent Driessen en 2010 y desde entonces se ha convertido en un estándar. No es la única forma de trabajar (ni siquiera la más moderna), pero es la que más se usa y la que más documentos vas a encontrar. Si aprendes GitFlow, entenderás el 90% de los flujos profesionales que existen.

La idea detrás de GitFlow es muy sencilla: cada tipo de trabajo tiene su propio tipo de rama. Y hay reglas claras sobre cuándo se crean, cómo se llaman, y hacia dónde se fusionan.

Vamos a verlo paso a paso.

Ramas principales: main y develop

En GitFlow hay dos ramas principales que siempre existen y nunca se borran.

main (o master, según cómo lo llames): Esta rama contiene el código que está en producción. Es decir, la versión que están usando los usuarios de verdad. En teoría, todo lo que está en main debería funcionar perfectamente. No se hacen experimentos aquí. No se desarrolla aquí. Solo llega código probado y estable.

develop: Esta es la rama principal de desarrollo. Aquí es donde se integran todas las funcionalidades nuevas que están en construcción. Es como una "cola de preparación" antes de ir a producción. Cuando el código en develop está lo suficientemente maduro como para lanzar una nueva versión, se prepara el lanzamiento.

La regla de oro: nunca se hace desarrollo directamente en main ni en develop. Todo el trabajo nuevo se hace en ramas auxiliares.

Ramas de soporte: feature, release, hotfix

Además de las dos ramas principales, GitFlow define tres tipos de ramas auxiliares.

Ramas feature (características)

Estas ramas se usan para desarrollar funcionalidades nuevas. Cada funcionalidad tiene su propia rama.

• Se crean desde: develop
• Se fusionan hacia: develop
• Convención de nombre: feature/nombre-de-la-funcionalidad (por ejemplo, feature/login, feature/api-rest, feature/dashboard)

El flujo de una feature es:

1. Estando en develop, creas la rama: git switch -c feature/mi-funcionalidad
2. Trabajas en ella: commits, commits, commits.
3. Cuando terminas, vuelves a develop: git switch develop
4. Fusionas los cambios: git merge feature/mi-funcionalidad
5. Borras la rama: git branch -d feature/mi-funcionalidad
6. Subes develop actualizada al remoto: git push origin develop

Las ramas feature son temporales. Viven poco tiempo (días o semanas). Una vez fusionadas, se borran.

Ramas release (lanzamiento)

Estas ramas se usan para preparar una nueva versión que irá a producción. Aquí se hacen los últimos ajustes: cambiar la versión en los archivos, corregir pequeños bugs de última hora, etc.

• Se crean desde: develop
• Se fusionan hacia: main y develop
• Convención de nombre: release/versión (por ejemplo, release/1.0.0, release/2.1.3)

El flujo de una release:

1. Cuando develop está listo para una nueva versión, creas la rama desde develop: git switch -c release/1.0.0 develop
2. Haces los ajustes finales (cambiar número de versión, documentación, etc.).
3. Cuando está todo listo, te mueves a main y fusionas: git switch main → git merge release/1.0.0
4. Pones una etiqueta (tag) en main con el número de versión: git tag -a 1.0.0 -m "Versión 1.0.0"
5. También fusionas la release en develop (para que no se pierdan los ajustes finales): git switch develop → git merge release/1.0.0
6. Borras la rama: git branch -d release/1.0.0
7. Subes todo (main y develop) al remoto: git push origin main develop --tags

Ramas hotfix (arreglos urgentes)

Estas ramas son para corregir errores críticos en producción. El tipo de bug que no puede esperar al próximo lanzamiento.

• Se crean desde: main
• Se fusionan hacia: main y develop
• Convención de nombre: hotfix/descripción (por ejemplo, hotfix/error-login, hotfix/seguridad-api)

El flujo de un hotfix:

1. Detectas un bug en producción. Desde main creas una rama: git switch -c hotfix/error-login main
2. Corriges el error en esa rama (uno o varios commits).
3. Cuando está arreglado, te mueves a main y fusionas: git switch main → git merge hotfix/error-login
4. Pones una etiqueta (normalmente aumentas el "parche" de la versión, por ejemplo de 1.0.0 a 1.0.1): git tag -a 1.0.1 -m "Corrección de error en login"
5. También fusionas el hotfix en develop (si develop existe y está activo): git switch develop → git merge hotfix/error-login
6. Borras la rama: git branch -d hotfix/error-login
7. Subes todo: git push origin main develop --tags

Este diagrama resume el flujo completo de GitFlow:

Comandos de git flow (init, start, finish)

Todo esto que te he contado se puede hacer manualmente con los comandos básicos de Git. Pero es un montón de pasos. Y es fácil olvidar alguno.

Para hacerlo más sencillo, existe una extensión de Git llamada git-flow. Son comandos extra que automatizan todo el proceso.

Primero, tienes que instalar la extensión. Depende del sistema operativo:

• macOS (con Homebrew): brew install git-flow
• Linux (Ubuntu/Debian): apt-get install git-flow
• Windows: Viene incluido en algunas instalaciones de Git. Si no, busca "git-flow for Windows".

Una vez instalado, vamos a usarlo.

Inicializar GitFlow en un repositorio

Dentro de tu repositorio, ejecutas:

git flow init

Te hará unas preguntas: cómo se llama la rama principal (main), cómo se llama la de desarrollo (develop), qué prefijos quieres usar para feature, release, hotfix, etc. Puedes aceptar los valores por defecto (presionando Enter).

A partir de ahí, tu repositorio está configurado para usar GitFlow.

Crear una feature

En lugar de hacer todo el proceso manual:

git flow feature start mi-funcionalidad

Esto:

• Crea la rama feature/mi-funcionalidad desde develop.
• Te cambia automáticamente a esa rama.

Cuando terminas la feature:

git flow feature finish mi-funcionalidad

Esto:

• Fusiona feature/mi-funcionalidad en develop.
• Borra la rama feature/mi-funcionalidad.
• Te vuelve a develop.

Crear una release

git flow release start 1.0.0

Te crea y te mueve a release/1.0.0 desde develop.

Cuando terminas:

git flow release finish 1.0.0

Esto:

• Fusiona release/1.0.0 en main.
• Pone una etiqueta (tag) en main con el nombre 1.0.0.
• Fusiona también los cambios en develop.
• Borra la rama release/1.0.0.

Crear un hotfix

git flow hotfix start error-login

Crea hotfix/error-login desde main y te cambia a ella.

Cuando lo terminas:

git flow hotfix finish error-login

Hace todo el proceso: fusiona en main, pone tag, fusiona en develop, borra la rama.

Como ves, los comandos de git-flow simplifican muchísimo el trabajo. No tienes que acordarte de todos los pasos. Y lo más importante: no te olvidas de ninguno.

¿Es obligatorio usar GitFlow? No. Muchos equipos usan flujos más simples (como GitHub Flow, que es básicamente "una rama main y ramas de feature con pull requests"). Pero conocer GitFlow te da una base sólida para entender cómo se organizan los proyectos grandes.

5.2. Buenas prácticas recomendadas

Ahora vamos a hablar de buenas prácticas. Son consejos que he aprendido con los años, a base de cometer errores. Si las sigues desde el principio, evitarás muchos dolores de cabeza.

Commits atómicos y mensajes claros

¿Qué es un commit atómico?

Es un commit que hace una sola cosa. Solo una.

Por ejemplo, si estás arreglando un error y además añadiendo una funcionalidad nueva, son dos commits separados. Un commit para el error, otro commit para la funcionalidad.

¿Por qué? Porque si mezclas dos cambios en un mismo commit, luego no puedes deshacer uno sin deshacer el otro. Y cuando mires el historial dentro de tres meses, no entenderás qué pasó.

Regla de oro: cada commit debe poder describirse con una frase corta. Si necesitas usar la palabra "y", probablemente deberían ser dos commits.

Mensajes de commit claros

Un buen mensaje de commit responde a la pregunta: ¿Qué cambio y por qué?

Mensaje malo (lo he visto miles de veces):

cambios

arreglado

asdf123

Mensaje bueno:

Corrige error en el cálculo del IVA cuando el carrito está vacío

Añade validación de email en el formulario de registro

Actualiza documentación del endpoint de usuarios

Algunos consejos para mensajes:

• Usa el imperativo: "Añade", "Corrige", "Elimina", "Actualiza".
• Primera línea de máximo 50 caracteres.
• Si necesitas más explicación, deja una línea en blanco y luego escribe un párrafo más largo.
• No pongas punto al final de la primera línea.

Uso de ramas y revisiones de código

Nunca trabajes directamente en main

Parece obvio, pero mucha gente lo hace al principio. Y luego se arrepiente.

La rama main (o master) debería ser sagrada. Solo debe recibir cambios a través de merges (preferiblemente con pull request) después de que alguien haya revisado el código.

Crea una rama por cada tarea

¿Vas a arreglar un bug? Rama. ¿Vas a añadir una funcionalidad? Rama. ¿Vas a experimentar con algo? Rama.

Las ramas son baratas. Cuestan casi nada crearlas. Y te dan libertad para probar cosas sin miedo a romper el trabajo de otros.

Revisiones de código (Code Reviews)

Si trabajas en equipo (o incluso si trabajas solo, pero quieres mejorar), haz revisiones de código. Una pull request no es solo para fusionar cambios; es para que otra persona los mire y diga "esto está bien" o "esto se puede mejorar".

La revisión de código:

• Detecta errores antes de que lleguen a producción.
• Comparte conocimiento: si alguien ve tu código, aprende cómo funciona.
• Mejora la calidad: sabes que otra persona lo va a leer, así que te esfuerzas más.

Incluso si trabajas solo, puedes hacerte tus propias pull requests. Te obligas a mirar tus cambios con otros ojos antes de fusionarlos.

Mantener un README.md actualizado

El archivo README.md es la puerta de entrada a tu proyecto. Es lo primero que ve la gente cuando entra a tu repositorio en GitHub.

Un buen README debe responder estas preguntas en los primeros segundos:

• ¿Qué hace este proyecto?
• ¿Cómo lo instalo?
• ¿Cómo lo uso?
• ¿Cómo puedo contribuir?

Y debe estar actualizado. No hay nada peor que un README que dice una cosa y el código hace otra.

Estructura básica de un buen README:

# Nombre del proyecto

Una frase que explique qué es.

## Instalación

Pasos para instalar (comandos de terminal, dependencias, etc.)

## Uso

Ejemplo de cómo usar el proyecto.

## Contribución

Si alguien quiere ayudar, ¿cómo lo hace?

## Licencia

MIT, GPL, Apache... (si no sabes, pon "No especificada")

## Agradecimientos

Si usas bibliotecas de otros o has recibido ayuda.

No necesitas escribir una novela. Pero sí lo suficiente para que alguien que no sabe nada de tu proyecto pueda empezar a usarlo en 5 minutos.

Agregar licencia y documentación

Licencia

Si tu proyecto es público, necesitas una licencia. La licencia dice qué puede hacer la gente con tu código.

Sin licencia, legalmente, nadie puede copiar, modificar ni distribuir tu código. Es como si estuviera "todos los derechos reservados" sin decirlo explícitamente.

Las licencias más comunes para proyectos de código abierto:

• MIT: Muy permisiva. Pueden hacer casi cualquier cosa, siempre que incluyan tu copyright. Ideal para librerías y herramientas.
• Apache 2.0: Parecida a MIT, pero con protección de patentes. Usada por Google, Android, etc.
• GPL: Exige que cualquier proyecto que use tu código también sea de código abierto. Es más restrictiva.
• Creative Commons: Para documentación, no para código.

¿Cuál elegir? Si no sabes, MIT es una opción segura para empezar. En GitHub, al crear un repositorio, puedes elegir una licencia de una lista. O si ya tienes el repositorio, añades un archivo LICENSE en la raíz.

Documentación

La documentación no es solo el README. Puedes tener:

• Wiki del repositorio (GitHub la ofrece gratis).
• Carpeta /docs dentro del repositorio con archivos Markdown.
• GitHub Pages con una web de documentación (usando herramientas como MkDocs, Docusaurus, etc.).

La regla de oro: escribe la documentación como si quien la lee no sabe nada. Así te aseguras de que sea útil para principiantes.

6. Herramientas gráficas (GUIs)

Hasta ahora hemos hecho todo desde la terminal. Y está bien. La terminal es potente, es rápida y funciona igual en cualquier sistema operativo.

Pero no es la única forma de trabajar con Git.

Hay herramientas gráficas (GUI, Graphical User Interface) que hacen lo mismo pero con botones, ventanas, árboles visuales, y colores. Para algunas personas, esto es mucho más cómodo.

No hay una opción correcta o incorrecta. Es cuestión de gustos y de lo que necesites en cada momento. Yo personalmente uso la terminal para cosas rápidas y una GUI para explorar el historial o cuando tengo que hacer merges complejos. Lo importante es que entiendas los conceptos. La herramienta es solo un medio.

Vamos a ver las más populares.

GitHub Desktop

GitHub Desktop es la herramienta oficial de GitHub. Es gratuita, funciona en Windows y macOS (Linux no tiene versión oficial, pero hay alternativas), y está diseñada para ser muy sencilla.

Si estás empezando, es una excelente opción. No tiene todas las funcionalidades avanzadas, pero cubre el 90% de lo que necesitas en el día a día.

Principales características:

• Autenticación con GitHub: Vinculas tu cuenta y ves todos tus repositorios.
• Clonar con un clic: Buscas un repositorio y lo clonas sin escribir comandos.
• Historial visual: Ves la lista de commits, con sus mensajes y hashes.
• Stage visual: En lugar de git add, marcas checkboxes en los archivos que quieres incluir.
• Commit con formulario: Escribes el mensaje en una caja de texto y pulsas un botón.
• Push y pull con botones: No necesitas recordar los comandos.
• Ramas: Creas ramas, cambias entre ellas, las fusionas, todo desde menús.
• Pull Requests: Puedes crear y revisar PRs sin salir de la app.

Cómo usarlo básico:

1. Instalas GitHub Desktop (desktop.github.com).
2. Inicias sesión con tu cuenta de GitHub.
3. Clonas un repositorio (File → Clone Repository).
4. Haces cambios en tu editor de código.
5. En GitHub Desktop, ves los archivos modificados. Marcas los que quieres añadir al commit.
6. Escribes un mensaje y pulsas "Commit to main" (o a la rama que toque).
7. Pulsas "Push origin" y ya está en GitHub.

Es muy intuitivo. Si alguien te dice que "los de verdad usan la terminal", no le hagas caso. Lo importante es que entiendas el flujo. La herramienta es secundaria.

GitKraken, SourceTree, Fork

Estas son herramientas más potentes que GitHub Desktop. Tienen más funcionalidades y son usadas por muchos profesionales.

GitKraken

Es mi favorita personal. GitKraken tiene una interfaz muy bonita y un árbol de commits visual que es una maravilla. Ves todas las ramas, todos los commits, y cómo se conectan, todo en un gráfico.

• Gratis para repositorios públicos. De pago para privados (aunque tiene un plan gratuito limitado para privados también).
• Disponible en Windows, macOS y Linux.
• Integración con GitHub, GitLab, Bitbucket.
• Resolución de conflictos visual (más fácil que la terminal).
• Comandos de GitFlow integrados (con botones).
• Terminal integrada si necesitas escribir comandos.

SourceTree

Es la herramienta de Atlassian (la empresa que hace Jira y Bitbucket). Es gratuita y muy potente, pero la interfaz es menos amigable que GitKraken (al menos para mí). Muchos equipos la usan porque se integra bien con Bitbucket.

• Windows y macOS (no Linux).
• Muestra el árbol de commits.
• Permite hacer todo: stage, commit, push, pull, merge, rebase, stash, etc.
• Soporta GitFlow.

Fork

Fork es una herramienta más moderna, muy rápida y con una interfaz limpia. Es de pago (pero tiene prueba gratuita y no es cara). Algunos la prefieren porque es más ligera que GitKraken.

• Windows y macOS (no Linux).
• Árbol de commits visual.
• Resolución de conflictos integrada.
• Muy rápida.

¿Cuál elegir? Si quieres algo sencillo y oficial, GitHub Desktop. Si quieres potencia visual y no te importa pagar (o solo usas repositorios públicos), GitKraken. Si quieres gratis y potente, SourceTree. Si quieres moderno y rápido, Fork.

Mi recomendación para empezar: GitHub Desktop. Cuando te sientas cómodo y necesites más, prueba GitKraken.

Integración con editores como VS Code o IntelliJ

Lo bueno de Git es que está en todas partes. No necesitas una aplicación separada. Tu propio editor de código ya tiene integración con Git.

Visual Studio Code (VS Code)

VS Code es el editor más popular hoy en día. Y tiene soporte Git increíble.

Cosas que puedes hacer desde VS Code sin abrir la terminal:

• Ver los cambios en los archivos (colores verde/rojo en el margen).
• Hacer stage de archivos (botón "+" al lado del archivo).
• Hacer commit (escribes el mensaje en una caja de texto y pulsas "Commit").
• Ver el historial de commits (en la pestaña "Source Control").
• Crear y cambiar de ramas (desde la barra inferior o desde el menú de ramas).
• Hacer push y pull (botones en la interfaz).
• Resolver conflictos (te muestra las tres versiones: actual, entrante y resultado final).

Además, hay extensiones como GitLens que llevan la integración a otro nivel: te muestra quién escribió cada línea, el historial de un archivo, comparación visual de commits, etc. Es impresionante.

IntelliJ IDEA (y otros de JetBrains)

Los editores de JetBrains (IntelliJ para Java, PyCharm para Python, WebStorm para JavaScript, etc.) también tienen una integración Git muy potente.

• Puedes hacer todo desde el menú VCS (Version Control System).
• Tiene un "log" visual con colores por rama.
• Resolución de conflictos con interfaz de tres paneles.
• Anotaciones (git blame) para ver quién escribió cada línea.

Otros editores

• Sublime Text: Tiene paquetes para Git (como GitGutter).
• Atom (aunque ya está medio abandonado): Tenía integración Git.
• Vim/Neovim: Para los muy puristas, hay plugins como fugitive que dan poder total.

La ventaja de usar Git desde el editor es que no tienes que cambiar de contexto. Estás escribiendo código y, con unos pocos clics o atajos de teclado, haces commit, push, pull. Es muy fluido.

Yo personalmente uso la terminal para el 80% de las cosas (por costumbre y rapidez) y el editor para ver el historial o para hacer commits rápidos. Pero cada persona encuentra su equilibrio.

Resumen de la tercera parte

Hemos cubierto:

• GitFlow: el flujo profesional más famoso, con sus ramas principales (main y develop) y ramas de soporte (feature, release, hotfix). Y los comandos git flow que automatizan todo.
• Buenas prácticas: commits atómicos con mensajes claros, usar ramas siempre, revisiones de código, mantener README actualizado, añadir licencia y documentación.
• Herramientas gráficas: GitHub Desktop (sencilla y oficial), GitKraken (potente y bonita), SourceTree (gratis y completa), Fork (moderna y rápida), y la integración nativa en editores como VS Code o IntelliJ.

Lo que viene

En la última parte (que será más corta, porque ya hemos cubierto lo esencial), hablaremos de comandos avanzados que no usas a diario pero que te salvan en situaciones concretas, de GitHub Pages y Actions (ya lo vimos un poco, pero profundizaremos), y de conclusión y próximos pasos.

Pero antes, tómate un descanso. Has llegado muy lejos. Con lo que sabes ahora, ya puedes trabajar en cualquier proyecto que use Git y GitHub. Todo lo demás son detalles y comandos específicos que irás aprendiendo sobre la marcha.

Cuando estés listo, continuamos con el broche final.

7. Trunk-Based Development: la alternativa moderna a GitFlow

Hasta ahora hemos hablado mucho de GitFlow. Y está bien. GitFlow es una forma muy estructurada y organizada de trabajar con ramas. Te da seguridad, orden y un lugar para cada cosa.

Pero no es la única forma de trabajar. Y en los últimos años, muchos equipos han empezado a cambiar hacia un enfoque más simple y ágil.

Se llama Trunk-Based Development (o TBD para los amigos).

Y sí, es importante que lo conozcas. Porque aunque empieces usando GitFlow (que está muy bien para aprender), es muy probable que en algún momento de tu carrera te encuentres con un equipo que usa TBD. O que tú mismo quieras probarlo porque has oído que es más rápido.

Así que vamos a verlo con calma.

¿Qué es Trunk-Based Development?

Imagínate que en lugar de tener ramas develop, feature/*, release/*, hotfix/*... solo tienes una rama principal. Una sola. Se llama main (o trunk, de ahí el nombre).

Todos los desarrolladores trabajan sobre esa misma rama. O como mucho, crean ramas muy pequeñas que duran horas, no días ni semanas.

La idea es sencilla: integras cambios pequeños y frecuentes en la rama principal muchas veces al día.

Si te suena a "eso es justo lo contrario de GitFlow", has dado en el clavo.

Mientras que GitFlow te da muchas ramas y muchos pasos, TBD te dice: "simplifica, integra rápido, no acumules cambios".

Este enfoque está muy alineado con metodologías ágiles y DevOps, donde la prioridad es la automatización, la productividad y la colaboración constante entre equipos.

"Trunk-Based Development es una estrategia de control de versiones que promueve la colaboración continua y la integración frecuente de cambios en una única rama principal del código, conocida como 'trunk' o 'main'." — Sergio Perea, ¿Qué es Trunk-Based Development?

Principios fundamentales de TBD

Sergio Perea, en su artículo, enumera los principios clave de TBD. Te los resumo:

1. Integración continua: Los desarrolladores integran sus cambios en la rama principal varias veces al día. Esto facilita la detección temprana de errores y reduce los conflictos.

2. Ramas de corta duración: Si se usan ramas (a veces sí, para cambios más grandes), duran horas o pocos días. Nada de ramas que viven semanas.

3. Revisión de código continua: Las revisiones son rápidas y constantes. No te tiras dos días esperando que alguien revise tu pull request.

4. Automatización de pruebas: Cada integración ejecuta pruebas automáticas. Si algo falla, se detecta al momento.

5. Uso de feature flags: Las "banderas de características" permiten activar o desactivar funcionalidades en producción sin necesidad de desplegar código nuevo. Esto es clave para TBD, porque puedes subir código incompleto (pero protegido) sin que afecte a los usuarios.

Beneficios de TBD

¿Por qué alguien cambiaría de GitFlow a TBD? Por estas razones:

Reducción de conflictos de integración: Al integrar cambios pequeñitos y muy seguido, los conflictos casi no aparecen. Y si aparecen, son tan pequeños que se resuelven en segundos.

Entrega continua: El código en main está siempre en un estado que se puede desplegar. No necesitas ramas de release ni preparaciones largas. Si quieres lanzar una nueva versión, lo haces ahora mismo.

Mejora en la calidad del código: Las revisiones continuas y las pruebas automáticas hacen que el código se mantenga limpio y funcional.

Mayor colaboración: Cuando todos trabajan sobre la misma rama (o sobre ramas muy cortas), todo el mundo ve lo que hacen los demás. No hay sorpresas de "llevo tres semanas en mi rama y ahora no puedo fusionar".

Comparación con GitFlow

Esta comparación es importante. Porque GitFlow no es "malo" y TBD no es "bueno". Son herramientas para contextos diferentes.

Como dice Sergio en su artículo:

"Mientras Git Flow es útil en entornos con ciclos de lanzamiento largos y estructuras más formales, Trunk-Based Development está más alineado con metodologías ágiles y DevOps, donde la prioridad es la automatización, la productividad y la colaboración constante entre equipos."

Si trabajas en una startup que despliega varias veces al día, TBD es tu amigo. Si trabajas en un banco que lanza una versión al año y necesita trazabilidad estricta, igual GitFlow te va mejor.

Paso 1: Establecer una rama principal compartida

El primer paso para adoptar TBD es muy simple en teoría, pero puede ser un cambio cultural enorme: decidir que solo hay una rama principal.

¿Por qué una sola rama?

• Evitas que el código se "desvíe" entre ramas largas.
• Todo el mundo trabaja sobre lo mismo.
• Los merges son pequeños y frecuentes, no monstruosos después de semanas.
• Lo que ves en main es lo que hay. Sin sorpresas.

Pasos para establecerla correctamente

1. Nombra la rama principal

Hoy en día se usa main en lugar de master. Si tu proyecto todavía tiene master, lo renombras:

git branch -m master main
git push -u origin main
git symbolic-ref refs/remotes/origin/HEAD refs/remotes/origin/main

2. Bloquea el uso de ramas largas

En GitHub (o GitLab, o Bitbucket) puedes configurar reglas para que no se puedan crear ramas que duren mucho tiempo. O al menos, desalentarlo explícitamente. Nada de ramas develop o release eternas.

3. Activa protección y revisión en main

Que no cunda el pánico. TBD no significa "cualquiera puede romper main". Al contrario.

En GitHub, ve a Settings > Branches > Branch Protection Rules y activa:

• Requerir pull requests para fusionar.
• Requerir revisiones (al menos una persona).
• Exigir que pasen los tests automáticos antes de fusionar.

4. Automatiza la integración y las pruebas

Cada cambio en main debe pasar por un pipeline de CI/CD (integración continua y despliegue continuo). Con GitHub Actions, por ejemplo, puedes ejecutar tests automáticamente cada vez que alguien hace push o abre una pull request.

El pipeline debe ser rápido (menos de 10 minutos). Si tarda más, la gente empezará a evitar integrar con frecuencia.

5. Educa al equipo

Este es el paso más difícil. La gente está acostumbrada a GitFlow (o a no usar nada ordenado). Hay que explicarles:

• Por qué cambiamos.
• Cómo funciona TBD.
• Cuáles son las nuevas reglas: "nunca rompas main", "integra al menos una vez al día", "usa feature flags", etc.

Buenas prácticas adicionales en TBD

Además de los pasos anteriores, hay cosas que ayudan mucho:

Commits pequeños y atómicos

Un commit debe hacer una cosa. Una sola. Si tienes que explicarlo con un "y", probablemente sean dos commits.

Mensajes de commit claros

Usa convenciones como Conventional Commits. Por ejemplo:

• feat: cuando añades una funcionalidad nueva.
• fix: cuando corriges un error.
• refactor: cuando cambias estructura sin cambiar funcionalidad.
• test: cuando añades pruebas.
• docs: cuando cambias documentación.

Ejemplo:

git commit -m "feat: añade feature toggle para búsqueda avanzada"

Esto no solo queda bonito. Permite generar changelogs automáticos y entender el historial de un vistazo.

Feature toggles (banderas de características)

Esta es una de las claves de TBD.

Una feature toggle es una variable que activa o desactiva una funcionalidad. Puedes subir código incompleto a main, pero desactivado. Cuando está listo, cambias el toggle y ya está disponible.

Sergio pone un ejemplo en Python que te copio aquí porque es muy claro:

# config.py
FEATURE_FLAGS = {
    "advanced_search": False  # Cambia a True para activarla
}

# main.py
from config import FEATURE_FLAGS

def basic_search():
    return "Ejecutando búsqueda básica..."

def advanced_search():
    return "Ejecutando búsqueda avanzada con filtros..."

def search():
    if FEATURE_FLAGS["advanced_search"]:
        return advanced_search()
    return basic_search()

if __name__ == "__main__":
    print(search())

Así puedes integrar código nuevo sin miedo. Está ahí, pero no se ve hasta que lo decidas.

Posibles dificultades de TBD

No todo es bonito. TBD también tiene sus problemas:

Rupturas accidentales: Si alguien introduce código defectuoso en main, todos se ven afectados. Por eso la CI y las revisiones son obligatorias, no opcionales.

Resistencia al cambio: Equipos acostumbrados a GitFlow pueden tener miedo de "romper cosas". Aquí la formación y la confianza son clave.

Cambios grandes: ¿Y si tienes que hacer una refactorización enorme que lleva semanas? En TBD puro, eso no se puede. La solución: técnicas como branch by abstraction (crear una capa intermedia) o usar feature flags para ir activando partes poco a poco.

Paso 2: Fomentar integraciones frecuentes

El segundo pilar de TBD (después de tener una rama principal) es que la gente integre con frecuencia.

¿Qué significa "con frecuencia"?

• Al menos una o dos veces al día.
• Idealmente, cada pocas horas.
• Nunca pasar días sin hacer push a main (o a una rama corta que vaya a main).

Beneficios de integrar frecuentemente

1. Reducción de conflictos: Si integras cada hora, las diferencias entre tu código y el de tus compañeros son mínimas. Los conflictos, si los hay, se resuelven en segundos.

2. Visibilidad y colaboración: Todo el mundo ve lo que hacen los demás en tiempo real. Si alguien está cambiando una parte crítica, lo sabes al momento.

3. Mejora continua: Cada integración pequeña se prueba, se revisa y se despliega (si toca). El feedback es inmediato.

Requisitos para que funcione

Para poder integrar varias veces al día, necesitas:

Tests automáticos rápidos y fiables: Los tests unitarios deben correr en segundos. Los de integración, en minutos. Y tienen que ser fiables: si fallan, es porque algo está roto de verdad.

CI bien configurada: GitHub Actions, GitLab CI, Jenkins... da igual la herramienta, pero debe estar ahí ejecutándose cada vez que alguien hace push.

Desacoplamiento y modularidad: Si el código está todo enmarañado, es difícil hacer cambios pequeños. Aplicar principios como "una clase, una responsabilidad" ayuda muchísimo.

Pequeños pasos (baby steps): Una funcionalidad grande se parte en trocitos pequeños. Cada trocito se integra por separado, protegido por un feature toggle si hace falta.

Uso de Feature Flags: Ya lo hemos dicho, pero es tan importante que lo repito. Los feature flags te permiten subir código incompleto sin miedo.

Técnicas para lograrlo

Commit temprano, commit a menudo: No esperes a tenerlo todo perfecto. Haz commits pequeños y súbelos.

Push en medio del trabajo: Si llevas unas horas y aún no has terminado, haz push igual (con la funcionalidad desactivada con un toggle si es necesario).

Pull frecuente del trunk: Antes de empezar a trabajar, haz git pull origin main. Y cada pocas horas, también. Así tu código no se desfasa del de los demás.

Short-lived branches: Si usas ramas (a veces son necesarias), que duren solo horas. Un día como mucho. Nada de ramas de una semana.

Qué evitar

• Ramas que duran varios días.
• Esperar a "tenerlo todo listo" para integrar.
• Cambios enormes sin tests.
• Integrar sin hacer pull antes (y luego tener conflictos enormes).
• Depender solo de integración manual (sin CI/CD).

Cultura de equipo: un factor clave

Esto no es solo técnico. Es cultural.

Para que TBD funcione, el equipo tiene que tener:

• Confianza: Saber que si alguien rompe algo, se arregla juntos, no se echan culpas.
• Valentía: Subir código incompleto (pero protegido) requiere valentía.
• Disciplina: Escribir tests desde el principio. No dejar las pruebas para "luego".
• Revisión rápida: Las pull requests se revisan en minutos, no en días.
• Tolerancia al cambio: El código está vivo. Cambia constantemente. Eso está bien.

Como dice Sergio en su artículo:

"Integrar frecuentemente es una práctica que debe estar respaldada por la cultura del equipo. Esto incluye confianza entre desarrolladores, valentía para subir código incompleto (pero protegido), disciplina para escribir tests desde el principio, revisión rápida y constante de PRs, y tolerancia al cambio constante."

Ejemplo práctico de un día en TBD

Para que te hagas una idea de cómo funciona TBD en el mundo real, imagina un equipo de 4 desarrolladores. Esto es lo que pasa en un día normal:

1. Pedro llega por la mañana y hace git pull origin main.
2. Crea una rama feat/nueva-alerta (sí, a veces se usan ramas, pero cortas).
3. En 2 horas, termina la primera parte de su funcionalidad.
4. Abre una pull request con tests y la etiqueta #WIP (Work In Progress).
5. Jaime (su compañero) ve la PR al momento, la revisa y le sugiere un pequeño cambio.
6. Pedro lo aplica, los tests pasan en CI, y Jaime fusiona la PR a main.
7. Al final del día, Pedro ha integrado 3 veces a main.

Sin semanas enteras sin integrar. Sin conflictos enormes. Sin sorpresas de última hora.

¿TBD o GitFlow? ¿Cuál elijo?

No hay una respuesta única. Depende.

Elige GitFlow si:

• Tu proyecto tiene ciclos de lanzamiento largos (semanas o meses).
• Necesitas mantener varias versiones en paralelo (ej: v1.0, v2.0, etc.).
• Tu equipo prefiere estructuras muy definidas y ramas para todo.
• No despliegas con frecuencia (porque el proceso de aprobación es lento, por ejemplo).

Elige TBD si:

• Deseas desplegar varias veces al día (o al menos muy seguido).
• Tu equipo es pequeño o mediano (funciona bien hasta 10-15 personas).
• Tienes buenas pruebas automáticas y CI/CD.
• Quieres mínimos conflictos y máxima velocidad.
• Usas (o estás dispuesto a usar) feature flags.

Y una cosa importante: no tienes que elegir uno para siempre. Puedes empezar con GitFlow mientras aprendes y luego pasarte a TBD cuando tu equipo y tu proyecto estén listos. O incluso usar una mezcla: GitFlow para el código muy estable y TBD para experimentos rápidos.

Lo importante es que conozcas las opciones y puedas decidir con criterio.

Enlaces y referencias

Este resumen está basado en el excelente artículo de Sergio Perea sobre Trunk-Based Development. Si quieres profundizar (y te recomiendo que lo hagas), aquí tienes el enlace:

👉 ¿Qué es Trunk-Based Development? por Sergio Perea

En su blog también encontrarás artículos relacionados como Feature Toggles (cómo implementarlas de 0 a experto), que es un complemento perfecto para entender cómo aplicar TBD en la práctica.

Resumen de esta última parte

Hemos cubierto:

• Qué es Trunk-Based Development: una estrategia de control de versiones centrada en una única rama principal e integraciones frecuentes.
• Principios fundamentales: integración continua, ramas cortas, revisión constante, automatización y feature flags.
• Beneficios: menos conflictos, entrega continua, mejor calidad, más colaboración.
• Comparación con GitFlow: cuándo usar cada uno.
• Paso 1: cómo establecer una rama principal compartida (nombrarla, protegerla, automatizarla, educar al equipo).
• Paso 2: cómo fomentar integraciones frecuentes (commits pequeños, push seguido, pull a menudo, ramas de corta duración).
• Buenas prácticas: commits atómicos, mensajes claros (Conventional Commits), feature toggles.
• Posibles dificultades: rupturas accidentales, resistencia al cambio, cambios grandes.
• Cultura de equipo: confianza, valentía, disciplina, revisión rápida.
• Ejemplo práctico: un día real en un equipo que usa TBD.

Conclusión final de todo el artículo

Hemos recorrido un camino muy largo. Desde no saber qué era Git hasta entender flujos profesionales como GitFlow y TBD.

Hemos instalado, configurado, hecho commits, creado ramas, resuelto conflictos, subido código a GitHub, hecho pull requests, sincronizado forks, y hasta hablado de feature flags y despliegue continuo.

Si has llegado hasta aquí, enhorabuena. No es un camino fácil. Pero te prometo que todo este esfuerzo vale la pena.

Git y GitHub no son herramientas que se aprenden en un día. Son como aprender a tocar un instrumento: al principio cuesta, los dedos no responden, te equivocas de comando, rompes cosas. Pero con práctica, se convierte en algo natural. Y cuando dominas Git, te das cuenta de que programar sin él es como escribir un libro a mano sin poder borrar ni guardar copias.

Próximos pasos

Ahora que sabes todo esto, ¿qué haces?

1. Practica. Crea repositorios, haz pruebas, rompe cosas a propósito y luego arréglalas.
2. Lee documentación oficial. Tanto Git como GitHub tienen documentación excelente y gratuita.
3. Únete a comunidades. Hay mucha gente aprendiendo y dispuesta a ayudar.
4. Contribuye a proyectos de código abierto. Empieza con pequeños cambios (documentación, algún error simple). Es la mejor forma de aprender TBD y colaboración real.
5. No pares de aprender. Tanto Git como GitHub añaden funcionalidades nuevas con frecuencia. Mantente actualizado.

Recursos finales

Estos son los recursos que más me han ayudado a mí (y los que aparecen a lo largo del material que hemos usado):

• Documentación oficial de Git: git-scm.com/doc
• Libro Pro Git (gratis, en español): git-scm.com/book/es/v2
• Documentación oficial de GitHub: docs.github.com/es
• Cheatsheet de comandos Git: training.github.com

Y por supuesto, el artículo de Sergio Perea sobre Trunk-Based Development que ha inspirado esta última sección: https://sperea.es/blog/trunk-based-development

Muchas gracias por leer hasta aquí.

Si te ha servido, compártelo con alguien que también esté aprendiendo. Y si algo no te ha quedado claro, vuelve a leer la sección correspondiente. Esto no es una carrera. Es un aprendizaje para toda tu carrera profesional.

Ahora te toca a ti: abre la terminal, escribe git init, y empieza a guardar tu historia.

¡Buena suerte!