Git

Descargar

Git es el sistema de control de versiones más usado del mundo. Guarda todo el historial de un proyecto: qué cambió, cuándo, quién lo cambió y por qué. Es software libre y gratuito, y funciona igual en Windows, GNU/Linux y macOS.

Sirve para trabajar sin miedo a romper algo —siempre se puede volver a una versión anterior—, para llevar la cuenta de los cambios propios y ajenos, y para compartir el proyecto entre varias computadoras. Es también lo que hay debajo de sitios como GitHub, GitLab o Bitbucket.

Descargar Git

En GNU/Linux casi siempre se instala con una sola orden desde el gestor de paquetes, sin entrar a ninguna página web. Todo está en Instalación en GNU/Linux. Para Windows se baja el instalador, en Instalación en Windows.

Qué es Git y para qué sirve

Para entender qué hace falta, conviene empezar por cómo se trabaja sin Git. Cuando un proyecto crece, aparecen los archivos con nombres así:

trabajo_final_final.docx
trabajo_final_final_bueno.docx
trabajo_final_ahora_si.docx
trabajo_final_ahora_si_este_anda.docx

Ese método tiene tres problemas. No se sabe qué cambió entre un archivo y otro. No se sabe cuándo ni por qué. Y no se puede volver atrás en una parte puntual: solo se puede elegir un archivo completo.

Git reemplaza esa costumbre por otra cosa: un único conjunto de archivos que va cambiando, y por debajo una historia con todos los estados por los que pasó, cada uno con su fecha, su autor y un mensaje que explica el cambio. Volver atrás deja de ser «abrir el archivo viejo» y pasa a ser «volver a este punto de la historia».

Las cuatro palabras que hay que retener

• Repositorio. La carpeta del proyecto más una carpeta oculta llamada .git. Ahí adentro vive toda la historia. Un proyecto se «convierte en repositorio» cuando se le crea esa carpeta, y eso es lo que hace el comando git init.
• Commit. Una foto del proyecto en un momento determinado, con autor, fecha y mensaje. Es la unidad mínima de la historia. «Hacer un commit» es guardar esa foto.
• Rama. Una línea de trabajo. La rama principal se llama main —o master en los proyectos viejos—. Las ramas permiten probar algo sin tocar la versión que funciona.
• Remoto. Una copia del repositorio que vive en otro lado, por lo general en internet (GitHub, GitLab). No es obligatorio: Git funciona perfectamente en una sola computadora.

Git no es GitHub

Se confunden todo el tiempo, y la diferencia importa:

Dicho de otro modo: Git se instala, GitHub se usa. Primero se instala Git y se configura —que es lo que explica esta página— y recién después, si hace falta publicar el proyecto, se abre una cuenta en GitHub.

Instalación en GNU/Linux

Git viene empaquetado en los repositorios oficiales de todas las distribuciones, así que se instala con el gestor de paquetes: una sola orden, sin instalador gráfico ni páginas de descarga.

Primero, comprobar si ya está

Algunas distribuciones lo traen instalado de fábrica. Antes de instalar nada conviene preguntar:

git --version

Si responde algo como git version 2.56.0, ya está y no hay nada más que hacer. Si responde command not found o «orden no encontrada», hay que instalarlo.

Instalarlo según la distribución

Cada familia de distribuciones usa su propio comando. Alcanza con identificar cuál es la propia:

Por qué sudo: Git se instala para todo el sistema, en carpetas que pertenecen al administrador, no dentro de la carpeta del usuario. Por eso el gestor de paquetes pide la contraseña.

Por qué apt update primero: apt trabaja con una lista de los paquetes disponibles, que se descarga cada tanto. Ese comando la actualiza antes de instalar; sin él, puede pasar que busque una versión que ya no existe y falle con «no se pudo encontrar el paquete». Las otras distribuciones actualizan la lista solas al instalar, así que ahí no hace falta.

Comprobar

Terminada la instalación, la misma orden del principio tiene que responder con la versión:

git --version
# git version 2.56.0

En GNU/Linux el instalador no crea nada más que el comando git. Queda pendiente la configuración del nombre y el correo, que es igual en los tres sistemas y está en Configuración inicial.

