Luis Ampuero

Tutorial Completo de Git y GitHub: De Cero a Colaborador

Tutorial Interactivo de Git y GitHub

¡Bienvenido a este tutorial completo sobre Git y GitHub! Aprenderás los conceptos fundamentales y el flujo de trabajo esencial para gestionar tus proyectos de programación, colaborar con otros y mantener un historial organizado de tus cambios. Usaremos analogías y un proyecto de ejemplo llamado "RecetasWeb" para que todo sea más fácil de entender.

1. Introducción: Tus Herramientas Esenciales

Antes de sumergirnos en los comandos, entendamos qué son Git y GitHub y por qué son tan importantes.

a. ¿Qué es Git? El Guardián de Tus Versiones

Git es un sistema de control de versiones. Imagina que estás escribiendo un libro; Git te permite guardar diferentes versiones del mismo para no perder nada si cometes un error. Es como un cuaderno mágico que guarda todas las versiones de tu libro (código) y te permite volver a ellas si lo necesitas. Además, Git facilita que varias personas trabajen en el mismo proyecto sin pisarse los cambios.

b. ¿Qué es GitHub? Tu Biblioteca en la Nube

GitHub es una plataforma en línea que usa Git para almacenar proyectos (llamados "repositorios"). Es como una biblioteca gigante donde puedes guardar tu "libro" (el código de tu proyecto) y compartirlo con otros. GitHub también ofrece herramientas para colaborar en equipo, como los Pull Requests.

Analogía General: Piensa en Git como una caja fuerte personal donde guardas las versiones de tu libro, y en GitHub como una gran estantería pública (o privada) en la nube donde colocas esa caja fuerte para que tú y tus amigos puedan trabajar juntos en el libro.

2. Empezando un Nuevo Proyecto: "RecetasWeb"

Cuando inicias un nuevo proyecto, estás creando algo desde cero. Para mantener el código organizado y colaborar, usarás Git y GitHub. Vamos a imaginar que estás creando un sitio web sencillo para compartir recetas de cocina: "RecetasWeb".

Analogía: Es como empezar a escribir un libro de recetas desde cero. Necesitas un lugar para escribir (tu computadora), una forma de guardar versiones (Git), y una estantería en la nube para compartirlo (GitHub).

a. Paso 1: Planificación del Proyecto (¡Antes del Código!)

Antes de escribir una línea de código, ten una idea clara.

  • Qué hacer: Define el objetivo, herramientas (lenguajes, frameworks) y cómo organizarás los archivos.
  • Ejemplo (RecetasWeb):
    • Usar HTML y CSS.
    • Página principal (index.html) y estilos (styles.css).
    • Mostrar lista de recetas con nombres e ingredientes.

Analogía: Decidir que tu libro de recetas tendrá capítulos para desayunos y postres, y que usarás papel y lápiz.

b. Paso 2: Configuración de Tu Entorno Local e Instalación de Git

Prepara tu computadora.

  • Qué hacer:
    1. Crea una carpeta para tu proyecto.
    2. Instala Git si aún no lo tienes.
    3. Instala un editor de código (ej. Visual Studio Code).
  • Instalación de Git:

    Windows:

    La forma más sencilla es descargar el instalador oficial desde git-scm.com/download/win y seguir las instrucciones. Esto también instalará Git Bash, una terminal que te permitirá usar los comandos de Git como se muestran en este tutorial.

    Linux (Debian/Ubuntu):

    Abre una terminal y ejecuta:

    sudo apt update
sudo apt install git

    Linux (Fedora/CentOS/RHEL):

    Abre una terminal y ejecuta:

    sudo yum install git  # Para versiones más antiguas de Fedora/CentOS/RHEL
sudo dnf install git  # Para versiones más nuevas de Fedora

    macOS:

    Git suele venir preinstalado. Puedes verificarlo abriendo la Terminal y escribiendo git --version. Si no está, puedes instalarlo con Homebrew:

    /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)" # Si no tienes Homebrew
