Tutorial de Git: instalar y configurar Git paso a paso

Este capítulo instala Git, ajusta los tres parámetros sin los cuales tu primer commit será rechazado y pone en marcha la autenticación con GitHub o GitLab. Cuenta unos quince minutos, incluida la parte de la clave SSH.

Si llegas directamente aquí, la diferencia entre Git y GitHub y el detalle del recorrido están en la introducción del tutorial.

Instalar Git

Es muy probable que Git ya esté en tu máquina si trabajas en macOS o en Linux. Compruébalo antes de instalar nada:

git --version

Si el comando responde con un número de versión, Git está instalado y puedes pasar a la configuración. Si responde que no encuentra el comando, sigue la sección que corresponda a tu sistema.

Windows

Lo más sencillo es el gestor de paquetes integrado en Windows:

winget install --id Git.Git -e --source winget

Si no, descarga el instalador en git-scm.com/install/windows y deja las opciones por defecto. La última versión publicada en el momento de esta comprobación es Git for Windows 2.55.0(5), del 20 de agosto de 2026. La instalación incluye Git Bash, un terminal que reproduce el entorno Unix. Úsalo en lugar del símbolo del sistema: todos los comandos de este tutorial funcionan ahí tal cual.

macOS

Git viene con las herramientas de línea de comandos de Xcode. La primera vez que invocas git se ofrece a instalarlas, o puedes forzar la instalación:

xcode-select --install

Esa versión es fiable, pero suele ir unos meses por detrás de la versión oficial. Para mantenerte al día, tira de Homebrew:

brew install git

Linux

Usa el gestor de paquetes de tu distribución.

# Debian, Ubuntu y derivadas
sudo apt update && sudo apt install git

# Fedora, RHEL, Rocky
sudo dnf install git

# Arch
sudo pacman -S git

# Alpine
sudo apk add git

La versión instalada depende de su distribución, y la diferencia a veces es grande. Las versiones registradas el 7 de septiembre de 2026 se dan en la sección « Resultado medido » al final de este capítulo. Ubuntu 24.04 incluye Git 2.43, publicado a finales de 2023: es más que suficiente para todo lo que hace este tutorial, ya que los comandos más recientes que usamos datan de Git 2.23.

Declararte: nombre y dirección de correo

Git anota el autor de cada commit en el historial. Mientras no le hayas dicho quién eres, se niega a registrar nada:

Author identity unknown

*** Please tell me who you are.

Run

  git config --global user.email "you@example.com"
  git config --global user.name "Your Name"

to set your account's default identity.
Omit --global to set the identity only in this repository.

fatal: unable to auto-detect email address (got 'root@23d1d26b6831.(none)')

Así que ajusta los dos valores antes que nada:

git config --global user.name "Damien Flandrin"
git config --global user.email "dam@example.com"

La opción --global escribe en tu archivo personal y vale para todos tus proyectos. Sin ella, el ajuste solo afecta al repositorio actual, algo útil cuando usas una dirección profesional en unos proyectos y una personal en otros.

Usa una dirección que no te importe hacer pública: aparece en el historial, y el historial se distribuye a todo el que clona el proyecto. GitHub ofrece una dirección de sustitución en @users.noreply.github.com si prefieres no exponer la tuya.

Elegir el nombre de la rama por defecto

Es el punto sobre el que circula más información falsa. Se lee a menudo que Git ya crea una rama main. No es cierto. Esto es lo que produce git init con Git 2.55, la versión vigente en septiembre de 2026:

hint: Using 'master' as the name for the initial branch. This default branch name
hint: will change to "main" in Git 3.0. To configure the initial branch name
hint: to use in all of your new repositories, which will suppress this warning,
hint: call:
hint:
hint: 	git config --global init.defaultBranch <name>
hint:
hint: Names commonly chosen instead of 'master' are 'main', 'trunk' and
hint: 'development'. The just-created branch can be renamed via this command:
hint:
hint: 	git branch -m <name>
hint:
hint: Disable this message with "git config set advice.defaultBranchName false"
Initialized empty Git repository in /root/a1/.git/

La rama se llama, en efecto, master, y el propio Git anuncia que el valor por defecto pasará a main a partir de la versión 3.0. Lo que ha cambiado son los alojadores: GitHub crea los repositorios nuevos con una rama main desde octubre de 2020, y GitLab desde su versión 14. De ahí el desfase permanente entre lo que hace tu máquina y lo que hace el servidor.

Zanja la cuestión de una vez por todas:

git config --global init.defaultBranch main

El mensaje desaparece y los repositorios que crees a partir de ahora arrancan en main. Ojo: este ajuste solo se aplica a los repositorios nuevos. Para uno que ya existe y cuya rama se llama master:

git branch -m master main