Instalación en Windows

En Windows Git no viene con el sistema: hay que descargarlo. El proyecto que lo empaqueta se llama Git for Windows y su página es git-scm.com/downloads. Ofrece tres descargas distintas:

• 64-bit Git for Windows Setup. Es el instalador normal: el que hay que bajar. Deja Git instalado y agregado al sistema.
• 64-bit Git for Windows Portable. Una versión que no se instala, se descomprime y se ejecuta desde ahí. Sirve para un pendrive o para una computadora donde no se puede instalar nada.
• MinGit. Una versión mínima, sin interfaz, pensada para que la usen otros programas por dentro. No es la que hay que bajar para trabajar.

Se descarga el primero, que pesa unos 70 MB, y se ejecuta con doble clic. Windows va a pedir permiso de administrador: hay que aceptar, porque el programa se instala para todo el sistema.

El asistente, pantalla por pantalla

El instalador hace una pregunta por pantalla. Ninguna es irreversible y todas se pueden dejar como vienen; la recomendación en cada caso está al final de cada punto.

1. Licencia. Git se distribuye con la licencia GPL versión 2, que es la que garantiza que sea y siga siendo software libre. Se acepta y se sigue.
2. Carpeta de instalación. Si el instalador se ejecutó como administrador —lo normal— propone C:\Program Files\Git y lo instala para todos los usuarios. Si se ejecutó sin esos permisos, instala solo para el usuario actual, en C:\Users\usuario\AppData\Local\Programs\Git. Las dos opciones funcionan; la segunda necesita menos permisos, pero la primera es la habitual.
3. Componentes. Es una lista de casilleros. Los que importan:
   • Additional icons. Un acceso directo en el escritorio o en la barra de inicio rápido.
   • Windows Explorer integration → Open Git Bash here y Open Git GUI here. Agrega «Abrir Git Bash aquí» al menú que aparece al hacer clic con el botón derecho sobre una carpeta. Es cómodo de verdad: abre la terminal ya parada en esa carpeta.
   • Git LFS. Soporte para archivos grandes. No se usa en estas materias, pero no molesta.
   • Associate .git* configuration files… y Associate .sh files to be run with Bash. Asocian esos archivos con el editor y con Bash, para poder abrirlos con doble clic.
   • Check daily for Git for Windows updates. Busca actualizaciones una vez por día.
   • Add a Git Bash Profile to Windows Terminal. Agrega Git Bash como una pestaña más del Terminal de Windows, si está instalado y el sistema es Windows 10 actualizado. Vale la pena.
   • Scalar. Una herramienta extra para repositorios muy grandes. Para aprender, no hace falta.
   Recomendación: dejar lo que viene marcado por omisión, que ya incluye «Open Git Bash here» y el perfil del Terminal.
4. Editor por defecto. Git necesita abrir un editor de texto en dos momentos: para escribir el mensaje de un commit cuando no se escribe en el mismo comando, y para resolver un conflicto. La lista ofrece Nano, Vim, Notepad++, VS Code y otros. Si VS Code está instalado y en el PATH, aparece en la lista y es la mejor opción. Si no, Nano: es el más simple de usar y muestra en pantalla los atajos para guardar y salir.
5. Nombre de la rama inicial. Dos opciones: Let Git decide, que usa el nombre histórico master, u Override the default branch name, que permite escribir main. Recomendación: main, porque es el nombre que usan GitHub y GitLab desde hace años para los repositorios nuevos. Si se deja master, después hay que renombrar la rama a mano en cada proyecto.
6. Ajuste del PATH. La pantalla más importante de todas, porque decide desde dónde se puede usar Git:
   • Use Git from Git Bash only: no toca el PATH. Git funciona solo dentro de Git Bash. Nada más lo ve.
   • Git from the command line and also from 3rd-party software (Recommended): agrega al PATH únicamente los envoltorios mínimos de Git. Funciona desde Git Bash, desde el Símbolo del sistema, desde PowerShell y desde cualquier programa que busque Git —por ejemplo VS Code, que lo usa para mostrar quién cambió cada línea.
   • Use Git and optional Unix tools from the Command Prompt: agrega además las herramientas de Unix que trae Git (find, sort, more y otras). El propio instalador avisa que eso puede reemplazar comandos de Windows y cambiar el comportamiento del sistema. No conviene.
   Recomendación: la del medio, que es la que viene marcada.