brew install git

    También puedes instalarlo descargando el instalador desde git-scm.com/download/mac.

  • Ejemplo de creación de carpeta:

    Crea una carpeta RecetasWeb.

    Abre la terminal y navega a esa carpeta:

    mkdir RecetasWeb
cd RecetasWeb

Analogía: Preparar tu escritorio: una carpeta nueva para tu libro, tus herramientas (Git, editor) listas y afiladas.

c. Paso 3: Inicializar un Repositorio Git Local

Aquí Git entra en acción.

  • Qué hacer:
    1. Inicializa un repositorio Git en tu carpeta. Esto crea el "cuaderno mágico" (.git/) para el historial.
    2. Crea un archivo inicial, como README.md, para describir tu proyecto.
  • Código:

    Inicializa el repositorio:

    git init

    Esto crea una carpeta oculta .git donde se guarda el historial.

    Crea un README.md:

    echo "# RecetasWeb" > README.md
echo "Un sitio web para compartir recetas de cocina." >> README.md

    Agrega el archivo a Git y haz tu primer "guardado" (commit):

    git add README.md
git commit -m "Primer commit: agregar README"

Analogía: git init es como poner una etiqueta "Versión 1" a tu libro. El commit es tomar una foto de esa primera página.

d. Paso 4: Crear los Archivos Iniciales del Proyecto

Empieza a escribir el código.

  • Qué hacer:
    1. Crea los archivos principales (ej. index.html, styles.css).
    2. Agrega contenido inicial.
    3. Guarda los cambios con Git (add y commit).
  • Ejemplo:

    Crea index.html:

    <!DOCTYPE html>
<html lang="es">
<head>
    <meta charset="UTF-8">
    <title>Recetas Deliciosas</title>
    <link rel="stylesheet" href="styles.css">
</head>
<body>
    <h1>Bienvenidos a Recetas Deliciosas</h1>
    <h2>Receta de Pizza</h2>
    <p>Ingredientes: harina, queso, tomate...</p>
</body>
</html>

    Crea styles.css:

    /* styles.css */
body {
    font-family: Arial, sans-serif;
    background-color: #f0f0f0;
}
h1 {
    color: #333;
}

    Agrega y haz commit:

    git add index.html styles.css
git commit -m "Agregar página principal y estilos iniciales"

Analogía: Escribir las primeras páginas: portada (index.html) y diseño (styles.css). Tomas otra foto (commit) para guardar esta versión.

e. Paso 5: Crear un Repositorio en GitHub y Conectar

Sube tu proyecto a la nube para almacenarlo y colaborar.

  • Qué hacer:
    1. Ve a GitHub y crea un nuevo repositorio (ej. RecetasWeb). No inicialices con un README si ya tienes uno local.
    2. Conecta tu repositorio local con el de GitHub.
    3. Sube tus archivos.
  • Ejemplo (comandos después de crear el repo en GitHub):

    GitHub te dará instrucciones similares a estas:

    git remote add origin https://github.com/tu-usuario/RecetasWeb.git
git branch -M main  # Renombra la rama actual a 'main' si es necesario
git push -u origin main # Sube tu rama 'main' a GitHub

    Reemplaza tu-usuario con tu nombre de usuario real de GitHub.

Analogía: Llevar tu libro a la biblioteca (GitHub) y colocarlo en una estantería. El URL es la dirección de esa estantería.

f. Autenticación con Git y GitHub

Cuando interactúas con repositorios remotos en GitHub (por ejemplo, al hacer git push o git pull desde un repositorio privado, o al empujar a cualquier repositorio), necesitas autenticarte para demostrar que tienes permiso para realizar esas acciones. Hay dos métodos principales de autenticación con GitHub:

1. HTTPS con Personal Access Token (PAT)

