Git: fundamentos, ramas y claves SSH múltiples

1. ¿Qué es Git?

Git es un sistema de control de versiones distribuido que permite rastrear los cambios en archivos y coordinar el trabajo entre múltiples personas en un proyecto de desarrollo de software. Fue creado por Linus Torvalds en 2005 para el desarrollo del kernel de Linux y se ha convertido en el estándar de facto para el control de versiones en la industria del software.

5 pilares importantes

Después de años usando Git, puedo decir que es mucho más que un simple sistema de control de versiones:

1. Historial. Te dice qué cambió, cuándo cambió, por qué cambió y quién lo cambió. Si tienes dudas sobre alguna modificación, sabes exactamente a quién consultar.
2. Botón de deshacer. Cuando algo se rompe en producción, siempre puedes volver a un último release estable mientras sigues trabajando en las mejoras necesarias.
3. Comunicación entre desarrolladores. Cada commit y Pull Request es un mensaje para tu equipo, donde explicas en qué estás trabajando, qué probaste y qué resolviste.
4. Trazabilidad para la mejora continua. Si sabes cuándo y cómo se rompió algo, puedes escribir tests para prevenir que vuelva a ocurrir.
5. Colaboración segura y sin miedo. Permite a cada desarrollador trabajar en su propia rama sin afectar el código de otros, brindando libertad para experimentar.

Git no es solo un control de versiones, sino lo que te permite pasar de un montón de archivos que solo funcionan en tu computadora a toda una aplicación desplegada en producción, robusta y mantenible a lo largo del tiempo.

2. Conceptos fundamentales

Repositorios

Un repositorio (o "repo") es el contenedor principal donde Git almacena todo el historial de tu proyecto. Contiene todos los archivos, carpetas y el historial completo de cambios. Puede ser local (en tu computadora) o remoto (en servicios como GitHub, GitLab o Bitbucket).

Existen dos tipos principales:

• Repositorio local: está en tu máquina y contiene tu copia de trabajo del proyecto.
• Repositorio remoto: está alojado en un servidor y permite la colaboración entre múltiples desarrolladores.

Commits

Un commit es una "fotografía" del estado de tu proyecto en un momento específico. Cada commit registra qué archivos cambiaron, quién hizo los cambios, cuándo se hicieron y por qué (mediante el mensaje de commit).

Los commits forman una línea de tiempo de tu proyecto, permitiéndote:

• Ver exactamente qué cambió en cada punto del historial.
• Volver a estados anteriores si algo sale mal.
• Entender la evolución del código a lo largo del tiempo.

Cada commit tiene un identificador único (hash SHA) y apunta al commit anterior, creando una cadena de historial.

Ramas (branches)

Las ramas son líneas independientes de desarrollo que te permiten trabajar en nuevas características, correcciones de errores o experimentos sin afectar el código principal del proyecto.

La rama principal suele llamarse main o master, y representa el código estable. Cuando quieres trabajar en algo nuevo, creas una rama separada, haces tus cambios allí, y luego la fusionas (merge) de vuelta a la rama principal cuando está lista.

Beneficios de las ramas:

• Permiten el trabajo paralelo de múltiples desarrolladores.
• Aíslan cambios experimentales del código estable.
• Facilitan la organización de features y fixes.
• Hacen más sencilla la revisión de código antes de integrarlo.

Áreas de Git: working directory, staging area, repository

Git organiza tu flujo de trabajo en tres áreas principales:

• Working Directory (directorio de trabajo): es donde editas y modificas tus archivos. Estos cambios aún no están siendo rastreados por Git hasta que los agregues al staging area.
• Staging Area (área de preparación): es un área intermedia donde colocas los cambios que quieres incluir en tu próximo commit. Usar git add mueve archivos modificados aquí. Esto te permite seleccionar específicamente qué cambios quieres confirmar.
• Repository (repositorio): es donde Git almacena permanentemente los commits confirmados. Cuando haces git commit, los cambios del staging area se guardan en el repositorio con un mensaje descriptivo y se convierten en parte del historial oficial del proyecto.

Este flujo de tres pasos te da control total sobre qué cambios incluir en cada commit, permitiéndote crear un historial limpio y organizado.

3. Gestión de múltiples cuentas SSH (GitHub, Bitbucket, etc.)

Esta guía te ayuda a configurar tu Mac para que use la clave SSH correcta automáticamente según el repositorio en el que estés trabajando, ideal para separar tus cuentas personales y del trabajo.

Objetivo

La idea es crear alias en la configuración de SSH. En lugar de usar git@github.com para todo, usaremos alias como git@github.com-personal y git@github.com-work. Cada alias apuntará a una clave SSH específica.

Paso 1: identifica tus claves SSH

Primero, asegúrate de saber dónde están tus claves. Generalmente, se encuentran en la carpeta oculta .ssh de tu directorio de usuario.

Comando para listar tus claves:

ls -alh ~/.ssh

Vas a ver archivos como id_rsa, id_ed25519, y las que hayas creado, por ejemplo:

• id_rsa_personal_github
• id_rsa_work_github
• id_rsa_personal_bitbucket
• id_rsa_work_bitbucket

Paso 2: crea y configura el archivo config

Aquí es donde ocurre la magia. Crearemos un archivo de configuración para decirle a SSH qué clave usar con cada alias.

Abre el archivo de configuración en el editor nano (si el archivo no existe, este comando lo creará):

nano ~/.ssh/config

Pega la siguiente plantilla y adáptala con los nombres exactos de tus archivos de clave:

# === GitHub Personal ===
Host github.com-personal
    HostName github.com
    User git
    IdentityFile ~/.ssh/id_rsa_personal_github
    IdentitiesOnly yes