7. Cliente SSH. Decide con qué programa se hacen las conexiones cifradas cuando se usa una clave SSH. La opción Use bundled OpenSSH es la que trae Git y la recomendada. Use (Tortoise)Plink solo sirve si se tiene TortoiseGit; Use external OpenSSH, si ya se tiene otro SSH instalado aparte.
8. Biblioteca para HTTPS. Es la que se usa para las conexiones por https:// —el otro camino posible para hablar con GitHub—. Use the OpenSSL library es la que viene por omisión y la recomendada; la alternativa usa la biblioteca nativa de Windows. Cualquiera de las dos funciona; no conviene cambiar sin motivo.
9. Finales de línea. Es un detalle que parece menor y no lo es. Windows termina las líneas de texto con dos caracteres (CRLF) y Unix con uno solo (LF). Si cada sistema guarda lo suyo, cada archivo aparece «modificado» entero cada vez que alguien lo abre en el otro sistema. Las tres opciones:
   • Checkout Windows-style, commit Unix-style line endings (Recommended): al bajar los archivos los convierte a formato Windows, y al guardar en la historia los deja en formato Unix. Es la opción que evita el problema.
   • Checkout as-is, commit Unix-style: deja los archivos como están al bajarlos, pero guarda en formato Unix. Sirve si el editor se banca bien los dos formatos.
   • Checkout as-is, commit as-is: no convierte nada. Para un proyecto que se comparte con Linux, es la opción que trae dolores de cabeza.
   Recomendación: la primera.
10. Terminal de Git Bash. Con qué ventana se abre Git Bash:
    • Use MinTTY (the default terminal of MSYS2): la que viene por omisión. Ventana redimensionable, selección de texto libre y tipografías con Unicode. El propio instalador aclara su única contra: algunos programas interactivos de consola —por ejemplo el intérprete de Python en modo interactivo— tienen que lanzarse con winpty para funcionar bien adentro.
    • Use Windows' default console window: usa la consola clásica de Windows, más simple pero con menos comodidades.
    Recomendación: MinTTY.
11. Comportamiento de git pull. Define qué hace git pull —traer los cambios del remoto— cuando hay cambios locales y remotos a la vez: Merge (por omisión) los une creando un commit de mezcla; Rebase reescribe la historia propia para ponerla arriba de la ajena; Fast-forward only aborta con un mensaje si no puede avanzar sin mezclar. Recomendación: dejar Merge, que es lo más predecible cuando se está aprendiendo.
12. Credential Manager. Git Credential Manager es un ayudante que se encarga de las credenciales contra GitHub y Azure: la primera vez abre el navegador para iniciar sesión y después recuerda el acceso. Es la opción por omisión y la más práctica: sin él, hay que escribir un token a mano cada vez que se sube algo.
13. Opciones extra. Dos casilleros: Enable file system caching, que lee de a bloques y guarda en memoria para acelerar las operaciones —conviene dejar activado— y Enable symbolic links, que habilita los enlaces simbólicos y necesita un permiso especial de Windows (modo desarrollador). Para empezar, solo el primero.

Al final, el instalador ofrece dos casilleros: Launch Git Bash y View Release Notes. Se puede dejar solo el primero y Finish.

Comprobar

Se abre Git Bash desde el menú Inicio —o con «Abrir Git Bash aquí» sobre cualquier carpeta— y se pregunta la versión:

git --version
# git version 2.56.0.windows.2

También funciona desde PowerShell o desde el Símbolo del sistema, si en el paso 6 se eligió la opción recomendada del PATH. Si ahí responde «no se reconoce el término 'git'», es que quedó la primera opción: hay que reinstalar marcando la del medio, o usar Git Bash.

Bash en Windows