Comprobar tu configuración

Con tres comandos sabes en qué punto estás:

git config --global --list                # qué está configurado
git config --global --list --show-origin  # y en qué archivo
git config --global --edit                # abrir el archivo

La configuración personal es un simple archivo de texto, ~/.gitconfig, que puedes leer y modificar directamente:

[user]
	name = Damien Flandrin
	email = dam@example.com
[init]
	defaultBranch = main

Hay dos ajustes más que conviene dejar puestos desde el principio. El editor que Git usa para los mensajes de commit, porque si no acabarás tarde o temprano dentro de Vim sin saber cómo salir:

git config --global core.editor "code --wait"   # Visual Studio Code
git config --global core.editor "nano"          # o cualquier editor de terminal

Y el comportamiento de git pull, que detallaremos en el capítulo sobre las ramas:

git config --global pull.rebase true

Autenticarte en GitHub o GitLab

Aquí toca una aclaración de vocabulario, porque hace perder mucho tiempo a quien empieza. Tu contraseña de GitHub ya no sirve para nada en Git. GitHub dejó de aceptar las contraseñas de cuenta para las operaciones Git el 13 de agosto de 2021. Esto es lo que responde el servidor si lo intentas igualmente:

Cloning into 'depot-prive'...
remote: Invalid username or token. Password authentication is not supported for Git operations.
fatal: Authentication failed for 'https://github.com/damienflandrin/depot-prive.git/'

Quedan dos métodos válidos: la clave SSH o el token de acceso personal. La clave SSH se monta en cinco minutos y no vuelve a pedirse nunca más. Es la que recomendamos.

Crear una clave SSH

ssh-keygen -t ed25519 -C "dam@example.com"

Acepta la ruta que se propone por defecto. La frase de paso es opcional, pero recomendable: protege la clave si tu máquina se ve comprometida.

Generating public/private ed25519 key pair.
Created directory '/root/.ssh'.
Your identification has been saved in /root/.ssh/id_ed25519
Your public key has been saved in /root/.ssh/id_ed25519.pub
The key fingerprint is:
SHA256:s5YjDRbNgv3/o8SvEFh4A6hzpWddSsquX0l0k4aUptw dam@example.com

Se han creado dos archivos. id_ed25519 es la clave privada: no sale nunca de tu máquina, no se copia a ningún sitio, no se pega en ningún formulario. id_ed25519.pub es la clave pública, la que le confías al servidor.

Muestra la clave pública y copia la línea entera:

cat ~/.ssh/id_ed25519.pub

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAINjiBkboRdOPXk2UWn3UUMSv2qr8G9cGvzKsTd+ZyYCa dam@example.com

Pégala después en Settings > SSH and GPG keys > New SSH key en GitHub, o en Preferencias > Claves SSH en GitLab.

Comprobar que la clave funciona

ssh -T git@github.com

La primera conexión te pide confirmar la huella del servidor. La de GitHub para las claves Ed25519 es SHA256:+DiY3wvvV6TuJJhbpZisF/zLDA0zPMSvHdkr4UvCOqU, compárala con la que publica GitHub antes de responder yes. Si todo está en orden, GitHub contesta con un mensaje de bienvenida que menciona tu nombre de usuario y precisa que el acceso al shell no está permitido, lo cual es normal. Si en su lugar obtienes esto:

git@github.com: Permission denied (publickey).

es que la clave pública no se ha registrado en tu cuenta, o que has pegado la clave privada por error.

La alternativa: el token de acceso personal

Si SSH está bloqueado en tu red, o dentro de un script de integración continua, usa un token de acceso personal. En GitHub lo creas en Settings > Developer settings > Personal access tokens, mejor con los tokens de alcance fino (fine-grained), que limitan el acceso a un repositorio concreto y caducan solos. En GitLab, el equivalente está en Preferencias > Tokens de acceso.

El token se usa en lugar de la contraseña cuando Git la pide. Para no reescribirlo en cada comando, activa un gestor de credenciales:

git config --global credential.helper store    # sencillo, pero el token queda escrito en claro
git config --global credential.helper osxkeychain  # macOS, guardado en el llavero

En Windows, Git Credential Manager viene instalado y activado por defecto con Git for Windows.

Trata un token exactamente igual que una contraseña: no se mete en un repositorio, ni en un archivo de configuración versionado, ni en una URL que compartes.

Tu equipo ya está listo. El capítulo siguiente crea un repositorio en GitHub o GitLab y lo conecta con una carpeta de tu máquina.

Resultado medido

Versión de Git instalada por el gestor de paquetes en la imagen oficial de cada distribución, registrada el 7 de septiembre de 2026:

Todas sirven: el comando más reciente empleado en este tutorial, git switch, data de Git 2.23.