Este es el método recomendado para la autenticación HTTPS en la línea de comandos.

  • ¿Qué es? Un PAT es una cadena de caracteres alfanuméricos que funciona como una contraseña alternativa para GitHub. Puedes crear PATs con permisos específicos (scopes) para limitar lo que se puede hacer con ellos.
  • ¿Por qué usar PATs en lugar de tu contraseña? GitHub ha deprecado el uso de contraseñas para la autenticación de Git en la línea de comandos por razones de seguridad. Los PATs son más seguros porque:
    • Son únicos para cada aplicación o uso.
    • Pueden ser revocados individualmente.
    • Pueden tener permisos limitados (por ejemplo, solo para leer repositorios o solo para escribir en ellos).
  • ¿Cómo usarlo?
    1. Genera un PAT en GitHub: Ve a tu perfil de GitHub → Settings → Developer settings → Personal access tokens → Tokens (classic) → Generate new token. Dale un nombre descriptivo, selecciona los scopes necesarios (para clonar, empujar, etc., el scope repo es común) y genera el token. ¡Copia el token inmediatamente! No podrás volver a verlo.
    2. Uso en la línea de comandos: Cuando Git te pida tu contraseña al interactuar con GitHub vía HTTPS, ingresa tu PAT en lugar de tu contraseña de GitHub. 
      git clone https://github.com/tu-usuario/tu-repositorio.git
# Username for 'https://github.com': tu-usuario
# Password for 'https://tu-usuario@github.com': [PEGA AQUÍ TU PERSONAL ACCESS TOKEN]
    3. Gestores de Credenciales: Para no tener que ingresar el PAT cada vez, puedes usar un gestor de credenciales de Git (Git Credential Manager), que suele estar configurado por defecto con las instalaciones modernas de Git. Este almacenará tu PAT de forma segura después de la primera vez que lo ingreses.

2. SSH (Secure Shell)

Este método utiliza un par de claves criptográficas: una clave pública que agregas a tu cuenta de GitHub y una clave privada que permanece segura en tu computadora.

  • ¿Cómo funciona? Cuando intentas conectarte a GitHub usando SSH, Git usa tu clave privada para "firmar" la conexión. GitHub luego verifica esta firma usando la clave pública correspondiente que tiene almacenada.
  • Ventajas:
    • No necesitas ingresar tu nombre de usuario o PAT cada vez que te conectas.
    • Considerado muy seguro si tu clave privada está protegida (idealmente con una frase de contraseña).
  • ¿Cómo configurarlo?
    1. Verifica claves SSH existentes: 
      ls -al ~/.ssh

      Busca archivos como id_rsa.pub, id_ecdsa.pub, o id_ed25519.pub.

    2. Genera una nueva clave SSH (si no tienes una o quieres una nueva):

      Se recomienda Ed25519:

      ssh-keygen -t ed25519 -C "tu_email@ejemplo.com"

      Cuando te pregunte "Enter a file in which to save the key", puedes presionar Enter para aceptar la ubicación por defecto. Es altamente recomendable establecer una frase de contraseña (passphrase) segura para tu clave SSH.

    3. Agrega tu clave SSH al ssh-agent: 
      eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519 # O el nombre de tu archivo de clave privada
    4. Agrega tu clave pública SSH a tu cuenta de GitHub:

      Copia el contenido de tu archivo de clave pública. Por ejemplo, si usaste Ed25519:

      cat ~/.ssh/id_ed25519.pub

      Copia toda la salida (que empieza con ssh-ed25519... y termina con tu email).

      Ve a tu perfil de GitHub → Settings → SSH and GPG keys → New SSH key. Dale un título y pega tu clave pública en el campo "Key".

    5. Prueba tu conexión SSH: 
      ssh -T git@github.com

      Deberías ver un mensaje como: "Hi tu-usuario! You've successfully authenticated, but GitHub does not provide shell access."

    6. Clonar y empujar con SSH: Cuando clones un repositorio, usa la URL SSH en lugar de la HTTPS. La encontrarás en GitHub en el botón "Code". Se verá algo así: git@github.com:tu-usuario/tu-repositorio.git. 
      git clone git@github.com:tu-usuario/tu-repositorio.git