Este tema tiene una respuesta corta que sorprende: Bash no se instala en Windows. Bash es un intérprete de órdenes de Unix: es el programa que recibe lo que se escribe en la terminal, entiende ls, cd, pwd, cat, y sabe encadenar comandos con | y >. Windows no lo trae porque usa los suyos: el Símbolo del sistema (cmd.exe) y PowerShell.

Ahora que Git está instalado, hay dos caminos para tener Bash, y conviene entender la diferencia antes de elegir.

Opción 1: Git Bash, que ya viene instalado

Git for Windows no es solo el programa git: trae además un entorno reducido de Unix, y dentro de él, un Bash. Viene en la misma instalación que se acaba de hacer; no hay nada más que descargar. Ese entorno es el que el propio proyecto describe como una emulación de Bash que se comporta como el comando git de Linux y Unix.

Para abrirlo hay tres caminos, todos disponibles ya:

• Menú Inicio → Git Bash.
• Clic con el botón derecho sobre una carpeta → Open Git Bash here. Es el más cómodo: abre la terminal parada en esa carpeta, sin tener que navegar hasta ahí.
• En el Terminal de Windows, como una pestaña más —si en el instalador se marcó esa opción—.

Se comprueba así:

bash --version
pwd
ls

Ahí aparece la única rareza que hay que entender: las rutas no se escriben como en Windows. La unidad C: se ve como /c, así que C:\Users\Mauro\Documentos es /c/Users/Mauro/Documentos:

cd /c/Users/Mauro/Documentos

Con esto alcanza para todo lo que tiene que ver con Git: los comandos son los mismos que en GNU/Linux, y las órdenes de Unix básicas están disponibles.

Opción 2: WSL, un Linux completo adentro de Windows

Si lo que se necesita no es «parecido a Linux» sino Linux de verdad —por ejemplo para compilar C, correr nginx, usar apt o ejecutar los scripts de un servidor—, Windows tiene una respuesta oficial: el Subsistema de Windows para Linux (WSL). Instala una distribución completa (Ubuntu por omisión) que comparte las carpetas con Windows, pero tiene su propio sistema de archivos y su propio Bash.

La instalación es un solo comando. Se abre PowerShell como administrador —botón derecho sobre el icono → Ejecutar como administrador— y se escribe:

wsl --install

Ese comando habilita las funciones necesarias, descarga Ubuntu y lo deja listo; después hay que reiniciar la computadora. La primera vez que se abre Ubuntu pide crear un usuario y una contraseña propios del Linux, que son independientes de los de Windows.

Requiere Windows 10 versión 2004 o posterior (compilación 19041) o Windows 11. Para ver qué distribuciones hay disponibles se usa wsl --list --online, y para instalar otra distinta, wsl --install -d Debian (por ejemplo).

Cuál conviene

Configuración inicial: el nombre y el correo

Con Git instalado todavía no se puede hacer un commit. Falta lo primero que pide cualquier sistema de versiones: saber quién está trabajando.

El motivo es que cada commit guarda, junto con los cambios, el nombre y el correo del autor. Esos datos quedan escritos en la historia y no se pueden cambiar después sin reescribirla. El mensaje de error que aparece si no están configurados lo dice sin vueltas:

*** Please tell me who you are.
Run
  git config --global user.email "[email protected]"
  git config --global user.name "Your Name"
to set your account's default identity.

Las dos órdenes

Se escriben una vez, en cualquier terminal, y valen para siempre:

git config --global user.name "Mauro Bobyk"
git config --global user.email "[email protected]"

• Las comillas son necesarias si el valor tiene espacios. Sin ellas, Git interpreta cada palabra como un dato distinto y guarda cualquier cosa.
• --global significa «para todos los proyectos de este usuario». El valor queda y no hay que repetirlo en cada repositorio. Sin --global, la orden vale solo para el repositorio en el que se está parado: es lo que se usa cuando un proyecto puntual necesita otro nombre, por ejemplo el de una empresa.

Comprobar que quedó bien

git config --global --list
# user.name=Mauro Bobyk
# [email protected]