# === GitHub Trabajo ===
Host github.com-work
    HostName github.com
    User git
    IdentityFile ~/.ssh/id_rsa_work_github
    IdentitiesOnly yes

# === Bitbucket Personal ===
Host bitbucket.org-personal
    HostName bitbucket.org
    User git
    IdentityFile ~/.ssh/id_rsa_personal_bitbucket
    IdentitiesOnly yes

# === Bitbucket Trabajo ===
Host bitbucket.org-work
    HostName bitbucket.org
    User git
    IdentityFile ~/.ssh/id_rsa_work_bitbucket
    IdentitiesOnly yes

Explicación rápida: Host es el alias que tú inventas. HostName es el servidor real (ej. github.com). IdentityFile es la ruta a la clave SSH que se usará para ese alias. IdentitiesOnly yes fuerza a SSH a usar solo la clave especificada.

Guarda y cierra el archivo: presiona Ctrl + O y luego Enter para guardar, y Ctrl + X para salir de nano.

Paso 3: añade las claves al agente SSH

Para evitar que macOS te pida la contraseña de la clave a cada rato, añádelas al agente SSH. Ejecuta estos comandos en la Terminal, uno por cada clave:

ssh-add -K ~/.ssh/id_rsa_personal_github
ssh-add -K ~/.ssh/id_rsa_work_github
ssh-add -K ~/.ssh/id_rsa_personal_bitbucket
ssh-add -K ~/.ssh/id_rsa_work_bitbucket

El flag -K guarda la contraseña en el Llavero de macOS.

Paso 4: usa los nuevos alias en Git

Ahora solo tienes que usar los alias que creaste en lugar de la URL original.

Para repositorios nuevos (git clone): simplemente modifica la URL de clonación, cambiando github.com por tu alias.

• Ejemplo personal (GitHub): en vez de git@github.com:tu-usuario/repo-personal.git, usa git clone git@github.com-personal:tu-usuario/repo-personal.git.
• Ejemplo trabajo (GitHub): en vez de git@github.com:empresa/repo-trabajo.git, usa git clone git@github.com-work:empresa/repo-trabajo.git.

Para repositorios existentes (git remote set-url): si ya tienes los repositorios clonados, solo necesitas actualizar la URL del remoto.

1. Navega a la carpeta de tu proyecto: cd ruta/a/tu/repositorio.
2. Verifica la URL actual: git remote -v.
3. Actualiza la URL con el alias correcto:
   • Para un repo personal de GitHub: git remote set-url origin git@github.com-personal:tu-usuario/repo.git
   • Para un repo de trabajo de Bitbucket: git remote set-url origin git@bitbucket.org-work:empresa/repo-trabajo.git

A partir de ahora, cada vez que hagas git pull, git push, etc., Git usará automáticamente la clave SSH correcta según la configuración del remoto de esa carpeta.

4. Plantilla de README.md

Tener un README.md completo y funcional es una de las buenas prácticas más importantes en cualquier repositorio: es la primera impresión de tu proyecto. Esta es una plantilla que podés reutilizar:

# Nombre del Proyecto

## Descripción
Breve descripción de lo que hace el proyecto y su propósito.

## Características principales
- Característica 1
- Característica 2
- Característica 3

## Instalación
```bash
# Ejemplo de comandos de instalación
git clone https://github.com/usuario/proyecto.git
cd proyecto
npm install # o pip install -r requirements.txt

Configuración

Describe cualquier configuración necesaria, como variables de entorno:

API_KEY=tu_clave_api
DB_CONNECTION=mysql://user:password@localhost/db

Uso

# Ejemplo de cómo ejecutar el proyecto
npm start # o python main.py

Estructura del proyecto

/src            # Código fuente
/tests          # Tests
/docs           # Documentación
/config         # Archivos de configuración

Dependencias principales

• Dependencia 1 - Breve descripción
• Dependencia 2 - Breve descripción

Contribución

Instrucciones para contribuir al proyecto:

1. Haz fork del repositorio
2. Crea una rama para tu feature (git checkout -b feature/amazing-feature)
3. Haz commit de tus cambios (git commit -m 'feat: añade nueva funcionalidad')
4. Haz push a la rama (git push origin feature/amazing-feature)
5. Abre un Pull Request

Licencia

MIT o la licencia que corresponda.

Contacto

• Nombre - @twitter_handle
• Email - email@example.com
• Link del proyecto: https://github.com/usuario/proyecto

## 5. Convenciones para mensajes de commit

Escribir mensajes de commit claros y descriptivos facilita el historial y la colaboración. Las convenciones más usadas son:

- **feat:** nueva funcionalidad.
- **fix:** corrección de errores.
- **docs:** cambios en documentación.
- **style:** cambios que no afectan al código (formato, espacios, etc.).
- **refactor:** refactorización del código.
- **test:** añadir o corregir tests.
- **chore:** tareas de mantenimiento (configuración, dependencias, etc.).

Buenos ejemplos:

- `feat(auth): implementa autenticación con Google`
- `fix(login): corrige validación de contraseñas`
- `docs(readme): actualiza instrucciones de instalación`

Otras buenas prácticas para mantener un repo saludable:

- Revisar los cambios antes de hacer commit (usar `git status`, `git diff` y `git add`).
- Usar `.gitignore` para no subir archivos sensibles (contraseñas, claves API), dependencias (`node_modules`, `vendor`, etc.) ni archivos de build o compilados (`dist`, `build`, `target`, etc.).
- Mantener commits pequeños y enfocados en un solo cambio, sincronizando regularmente con el repositorio remoto.