Skip to content

07-ramas.md

Latest commit

 

History

History
241 lines (165 loc) · 6.23 KB

07-ramas.md

File metadata and controls

241 lines (165 loc) · 6.23 KB

Curso: Dominando Git y la Conexión con la Nube

Introducción

Hasta ahora todos los commits han ido al mismo sitio: la rama main. Eso funciona cuando trabajas solo en algo pequeño, pero en cuanto el proyecto crece o hay más de una persona, trabajar directamente sobre main se vuelve un problema.

Para eso existen las ramas. Y una vez que las entiendes, cambia completamente la forma en que trabajas con Git.

Punto de partida

Vamos a trabajar sobre mi-proyecto, el repositorio que creamos al principio del curso con index.html e index.js. Entramos en la carpeta y comprobamos el historial:

cd mi-proyecto
git log --oneline
7d9e0f1 (HEAD -> main, origin/main) primer commit

¿Qué es una rama?

Imagina que estás escribiendo un documento y en un momento dado quieres probar un cambio grande sin tocar el original. Lo que harías es guardar una copia, trabajar en ella, y si sale bien, reemplazas el original. Si sale mal, tiras la copia y el original sigue intacto.

Una rama en Git hace exactamente eso, pero sin duplicar ficheros ni carpetas. Internamente Git solo lleva la cuenta de qué commits pertenecen a cada línea de desarrollo. Es instantáneo y casi no ocupa espacio.

Lo importante es el concepto: los cambios que haces en una rama no afectan a main hasta que tú decidas unirlas.

Ver las ramas

Para ver qué ramas existen en el repositorio:

git branch
* main

El asterisco indica en qué rama estamos. De momento solo tenemos main.

Crear una rama y moverse a ella

Vamos a añadir estilos al proyecto. En vez de hacerlo directamente en main, abrimos una rama para ese trabajo:

git switch -c feature/estilos
Switched to a new branch 'feature/estilos'

Con -c creamos la rama y nos movemos a ella en un solo paso. Si volvemos a mirar las ramas:

git branch
* feature/estilos
  main

main sigue exactamente donde estaba. A partir de ahora, los commits que hagamos irán a feature/estilos.

Trabajar en la rama

Creamos el fichero style.css:

style.css

body {
  font-family: sans-serif;
  margin: 2rem;
  background-color: #f5f5f5;
}

Y enlazamos la hoja de estilos desde index.html, añadiendo la línea del link en el <head>:

index.html

<!DOCTYPE html>
<html lang="es">
  <head>
    <meta charset="UTF-8" />
    <title>Mi proyecto</title>
+    <link rel="stylesheet" href="style.css" />
  </head>
  <body>
    <script src="index.js"></script>
  </body>
</html>

Comprobamos el estado:

git status
On branch feature/estilos
Untracked files:
  (use "git add <file>..." to include in what will be committed)
        style.css

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
        index.html

Vamos línea a línea:

  • On branch feature/estilos — Git nos confirma que estamos en la rama correcta, no en main.
  • Untracked files: style.css — Git ve el fichero pero no lo conoce todavía. Como acabamos de crearlo, nunca ha formado parte de ningún commit.
  • Changes not staged for commit: index.html — Este fichero sí existía antes y Git lo tenía controlado, pero ahora tiene cambios que todavía no hemos añadido al área de staging.

Hacemos el commit:

git add .
git commit -m "Añade hoja de estilos y la enlazamos en el HTML"
[feature/estilos 3f8a21c] Añade hoja de estilos y la enlazamos en el HTML
 2 files changed, 9 insertions(+)
 create mode 100644 style.css

Volver a main

git switch main

Si miramos los ficheros del proyecto, style.css ha desaparecido y index.html no tiene el link. No es que se hayan borrado: están en feature/estilos. En main esos cambios todavía no existen.

Esto es lo que hace útiles a las ramas: puedes trabajar en algo durante días sin que main se entere.

Fusionar la rama

Cuando el trabajo en la rama está listo, lo incorporamos a main con merge:

git merge feature/estilos
Updating 7d9e0f1..3f8a21c
Fast-forward
 index.html | 1 +
 style.css  | 6 +++++
 2 files changed, 7 insertions(+)
 create mode 100644 style.css

Git dice Fast-forward. Significa que no ha habido ningún trabajo paralelo: mientras desarrollábamos en feature/estilos, nadie tocó main. El camino estaba despejado.

En ese caso Git no necesita combinar nada. Solo mueve main hacia adelante hasta alcanzar el último commit de la rama:

antes del merge:

  [primer commit] ──── [Añade estilos]
        ↑                     ↑
       main            feature/estilos


después del merge:

  [primer commit] ──── [Añade estilos]
                              ↑
                        main (avanzó)

Es el caso más sencillo y limpio. En la siguiente guía verás qué pasa cuando main sí ha avanzado por su lado, que es donde las cosas se complican.

git log --oneline --decorate
3f8a21c (HEAD -> main, feature/estilos) Añade hoja de estilos y la enlaza en el HTML
7d9e0f1 primer commit

Subir los cambios a GitHub

Ahora que main tiene los estilos, lo subimos:

git push

Si entramos en GitHub y refrescamos, veremos que style.css ya aparece en el repositorio.

Captura de GitHub mostrando el nuevo fichero style.css

Eliminar la rama

Una vez fusionada, la rama ya no hace falta. Es buena práctica borrarla para no acumular ramas que ya no se usan:

git branch -d feature/estilos
Deleted branch feature/estilos (was 3f8a21c).

Un último commit antes de terminar

Para dejar el repositorio listo para la siguiente guía, hacemos un cambio en main. Editamos index.js y añadimos una función:

index.js

console.log("Hola mundo");

const saludo = (nombre) => {
  return `Hola, ${nombre}`;
};
git add index.js
git commit -m "Añade función saludo en index.js"

En la siguiente guía crearás una rama que también modifica index.js. Cuando main y una rama tocan el mismo fichero, Git ya no puede fusionarlos automáticamente. Eso se llama conflicto, y es lo que verás a continuación.