Sin --global, la orden muestra la configuración completa, ya mezclada con la que viene por omisión en el sistema.

El nombre de la rama inicial

Cada repositorio nuevo nace con una rama principal. Históricamente se llamaba master; hoy GitHub y GitLab usan main para los repositorios nuevos. Se puede dejar configurado para no tener que renombrarla en cada proyecto:

git config --global init.defaultBranch main

Si no se hace, Git sigue usando master al crear un repositorio con git init, y al subirlo a GitHub quedan dos nombres distintos para la misma rama. Es solo eso: una costumbre que evita un paso extra.

Y conviene tener claro que main y master son la misma cosa: cambia el nombre, no el comportamiento. Lo único que importa es que el nombre local y el del remoto coincidan. Muchos apuntes, tutoriales y cursos —y la configuración por omisión de Git— siguen trabajando con master, y no hay ningún problema en usar ese nombre: los comandos son idénticos.

Los finales de línea (solo en Windows)

Windows y Unix terminan las líneas de los archivos de texto de forma distinta: Windows con dos caracteres (CRLF) y Unix con uno (LF). Si Git no hace nada al respecto, cada archivo de un proyecto compartido aparece «modificado» en su totalidad cada vez que se lo abre en el otro sistema.

El instalador de Windows ya se ocupa de esto cuando se elige la opción recomendada. Se comprueba con:

git config --system core.autocrlf
# true

Si responde true, está bien: al bajar los archivos las líneas se convierten al formato de Windows, y al hacer un commit se guardan en formato Unix, que es el que entienden todos. Si la orden no responde nada, se arregla con git config --global core.autocrlf true.

El editor

Cuando el mensaje de un commit no se escribe en el mismo comando, Git abre un editor de texto. Si se usa VS Code, se le puede decir que sea el de siempre —el --wait es imprescindible: sin él, VS Code devuelve el control enseguida y Git sigue sin que el mensaje se haya escrito—:

git config --global core.editor "code --wait"

Si no se configura nada, en Windows se usa el editor elegido durante la instalación y en GNU/Linux suele abrirse Vim, que es incómodo para quien no lo conoce. Por eso conviene definirlo.

Clave SSH (opcional)

Este paso no hace falta para usar Git: solo sirve para hablar con GitHub. Hay dos formas de autenticarse, y conviene saber que existen las dos:

• HTTPS. La dirección del repositorio empieza con https://. Cada vez que se sube o baja algo hay que identificarse. En Windows, el Credential Manager que se instaló con Git se encarga de guardar el acceso la primera vez y después ya no pregunta nada.
• SSH. La dirección empieza con git@. Se genera un par de claves en la computadora y se le dice a GitHub cuál es la pública. No vuelve a pedir nada nunca más. Es el camino cómodo cuando se trabaja con varios repositorios.

Generar el par de claves

ssh-keygen -t ed25519 -C "[email protected]"

• -t ed25519 elige el tipo de clave. Es el algoritmo moderno y el que recomienda GitHub; las claves generadas así son más cortas y más seguras que las rsa antiguas.
• -C agrega un comentario al final de la clave, que no tiene ninguna función técnica: sirve para reconocer de qué computadora es cuando se ven varias listadas en GitHub. Lo habitual es poner el correo.

Después de ejecutarlo hace dos preguntas. La primera es dónde guardar los archivos, y la respuesta por omisión —el directorio ~/.ssh/— es la correcta: alcanza con apretar Enter. La segunda pide una frase de paso: es una contraseña que protege la clave privada, y se puede dejar vacía apretando Enter. Ponerla es más seguro; dejarla vacía es más cómodo, y para una computadora personal es una decisión razonable.

La orden crea dos archivos:

• id_ed25519 — la clave privada. No se comparte con nadie, nunca, bajo ningún motivo.
• id_ed25519.pub — la clave pública. Es la que se copia y se pega en GitHub. Se puede mostrar por pantalla con:

cat ~/.ssh/id_ed25519.pub

Cargarla en GitHub

Se copia el contenido completo del archivo .pub —empieza con ssh-ed25519 y termina con el correo— y en GitHub se entra a Settings → SSH and GPG keys → New SSH key, se le pone un título que identifique la computadora y se pega. Se guarda y ya está.

