Control de versiones con Git en criollo: Tutorial ATP y APB
¡Qué tema el control de versiones! Es un problema clásico que aparece en la vida de un programador cuando empieza a cambiarle el nombre a los archivos a mano, con información de los cambios nuevos en el nombre.
En el desarrollo de software se utilizan múltiples archivos en diversos lenguajes que interactúan entre sí para los interpretados o se encastran de cierta forma para generar un ejecutable en los compilados. Es fácil ver cómo el problema del versionado se va complicando. Ahora, imaginate cómo se complica si hay que coordinar los cambios de mucha gente al mismo tiempo y colaborar sin romper nada.
Ahí fue donde apareció al rescate el gran prócer de la computación, Linus Torvalds, y en 2005 inventó Git para ordenar mejor el desarrollo del kernel de Linux y el resto es historia (no digo fué, porque se sigue construyendo y escribiendo día a día, mira como commitea el loco Laaaiiinuuuusss!).
Git es un software de control de versiones distribuido que nos provee de un conjunto de herramientas para tener un seguimiento de cambios, volver atrás a estados anteriores, desarrollar cosas nuevas en paralelo y, sobre todo, trabajar con otras personas sin conflictos.
Bah, sin tantos conflictos, porque las personas seguimos estando involucradas en el proceso. Y esperemos que así sea por un tiempo.
La idea de este artículo es mostrar cómo funciona Git, para qué se usa y, finalmente, cerrar con un ejemplo para implementarlo paso a paso, ya sea para proyectos personales o desarrollo colaborativo.
Git y Github
¿Qué es Git?
Git es un programa para automatizar el control de versiones en el desarrollo de software. Visualmente, yo puedo tener mi copia local del proyecto, probar modificaciones en paralelo y crear ramas (branches) para trabajar en diferentes partes del proyecto sin afectar la versión principal. Cuando el trabajo está listo, podés mover esos cambios a la versión principal mediante un proceso llamado “merge” o fusión. Finalmente, subís esos cambios al repositorio remoto, que puede estar en plataformas GitHub o GitLab. Ese repositorio remoto es el lugar donde se juntan todos los cambios de los colaboradores involucrados en el proyecto.
¿Qué es GitHub?
Github es una plataforma online de desarrollo de software que te permite tener una copia de tu repositorio en tu cuenta, funcionando como un backup remoto.
En conjunto con Git, permite tener un repositorio central accesible por internet, ya sea público o privado. Podés compartir este repositorio con colaboradores, dándoles acceso de solo lectura en caso de repositorios privados, o acceso de edición a colaboradores. Cada colaborador se identifica con su propia cuenta, lo que facilita la gestión de permisos.
Una vez que tenés tu repositorio clonado localmente, podés hacer lo que quieras con él.
¿Dónde se guardan los archivos?
Un proyecto no es más que un conjunto de archivos con diferentes extensiones que definen cómo se ejecutan o qué contienen.
El directorio (o carpeta) que contiene todos los archivos del proyecto con el que interactuamos vive localmente en nuestra máquina. Ahí, podés usar Git para versionar tu trabajo, guardando “fotos” del proyecto en distintos momentos del tiempo. Git guarda el historial de cambios en sus carpetas, lo que te permite rastrear y revertir modificaciones si es necesario.
Este historial se sincroniza cuando decidís interactuar con el repositorio remoto, subiendo los cambios para que sean compartidos con los demás miembros de tu equipo de trabajo. Además, desde este repositorio remoto podés crear copias locales de otras ramas (branches) y traerte los últimos cambios que hayan subido tus compañeros en las ramas en las que están trabajando juntos.
Flujo de Trabajo de Git para Desarrollo
Creando o Clonando un Repositorio
Comenzar un nuevo proyecto o trabajar en uno existente se puede hacer de las siguientes formas:
- Creando un nuevo repositorio:
- Inicializá un nuevo repositorio de Git localmente
- Opcionalmente, creá un repositorio remoto en una plataforma como GitHub
- Vinculá los repositorios local y remoto
- Clonando un repositorio existente:
- Usá el comando
git clone
para copiar un repositorio remoto a tu máquina local
- Usá el comando
Cuando uno clona, lo que hace es justamente clonar el repositorio remoto a un nuevo repositorio local para trabajar sobre ese código.
Haciendo Cambios y Commiteando
A medida que trabajás en tu proyecto, Git rastrea los cambios en tus archivos. El flujo de trabajo básico sigue estos pasos:
- Modificar los archivos en tu directorio de trabajo.
- Stagear (o preparar) los cambios que querés commitear.
- Commitear los cambios stageados con mensajes descriptivos.
- Opcionalmente, pushear los commits a un repositorio remoto.
Colaborando con Otros
Cuando trabajás en proyectos compartidos, el flujo de trabajo suele ser el siguiente:
- Pulleás los últimos cambios del repositorio remoto.
- Creás una nueva rama para tu feature o corrección de bug.
- Hacés y commiteás tus cambios.
- Pusheás la rama al repositorio remoto.
- Creás un pull request para revisión (si usás una plataforma como GitHub).
- Mergeás los cambios después de la aprobación.
Conceptos Clave de Git
Repositorios
Un repositorio de Git es una colección de archivos y su historial de revisiones. Hay dos tipos:
- Repositorio local: Existe en tu máquina.
- Repositorio remoto: Alojado en un servidor, como GitHub, GitLab o Bitbucket.
Git no rastrea todos los archivos del proyecto automáticamente. Los archivos pueden estar en los siguientes estados:
- No Rastreado - untracked: Archivos nuevos agregados al proyecto que Git aún no está siguiendo.
- Preparado - added: Archivos que están listos para ser incluidos en el próximo commit. Los cambios se preparan usando el comando
git add
. - Cometido - commited: Cambios que han sido registrados en el historial del repositorio. Se guardan en el historial usando el comando
git commit
. - Ignorados - ignored: Archivos que git no rastreará, como archivos de claves para conexión y acceso a recursos, archivos demasiado grandes, configuraciones locales o archivos auxiliares que se crean localmente durante el desarrollo. Estos se especifican en un archivo oculto en la raíz del proyecto llamado
.gitignore
.
Commits
Un commit representa un punto específico en la historia del proyecto. Incluye:
- Un identificador único (hash).
- Un mensaje de commit describiendo los cambios realizados.
- Una instantánea del proyecto en ese momento.
Ramas
Las ramas te permiten divergir de la línea principal de desarrollo para trabajar en nuevas features o experimentos de forma independiente, sin afectar el código principal.
Merging
El merging es el proceso de integrar cambios de una rama a otra, típicamente combinando ramas de features de vuelta a la rama principal (main o master).
Seguimiento Remoto
Git te permite mantener tu repositorio local sincronizado con repositorios remotos, facilitando la colaboración y backup del proyecto.
Mejores Prácticas
- Commiteá frecuentemente con mensajes claros y descriptivos.
- Usá ramas para desarrollar nuevas features o experimentos.
- Mantené la rama principal estable, siempre lista para compilar y desplegar.
- Revisá los cambios antes de mergear.
- Usá
.gitignore
para excluir archivos innecesarios. - Pulleá regularmente los cambios del repositorio remoto.
- Resolvé conflictos rápida y cuidadosamente.
Al entender estos conceptos y seguir las mejores prácticas, estarás bien preparado para usar Git de manera efectiva, tanto en proyectos personales como en desarrollo colaborativo.
Tutorial Práctico: Configuración y Contribución
Este tutorial práctico te guiará a través del proceso de creación de un nuevo repositorio, configurar un sitio Jekyll y hacer contribuciones usando Git y GitHub. Cubriremos tanto operaciones de línea de comandos como integración con Visual Studio Code.
Prerrequisitos
Antes de comenzar este tutorial, asegurate de tener:
- Git instalado en tu sistema.
- Una cuenta de GitHub.
- GitHub CLI (
gh
) instalado. - Jekyll instalado.
- Visual Studio Code (VSCode) instalado.
Parte 1: Operaciones de Línea de Comandos
Paso 1: Crear un Nuevo Repositorio en GitHub
-
Abrí tu terminal e iniciá sesión en GitHub usando GitHub CLI:
gh auth login
Seguí las indicaciones para completar el proceso de autenticación.
-
Creá un nuevo repositorio en GitHub:
gh repo create mi-sitio-jekyll --public
Este comando crea un nuevo repositorio público llamado “mi-sitio-jekyll” en tu cuenta de GitHub.
Paso 2: Clonar el Repositorio Localmente
-
Cloná el repositorio recién creado a tu máquina local:
git clone https://github.com/tu-usuario/mi-sitio-jekyll.git cd mi-sitio-jekyll
-
Examiná el contenido del directorio
.git
:ls -la .git
Este comando te mostrará la estructura interna del repositorio Git.
Paso 3: Configurar Git para el Repositorio
Configurá tu nombre de usuario y email para este repositorio específico:
git config user.name "Tu Nombre"
git config user.email "tu.email@ejemplo.com"
Paso 4: Inicializar un Nuevo Sitio Jekyll
-
Creá un nuevo sitio Jekyll en el directorio actual:
jekyll new . --force
-
Eliminá el archivo
index.markdown
predeterminado:rm index.markdown
-
Creá un nuevo archivo
index.md
con algo de contenido:echo "# Bienvenido a Mi Sitio Jekyll" > index.md echo "" >> index.md echo "Este es un nuevo sitio Jekyll creado para el tutorial." >> index.md
Paso 5: Commitear y Pushear Cambios
-
Stageá todos los cambios:
git add .
-
Commiteá los cambios:
git commit -m "Configuración inicial del sitio Jekyll"
-
Pusheá los cambios a GitHub:
git push origin main
Paso 6: Crear un Pull Request
-
Creá una nueva rama para tus cambios:
git checkout -b actualizar-homepage
-
Hacé un cambio en el archivo
index.md
:echo "" >> index.md echo "Esta línea fue agregada en una nueva rama." >> index.md
-
Commiteá y pusheá los cambios:
git add index.md git commit -m "Actualizar contenido de la página principal" git push origin actualizar-homepage
-
Creá un pull request usando GitHub CLI:
gh pr create --title "Actualizar página principal" --body "Agregada una nueva línea a la página principal."
Paso 7: Revisar y Mergear el Pull Request
-
Visualizá el pull request:
gh pr view
-
Aprobá y mergeá el pull request:
gh pr review --approve gh pr merge
TODO: Revisar proceso y metodología de revisión de pull request y review.
Es común para las primeras veces que rompamos el codigo en una rama, o combinemos mal las versiones, o un merge de código da conflictos y nos apuremos para resolverlo mientras estamos aprendiendo. Cuando el local está roto, puede surgir la tentación de clonar todo de cero nuevamente, soy culpable de hacerlo. Pero, si te pasa, te recomiendo usar un asistente de IA, explicando el contexto del repositorio, el problema y finalmente el error que nos está dando la terminal o VSCode. Después le decis qué querés hacer y te responde con los comandos para hacerlo.
Parte 2: Usando Visual Studio Code
Ahora vamos a pasar por el mismo proceso usando Visual Studio Code con la vista de Control de Código Fuente y la extensión de GitHub Pull Request.
-
Abrí Visual Studio Code y navegá a la vista “Control de código fuente” (Ctrl+Shift+G).
-
Si tenés VSCode abierto hacé clic en “Clonar repositorio” e ingresá la URL de tu repositorio de GitHub.
-
Una vez clonado, podés hacer cambios en tus archivos directamente en VSCode.
-
Para stagear cambios, hacé clic en el ícono “+” junto a los archivos modificados en la vista de Control de código fuente.
- Para commitear cambios, ingresá un mensaje de commit en el cuadro de texto y hacé clic en el ícono de tilde.
- Para pushear cambios, hacé clic en el menú “…” en la vista de Control de código fuente y seleccioná “Push”.
- Para crear una nueva rama, hacé clic en el nombre de la rama en la esquina inferior izquierda y seleccioná “Crear nueva rama”.
-
Después de hacer cambios en la nueva rama, pusheá la rama a GitHub.
-
En la extensión GitHub Pull Request (instalada desde el marketplace de VSCode), podés crear un nuevo pull request haciendo clic en el botón “Crear Pull Request”.
Aquí podemos ver los cambios realizados:
Hacemos el Pull Request:
- Revisá y mergeá el pull request directamente desde la extensión GitHub Pull Request en VSCode.
Forking, Branching y Pull Requests
Esta sección se enfoca en el proceso de contribuir a un sitio Jekyll existente a través de forking, branching y pull requests.
Prerrequisitos
Antes de comenzar, asegurate de tener:
- Git instalado en tu sistema.
- Una cuenta de GitHub.
- Visual Studio Code (VSCode) instalado.
- Acceso a una terminal Linux (Ubuntu o WSL).
Paso 1: Forkear el Repositorio
- Navegá a la página de GitHub del repositorio del sitio Jekyll al que querés contribuir.
- Hacé clic en el botón “Fork” en la esquina superior derecha de la página.
Te aparecerá un mensaje así:
- GitHub creará una copia del repositorio bajo tu cuenta.
Para esta parte del tutorial podes usar este repositorio de ejemplo en mi cuenta.
Paso 2: Clonar Tu Repositorio Forkeado
En este momento, vos hiciste un fork que es una copia de un repositorio propia dentro de tu cuenta. Todo lo que modifiques ahí, es exclusivamente tuyo. Ahora vamos a ver cómo es el flujo de trabajo normal para este caso de uso. Así se hace para trabajar en el desarrollo de software libre abierto colaborativo normalmente:
- En la página de GitHub de tu repositorio forkeado, hacé clic en el botón “Code” y copiá la URL HTTPS.
- Abrí tu terminal y navegá al directorio donde querés clonar el repositorio.
- Ejecutá el siguiente comando, reemplazando
<URL>
con la URL copiada:
git clone <URL>
- Cambiá al directorio recién creado:
cd <nombre-del-repositorio>
Paso 3: Configurar el Remoto Upstream
Para mantener tu fork actualizado con el repositorio original, agregalo como un remoto upstream:
git remote add upstream https://github.com/propietario-original/repositorio-original.git
Verificá el nuevo remoto:
git remote -v
Paso 4: Crear una Nueva Rama para Tu Feature
Creá y cambiá a una nueva rama para tu feature:
git checkout -b nombre-rama-feature
Paso 5: Hacer Cambios a Tu Sitio Jekyll
- Abrí el proyecto en Visual Studio Code:
code .
- Hacé los cambios necesarios a los archivos de tu sitio Jekyll.
- Guardá tus cambios.
Paso 6: Stagear y Commitear Tus Cambios
- Stageá tus cambios:
git add .
- Commiteá tus cambios con un mensaje descriptivo:
git commit -m "Agregar feature: descripción de tus cambios"
Paso 7: Pushear Tus Cambios a Tu Fork
Pusheá tu rama de feature a tu repositorio forkeado en GitHub:
git push origin nombre-rama-feature
Paso 8: Mergear Tu Rama de Feature
Si estás satisfecho con tus cambios y querés actualizar la rama principal de tu fork:
- Cambiá a la rama principal:
git checkout main
- Mergeá tu rama de feature:
git merge nombre-rama-feature
- Pusheá los cambios a la rama principal de tu fork:
git push origin main
Paso 9: Crear un Pull Request para el repo de otro
Para contribuir tus cambios de vuelta al repositorio original:
- Andá a la página de GitHub de tu fork.
- Hacé clic en “Pull requests” y luego en “New pull request”.
- Asegurate de que el repositorio base sea el repositorio original y el repositorio head sea tu fork.
- Seleccioná las ramas que querés comparar.
- Hacé clic en “Create pull request”.
- Agregá un título y descripción para tu pull request, explicando tus cambios. Todo esto se ve así:
- Hacé clic en “Create pull request” para enviar. Al enviarlo deberías ver algo así:
Conclusión
Esta guía completa ha cubierto los fundamentos de Git, el proceso de forkear y contribuir a repositorios existentes, y ha proporcionado un tutorial práctico para configurar y contribuir a un sitio Jekyll. Al dominar estos conceptos y técnicas, estarás bien equipado para colaborar efectivamente en sitios Jekyll y otros proyectos alojados en GitHub.
Recordá mantener tu fork actualizado con el repositorio upstream fetcheando y mergeando cambios regularmente:
git fetch upstream
git checkout main
git merge upstream/main
A medida que ganes experiencia, encontrarás que el control de versiones se convierte en una herramienta invaluable en tu kit de herramientas de desarrollo web. Practicá estos pasos regularmente para sentirte más cómodo con las operaciones de Git y GitHub, y no dudes en explorar características más avanzadas a medida que ganes confianza en tus habilidades.
Para más información sobre Git y GitHub, consultá la documentación oficial de Git y las Guías de GitHub.
Siempre sé cuidadoso cuando trabajés con comandos de Git, especialmente al pushear cambios a repositorios remotos o mergear ramas. Asegurate de entender las implicaciones de cada acción antes de proceder.