Elegir entre HTTPS (con PAT) y SSH es a menudo una preferencia personal. SSH es popular entre desarrolladores por su conveniencia una vez configurado. Los PATs son flexibles y más fáciles de empezar a usar para interacciones HTTPS.

3. Flujo de Trabajo Esencial: Ramas y Pull Requests

Ahora que tu proyecto está en Git y GitHub, veamos cómo trabajar de forma organizada, especialmente en equipo.

a. Ramas (Branches): Tu Espacio de Trabajo Aislado

Una rama es una copia del proyecto donde puedes hacer cambios sin afectar la versión principal (generalmente main o master). Git te permite crear tantas ramas como necesites.

  • Contexto: Cuando vas a añadir una nueva función o corregir un error, creas una rama nueva para ese cambio específico.
  • Comandos:

    Para crear una nueva rama y cambiar a ella:

    git checkout -b nombre-de-tu-rama

    (Ej: git checkout -b nueva-receta-pastel)

    Para cambiar a una rama existente:

    git checkout nombre-de-rama-existente

Analogía: Una rama es como una copia de tu libro de recetas en la que puedes escribir borradores sin arruinar el libro original. La rama main es el libro oficial publicado.

b. Commits: Guardando Tu Progreso

Un commit es como un "punto de guardado" de los cambios que hiciste en tu código dentro de una rama. Cada commit tiene un mensaje que describe qué cambiaste.

  • Contexto: Antes de proponer tus cambios (con un Pull Request), haces varios commits en tu rama para guardar tu progreso de forma granular.
  • Buenas Prácticas para Commits:
    • Haz commits pequeños y específicos. (Ej: "Agregué ingredientes de la pizza" en lugar de "Hice muchos cambios").
    • Escribe mensajes de commit claros y descriptivos.

Analogía: Un commit es como tomar una foto de una página de tu libro de recetas después de escribir algo nuevo, para no perder ese progreso.

c. Pull Requests (PRs): Proponiendo Tus Cambios para Integración

Un Pull Request (PR) es una solicitud formal que haces en GitHub (o plataformas similares) para que los cambios que hiciste en tu rama sean incorporados (mezclados o "mergeados") a otra rama, usualmente la rama principal (main).

  • Contexto: Esencial para el trabajo en equipo. En lugar de que todos escriban directamente en el "libro principal" (main), cada persona hace cambios en una copia (rama) y luego pide permiso (un PR) para agregar esos cambios al libro principal.
  • Proceso Básico de un PR:
    1. Haces cambios en una copia (rama) de tu proyecto.
    2. Subes esos cambios (tu rama con sus commits) a GitHub (git push origin nombre-de-tu-rama).
    3. En GitHub, creas un Pull Request desde tu rama hacia la rama main.
    4. Tus compañeros revisan el PR, dan retroalimentación (revisión de código).
    5. Si todo está bien, aprueban y mezclan (merge) tus cambios en main.

Analogía: Creas una nueva receta de pastel en tu borrador (rama). Un PR es como decir a tus compañeros: "¡Oigan, hice esta nueva receta de pastel! ¿La revisan y, si les gusta, la agregamos al libro principal?".