Probar que funciona

ssh -T [email protected]

La respuesta esperada es un mensaje que empieza con Hi usuario! You've successfully authenticated…. La primera vez va a preguntar si se confía en el servidor: se escribe yes. Que termine con «GitHub does not provide shell access» es correcto, no es un error: significa que la autenticación funcionó y que GitHub no da una consola de comandos, que es justamente lo que no se busca.

Comandos básicos

Git ordena el trabajo en tres áreas, y casi todos los comandos consisten en mover cambios de una a otra. Entender este dibujo es entender Git. Los apuntes y la documentación las nombran en inglés, así que conviene reconocer las dos formas:

• Directorio de trabajo (working directory): la carpeta del proyecto con los archivos tal como están ahora.
• Área de preparación (staging area): lo que ya se marcó para entrar en el próximo commit.
• Repositorio local (local repository): la historia de commits, guardada adentro de la carpeta oculta .git.

Y git status muestra cada archivo con el estado en el que está: sin seguimiento (untracked) si Git todavía no lo conoce, modificado (modified) si cambió y no se preparó, y preparado (staged) si ya está listo para el próximo commit. Los nombres en inglés son los que aparecen en la pantalla, así que vale la pena aprendérselos.

Crear, guardar y mirar

El ciclo de todos los días. Los tres primeros son los que se usan todo el tiempo:

Deshacer, mover y etiquetar

El archivo .gitignore

Hay archivos que no se guardan en la historia: los que se pueden volver a generar, los que pesan demasiado y —sobre todo— los que tienen datos privados. Para eso se crea, en la raíz del proyecto, un archivo de texto llamado .gitignore con la lista de lo que hay que ignorar:

# Dependencias: se reinstalan con el gestor de paquetes
node_modules/
vendor/

# Credenciales y configuración local: nunca
.env

# Archivos generados o temporales
*.log
build/
storage/

Cada línea es un patrón. El # comienza un comentario y la barra final indica una carpeta. Los archivos listados no aparecen en git status ni entran en ningún commit, aunque se use git add ..

Una sesión completa, paso a paso

Juntando todo, así se crea un proyecto desde cero y se lo publica. Es la secuencia que se repite cada vez que empieza algo nuevo:

mkdir mi-proyecto
cd mi-proyecto

git init
git config --global user.name "Mauro Bobyk"
git config --global user.email "[email protected]"

# ... se crean los archivos del proyecto ...

git status          # ¿qué hay para guardar?
git add .           # preparar todo
git commit -m "Primera version del proyecto"

git branch -M main                      # asegurar el nombre de la rama
git remote add origin [email protected]:usuario/mi-proyecto.git
git push -u origin main                 # primera subida

Y ya con el proyecto en marcha, el ciclo de todos los días es siempre el mismo:

git pull                            # traer lo que haya hecho otro
# ... trabajar: editar, crear, borrar archivos ...
git status
git add .
git commit -m "Agrega la pantalla de login"
git push

Cuando el cambio que se va a hacer es grande o experimental, no se trabaja directamente sobre main: se abre una rama, se trabaja ahí y después se fusiona. Eso está en Ramas y fusiones, y la forma de publicar y traer cambios de GitHub, en Repositorios remotos.

Vale la pena escribir git status antes de cada add y antes de cada commit: es la forma más rápida de entender qué está pasando, y evita el error clásico de guardar en un mismo commit cosas que no tienen nada que ver entre sí. Y si alguna vez una palabra o un comando no se entiende, git help explica: git help commit abre el manual del comando commit.

Ramas y fusiones

Hasta acá todo el trabajo fue en una sola línea: un commit atrás del otro. La rama (branch) es lo que permite abrir una segunda línea de trabajo, hacer cambios ahí sin tocar la principal, y después unirlas. Es lo que hace que Git sirva para trabajar entre varios y para probar cosas sin romper lo que ya funciona.