d. Términos Clave Relacionados con Pull Requests:

  • Repositorio (Repository): El lugar donde se guarda todo el proyecto (código, archivos, historial). En GitHub, es como una carpeta grande para tu proyecto. Los PRs se crean dentro de un repositorio.

    Analogía: La estantería completa donde guardas tu libro de recetas.

  • Merge (Mezclar): El acto de combinar los cambios de una rama con otra (generalmente main). Un PR aprobado termina con un merge.

    Analogía: Pegar oficialmente tu nueva receta de pizza en el libro principal después de que todos la aprobaron.

  • Revisión de Código (Code Review): Proceso donde otros revisan los cambios en tu PR. Pueden dejar comentarios, sugerir mejoras o aprobar.

    Analogía: Tus amigos prueban tu receta de pizza y te dicen si está rica o necesita ajustes antes de publicarla.

  • Conflictos (Merge Conflicts): Ocurren cuando Git no puede combinar automáticamente cambios hechos por diferentes personas en la misma parte de un archivo. Debes resolverlos manualmente antes del merge.

    Ejemplo: Tú cambiaste una línea para usar queso mozzarella, y un compañero cambió la misma línea para usar queso cheddar. Git no sabe cuál elegir.

    Analogía: Dos chefs intentan agregar ingredientes diferentes a la misma receta al mismo tiempo. Deben decidir juntos qué ingrediente usar.

  • Fork (Bifurcar): Una copia completa de un repositorio de otra persona en tu propia cuenta de GitHub. Útil si no tienes permisos para modificar directamente un repositorio (ej. un proyecto de código abierto). Haces un fork, trabajas en tu copia y luego creas un PR desde tu fork al repositorio original.

    Analogía: Hacer una fotocopia del libro de recetas de alguien más para trabajar en tu propia versión, y luego pedirles que incluyan tus cambios en su libro original.

e. ¿Cómo se Autoriza un Cambio en la Rama Principal (main)?

Normalmente, la rama main está protegida. Los cambios se autorizan a través del proceso de Pull Request:

  1. Crear una rama para los cambios (ej. nueva-receta-sopa).
  2. Hacer los cambios y commits en esa rama.
  3. Subir la rama a GitHub (git push origin nueva-receta-sopa).
  4. Crear un Pull Request en GitHub desde nueva-receta-sopa hacia main.
  5. Revisión y Aprobación: Compañeros (o tú mismo si trabajas solo) revisan el código. Pueden solicitar cambios. Una vez aprobado...
  6. Hacer el Merge: Un encargado (o tú) hace clic en "Merge pull request" en GitHub. ¡Tus cambios ahora están en main!

Protección de Ramas (Opcional pero Recomendado): En GitHub, puedes configurar "Branch protection rules" para main. Esto puede exigir que todos los cambios pasen por un PR y que al menos una persona apruebe antes del merge.

4. Estructura de Archivos del Proyecto: Local y en GitHub

Una buena organización de carpetas es clave.

Analogía: Es el índice de tu libro de recetas. Si está bien organizado, encuentras todo fácilmente.

a. Estructura Local Inicial (Proyecto RecetasWeb)

Después de git init y crear los primeros archivos:

RecetasWeb/
├── .git/           # Carpeta oculta de Git (¡no la toques manualmente!)
├── index.html      # Página principal
├── styles.css      # Archivo de estilos
└── README.md       # Descripción del proyecto

b. Estructura Local Más Completa (Recomendada)

A medida que el proyecto crece:

RecetasWeb/
├── .git/
├── .github/                  # Carpeta para configuraciones de GitHub (ej. Actions)
│   └── workflows/            # Subcarpeta para GitHub Actions
│       └── check.yml         # Archivo para automatizar revisiones
├── assets/                   # Carpeta para recursos estáticos (imágenes, fuentes)
│   ├── images/               # Subcarpeta para imágenes
│   │   └── pizza.jpg
│   └── fonts/                # Subcarpeta para fuentes
├── pages/                    # Carpeta para páginas adicionales
│   └── receta-sopa.html
├── src/                      # Opcional: para código fuente si el proyecto es más complejo (ej. JavaScript)
├── tests/                    # Opcional: para pruebas automatizadas
├── index.html
├── styles.css                # Podría estar en assets/css/ o src/styles/ en proyectos más grandes
├── README.md
└── .gitignore                # Archivo para listar archivos/carpetas a ignorar por Git