Al crear un repositorio, Git crea una rama principal —main, o master en los proyectos y apuntes más viejos: son la misma cosa—. Todo el trabajo del día a día pasa ahí hasta que haga falta otra. La rama en la que se está parado se llama rama actual, y es la que va a recibir los próximos commits.

Para qué sirve una rama

• Probar sin romper. Antes de un cambio grande se abre una rama. Si sale mal, se descarta y la rama principal queda intacta: nunca dejó de funcionar.
• Separar por tema. Una rama para arreglar un error, otra para una función nueva. Así la rama principal siempre se puede entregar.
• Trabajar de a varios. Cada persona hace su parte en su rama, y después se pide la fusión —en GitHub, con un pull request—.

Ver, crear y cambiar de rama

Para saber en qué rama se está parado y cuáles existen:

git branch

La rama actual aparece marcada con un asterisco. Para crear una y pasarse a ella en un solo paso hay dos formas, y las dos hacen exactamente lo mismo:

git checkout -b nueva-funcion      # la forma clásica

git switch -c nueva-funcion        # la forma moderna: el mismo resultado

Y para moverse entre ramas que ya existen:

git checkout main           # o:  git switch main
git checkout nueva-funcion  # o:  git switch nueva-funcion

La rama nueva nace con todos los commits de la rama en la que se estaba, y a partir de ahí las dos crecen por separado. Los cambios que se hagan en una no aparecen en la otra hasta que se fusionen.

Fusionar: el comando merge

git merge une dos historias. Lo importante es entender que siempre fusiona hacia la rama actual: lo que se pasa como argumento es la rama que se trae. Por eso el orden es: primero pararse en la rama que recibe, después traer la otra.

git checkout main          # 1. me paro en la rama que va a recibir
git merge nueva-funcion    # 2. traigo la otra
git branch -d nueva-funcion  # 3. si ya se fusionó, la borro

Según cómo hayan crecido las dos ramas, Git resuelve la fusión de dos maneras:

• Avance rápido (fast-forward): si la rama principal no se movió desde que se abrió la otra, alcanza con mover el puntero hacia adelante. No hay nada que combinar y no se crea ningún commit nuevo: la historia sigue siendo una línea recta.
• Fusión de tres vías (3-way): si las dos ramas avanzaron, Git busca el commit común del que salieron, combina los dos cambios y crea un commit de fusión —el F del dibujo—, que es el único commit con dos padres.

Para ver en qué quedó todo, la orden que muestra el árbol con las ramas dibujadas:

git log --oneline --decorate --graph --all

Cuando hay conflicto

Un conflicto aparece cuando las dos ramas tocaron la misma parte del mismo archivo de manera distinta. Git no adivina: para la fusión a mitad de camino y pide que lo resuelva una persona. En el archivo, las dos versiones quedan marcadas así:

<<<<<<< HEAD
    el texto que había en la rama actual
=======
    el texto que traía la otra rama
>>>>>>> nueva-funcion

Lo que está entre <<<<<<< y ======= es lo que ya había; lo que está entre ======= y >>>>>>> es lo que llega. La resolución tiene tres pasos:

1. Editar el archivo y dejarlo como tiene que quedar: se borran las tres líneas de marcas y se deja el contenido correcto —que puede ser uno de los dos, el otro, o una mezcla—.
2. git add archivo para avisarle a Git que ese conflicto ya está resuelto. Mientras quede alguno sin marcar, Git no deja terminar.
3. git commit para cerrar la fusión. Git propone un mensaje ya escrito; alcanza con guardarlo.

Durante el conflicto, git status es la guía: muestra los archivos en conflicto y, abajo, los pasos que faltan. Y si la fusión quedó más complicada de lo que parecía, se puede volver todo atrás con git merge --abort: la fusión se cancela y cada rama queda como estaba.

Borrar una rama

git branch -d nueva-funcion   # borra una rama ya fusionada
git branch -D nueva-funcion   # la borra aunque no esté fusionada

git branch -m nombre-nuevo    # renombra la rama actual

La diferencia entre -d y -D es una red de seguridad: la primera se niega a borrar una rama que tiene commits sin fusionar, y avisa: «The branch 'nueva-funcion' is not fully merged». Es una advertencia que vale la pena leer: borrar una rama sin fusionar es descartar todo el trabajo que hay en ella. Cuando de verdad es un experimento fallido, se fuerza con -D.