Contenido de .gitignore (ejemplo):

# .gitignore
*.log                   # Ignora archivos de log
node_modules/           # Ignora dependencias de Node.js (si usas)
.DS_Store               # Ignora archivos de macOS
.vscode/                # Ignora configuraciones del editor VSCode

Analogía (.gitignore): Una lista de cosas que no quieres llevar a la biblioteca (papeles sucios, borradores temporales).

c. Estructura en GitHub

Es un espejo de tu estructura local (lo que subes con git push), pero .git/ no se muestra. GitHub puede tener carpetas especiales como .github/workflows/ para GitHub Actions.

d. ¿Por Qué esta Estructura?

  1. Organización: Facilita navegar y encontrar archivos.
  2. Escalabilidad: Permite que el proyecto crezca ordenadamente.
  3. Colaboración: Un estándar ayuda a que todos entiendan dónde están las cosas.
  4. Automatización: Herramientas como GitHub Actions esperan ciertas carpetas.
  5. Mantenimiento: .gitignore mantiene limpio el repositorio.

Analogía Final (Estructura de Carpetas): Es como la organización de una cocina. Los ingredientes (archivos) están en cajones específicos: harina en assets/, recetas en pages/. Si todo tiene su lugar, cocinar (desarrollar) es más fácil.

e. Referenciando Archivos en HTML (Rutas Relativas)

Cuando tu index.html necesita cargar styles.css o una imagen de assets/images/pizza.jpg, debes usar rutas relativas.

  • ¿Qué es una ruta relativa? Describe la ubicación de un archivo en relación con el archivo actual (ej. index.html).
  • ¿Por qué usarlas?
    • Portabilidad: Funcionan igual localmente y en un servidor (GitHub Pages).
    • Mantenimiento: No necesitas cambiar rutas si mueves el proyecto o cambia el dominio.
  • Reglas Básicas:
    • nombre-archivo.ext: Archivo en la misma carpeta. (ej. styles.css si está al lado de index.html).
    • nombre-carpeta/nombre-archivo.ext: Archivo dentro de una subcarpeta. (ej. assets/images/pizza.jpg).
    • ../nombre-archivo.ext: Archivo en la carpeta padre (subir un nivel).
  • Ejemplo en index.html (asumiendo que index.html y styles.css están en la raíz, e images dentro de assets): 
    <!DOCTYPE html>
<html lang="es">
<head>
    <meta charset="UTF-8">
    <title>Recetas Deliciosas</title>
    <!-- Vincular el archivo CSS -->
    <link rel="stylesheet" href="styles.css">
</head>
<body>
    <h1>Bienvenidos a Recetas Deliciosas</h1>
    <h2>Receta de Pizza</h2>
    <!-- Vincular una imagen -->
    <img src="assets/images/pizza.jpg" alt="Foto de una pizza">
    <!-- Vincular otra página -->
    <a href="pages/receta-sopa.html">Ver receta de sopa</a>
</body>
</html>

Analogía (Rutas Relativas): Estás en la sala (index.html). Para el CSS en la misma sala, solo dices "toma styles.css". Para la imagen, dices "ve al cajón assets/, luego al subcajón images/, y toma pizza.jpg".

5. Herramientas: ¿Terminal (Bash) o IDE?

a. ¿Por Qué bash en los Comandos de Ejemplo?

Bash (Bourne Again Shell) es un lenguaje de comandos que se ejecuta en una terminal.

  • Universalidad: Es una forma directa de interactuar con Git en la mayoría de sistemas operativos (Linux, macOS, Windows con Git Bash).
  • Consistencia: Los comandos son los mismos.
  • Educativo: Entiendes profundamente cómo funciona Git.

Analogía: Bash es el idioma que hablas para darle instrucciones a tu asistente (Git).

b. ¿Es Necesario Usar la Terminal? ¿O Puedo Usar un IDE?