Repositorios remotos

Un remoto es una copia del repositorio que vive en otra computadora —casi siempre, en GitHub—. Se le pone un nombre corto, un alias, para no escribir la dirección entera cada vez. El nombre que se usa por costumbre para el principal es origin.

Hay dos maneras de conectar el proyecto con un remoto, y cuál se usa depende de dónde esté el repositorio hoy:

• Si el repositorio ya está en GitHub y no en la computadora: git clone URL, que lo trae entero —con toda la historia— a una carpeta nueva, y ya deja el remoto configurado con el nombre origin.
• Si el repositorio ya está en la computadora y hay que publicarlo: git remote add origin URL, que solo deja anotada la dirección; los commits se suben después con push.

Para ver qué remotos hay configurados y con qué dirección:

git remote -v
# origin  https://github.com/usuario/mi-proyecto.git (fetch)
# origin  https://github.com/usuario/mi-proyecto.git (push)

La dirección puede ser https://… —el caso de arriba— o [email protected]:usuario/mi-proyecto.git, que es la forma de SSH. La diferencia está explicada en Clave SSH. Otros dos comandos del mismo grupo: git remote show origin muestra el detalle del remoto —a qué rama está enganchada la actual, cuáles sigue y cuáles no— y git remote rm alias borra un remoto configurado.

Subir los commits: push

El push manda al remoto los commits que están en la computadora y no allá. La primera vez que se sube una rama se usa -u:

git push -u origin main    # la primera vez: sube y deja la rama enganchada
git push                   # las siguientes veces alcanza con esto

Ese -u deja anotado que la rama local main sigue a la rama main de origin. A partir de ahí, git push y git pull solos ya saben a dónde ir; sin ese dato hay que aclarar el remoto y la rama cada vez. A las ramas que se suben de vez en cuando, en cambio, se las puede subir sin -u: git push origin otra-rama.

Se suben commits, no archivos sueltos: lo que no se guardó con commit no viaja. Y para borrar una rama del remoto: git push origin --delete otra-rama.

Bajar los cambios: fetch y pull

Son dos comandos parecidos que hacen cosas distintas, y confundirlos es la causa de la mitad de los sustos con Git:

• git fetch origin baja del remoto lo nuevo y lo guarda en el repositorio local, pero no toca ni un archivo. Se puede mirar con calma qué llegó y decidir después.
• git pull hace las dos cosas de un tirón: baja y mezcla. Es el que se usa todos los días, al empezar a trabajar.

De hecho, pull es exactamente fetch seguido de merge. Hacerlo a mano es útil cuando se quiere ver antes de mezclar:

git fetch origin

git log --oneline origin/main   # qué llegó
git merge origin/main           # integrarlo

Existe además git pull --rebase: en lugar de crear un commit de fusión, pone los commits propios arriba de los que bajaron, y deja la historia en una línea recta. Es una herramienta útil pero que reescribe commits, así que conviene no usarla hasta entender bien qué hace.

Esa opción sale del comando git rebase, que es el que mueve una serie de commits de un lugar a otro. Con -i —interactivo— se abre una lista para reordenar los commits, juntar varios en uno o corregirles el mensaje antes de publicarlos: es útil para dejar la historia prolija antes de pedir una fusión. Reescribe la historia, así que la regla es no usarlo nunca sobre commits que ya se subieron al remoto, porque los demás ya los tienen.

Las ramas del remoto

El remoto también tiene ramas, y se pueden ver todas —las locales y las de allá— con git branch -a. Las del remoto aparecen con el prefijo remotes/origin/:

git branch -a
# * main
#   remotes/origin/main
#   remotes/origin/otra-rama

Si hay que trabajar sobre una rama que solo existe en el remoto, alcanza con pedirla: git checkout otra-rama la busca en origin, la baja y crea la rama local con el mismo nombre, todo en un paso. Es la forma de tomar una rama de otra persona sin tener que crear nada a mano.