No, no es estrictamente necesario.

  • IDEs (Entornos de Desarrollo Integrado): Muchos IDEs modernos (Visual Studio Code, IntelliJ IDEA, PyCharm) tienen integración con Git. Puedes hacer commits, crear ramas, etc., desde una interfaz gráfica.

    Ejemplo (VS Code): Puedes inicializar Git, hacer commits, cambiar ramas y subir cambios usando la pestaña de Git y botones.

  • Ventajas del IDE: Más visual, menos errores de tipeo, todo en un lugar.
  • Desventajas del IDE: Menos control en operaciones avanzadas, dependencia del IDE.
  • Recomendación: Aprende lo básico en la terminal para entender Git, luego usa un IDE por comodidad si lo prefieres. Muchos desarrolladores usan una mezcla de ambos.

Analogía (Terminal vs IDE): Usar la terminal es como cocinar siguiendo instrucciones exactas con tus manos (control total). Usar un IDE es como un robot de cocina: hace el trabajo con botones, pero a veces con menos flexibilidad para detalles finos.

6. Otros Comandos y Conceptos Útiles de Git

  • git clone <URL_del_repositorio>: Si quieres trabajar en un proyecto existente en GitHub, primero lo clonas (descargas una copia) a tu máquina.

    Ejemplo: git clone https://github.com/tu-usuario/RecetasWeb.git

    Analogía: Pedir una copia del libro de recetas de la biblioteca para trabajar en tu casa.

  • git status: Muestra el estado de tus archivos (cuáles están modificados, cuáles listos para commit, etc.). ¡Úsalo frecuentemente!
  • git pull origin nombre-rama: Actualiza tu rama local con los cambios de la rama remota correspondiente en GitHub. Esencial antes de empezar a trabajar para tener la última versión.
  • git log: Muestra el historial de commits de la rama actual.

    Analogía: Revisar un álbum de fotos de todas las versiones de tu libro.

  • Deshacer Cambios:
    • git restore <archivo>: Descarta cambios en un archivo que aún no has añadido al "staging area".
    • git restore --staged <archivo>: Saca un archivo del "staging area" (deshace git add <archivo>).
    • git reset HEAD^: Deshace el último commit (manteniendo los cambios en tus archivos para que puedas rehacer el commit). (¡Con cuidado con reset!).
  • GitHub Actions: Permite automatizar tareas en tu repositorio de GitHub, como ejecutar pruebas cada vez que se crea un PR. Se configuran con archivos .yml en la carpeta .github/workflows/.

    Analogía: Un asistente que revisa automáticamente tu receta cada vez que la actualizas.

7. Buenas Prácticas Adicionales

  • Nombres de Ramas Descriptivos: nueva-receta-sopa es mejor que rama1.
  • Actualiza con Frecuencia: Haz git pull regularmente si colaboras para evitar conflictos grandes.
  • Documentación: Mantén tu README.md actualizado con información sobre el proyecto, cómo ejecutarlo y cómo contribuir.

8. Conclusión: ¡A Practicar!

Este tutorial te ha dado una base sólida. La clave ahora es practicar:

  1. Crea tus propios proyectos.
  2. Usa Git para cada cambio.
  3. Súbelos a GitHub.
  4. Intenta colaborar con alguien o contribuye a proyectos de código abierto (empezando con un fork).

Analogía Final General: Iniciar un proyecto es como empezar un libro de recetas. Planificas (decides recetas), preparas tu escritorio (entorno), escribes y guardas versiones (Git), lo compartes en una biblioteca (GitHub), y estableces reglas para que otros chefs te ayuden (flujo con Pull Requests). Los Pull Requests son el filtro de calidad: antes de agregar una nueva receta al libro principal, todos la revisan. Así, el libro siempre está en buen estado.

¡No tengas miedo de experimentar! Git es poderoso y te permite retroceder si algo sale mal.

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *