Tu primer repositorio

docs.scrimba.com

Por lo general llegas hasta aquí de dos formas. O ya tienes una carpeta de proyecto, un weather-app que vienes construyendo localmente, y quieres que Git empiece a registrar su historia. O alguien más ya construyó el proyecto, este vive en GitHub, y quieres tener tu propia copia de trabajo en tu máquina. Ambos casos empiezan con tres comandos pequeños, y al terminar este capítulo ya habrás usado los tres de verdad. Pero antes, una comprobación que toma diez segundos: asegurarte de que Git esté instalado en tu máquina.

¿Tienes Git instalado?

Todo lo que verás en este manual ocurre en la terminal, así que el primer paso es abrir una. Una terminal es una aplicación donde escribes comandos como texto y los programas te responden en texto. Ya la tienes en tu computadora:

• macOS: la aplicación se llama Terminal. Presiona Cmd+Espacio, escribe "terminal" y presiona Enter.
• Windows: por ahora abre PowerShell (busca "powershell" en el menú Inicio). Al instalar Git más abajo también se agrega Git Bash, una terminal hecha justamente para esto, y cualquiera de las dos ejecuta los mismos comandos de Git.
• Linux: busca una aplicación llamada Terminal o Consola; Ctrl+Alt+T la abre en muchas distribuciones.

Git en sí mismo es un programa de línea de comandos: no tiene ventana propia, y lo usas escribiendo comandos que empiezan con la palabra git y leyendo lo que te responde. Así también debes leer cada bloque de código en este manual: la línea que empieza con $ es el comando que tú escribes (sin el $), y las líneas debajo son la respuesta de Git.

Entonces, la comprobación. Escribe esto en tu terminal y presiona Enter:

$ git --version
git version 2.45.1

Si te devuelve un número de versión, significa que Git está instalado y listo para usar. Es probable que tu número sea distinto al de este ejemplo, y eso está bien. Si en cambio ves "command not found" o "git is not recognized", Git todavía no está en tu máquina, e instalarlo es una tarea que solo harás una vez:

• macOS: al ejecutar git --version normalmente se abre un diálogo que te ofrece instalar las Command Line Tools de Apple. Acéptalo, y macOS instalará Git por ti.
• Windows: descarga Git for Windows desde git-scm.com/downloads y ejecuta el instalador. Las opciones predeterminadas son razonables en todos los casos, y de paso se instala Git Bash.
• Linux: instala el paquete git con el gestor de paquetes de tu distribución, por ejemplo sudo apt install git en Ubuntu y Debian.

Cuando termine la instalación, cierra tu terminal, abre una nueva y vuelve a ejecutar git --version. Si ves un número de versión, terminaste la configuración para siempre; nada más en el resto de este manual requiere instalación.

El número de versión importa un poco más de lo que parece. Este manual usa los verbos modernos git switch y git restore, que llegaron en Git 2.23 en 2019, así que una máquina con un Git preinstalado muy antiguo puede arrojar "not a git command" en ejemplos que son correctos. Cualquier Git de los últimos años los tiene; si el tuyo es anterior a 2.23, actualízalo desde los mismos lugares mencionados arriba.

También te vas a encontrar con herramientas gráficas de Git: GitHub Desktop, el panel de Git en VS Code, el soporte integrado en la mayoría de los editores. Todas son interfaces que por debajo ejecutan este mismo programa de Git. Aprender primero los comandos también te sirve ahí, porque cada botón de esas herramientas corresponde a un comando que ya conoces.

Git es un solo programa autónomo, no un servicio. Nada corre en segundo plano, nada vigila tus carpetas, y no hay ninguna cuenta en la que iniciar sesión: cada comando arranca, lee o escribe archivos dentro del repositorio, imprime su respuesta y termina. Por eso todo funciona sin conexión a internet. Ejecuta which git (o where git en Windows) para ver exactamente dónde vive el programa en tu disco.

Una particularidad de plataforma que vale la pena conocer: en macOS, Apple distribuye su propia compilación de Git junto con las Command Line Tools, normalmente una o dos versiones por detrás de la última publicada en git-scm.com. Para todo lo que hay en este manual, y para casi todo el trabajo diario, esa diferencia no importa.

Juno¿Tienes Git instalado? Git es un programa con el que te comunicas escribiendo comandos en una terminal, y git --version te dice si está en tu máquina: un número de versión significa que estás listo, y "command not found" significa que hay que instalarlo desde git-scm.com o el instalador de tu sistema. Esto solo lo haces una vez. La configuración es la parte menos divertida de cualquier manual, ¡así que felicidades por haberla superado!

Juno¿Tienes Git instalado?git --version resuelve la duda de la instalación en una sola línea. Cualquier versión razonablemente reciente funciona, aunque los verbos switch y restore que usa este manual necesitan Git 2.23 o más nuevo, así que actualiza si te quedaste atrás. Las herramientas con interfaz gráfica como GitHub Desktop ejecutan por debajo este mismo programa, así que todo lo que aprendas aquí se traslada gratis a ellas.

Juno¿Tienes Git instalado? Git es un solo programa local sin demonio y sin cuenta: corre cuando escribes, toca archivos dentro del repositorio y termina, por eso funciona sin conexión de principio a fin. which git te muestra el binario. La compilación que incluye Apple va una o dos versiones detrás de la más reciente, y en catorce años esa diferencia no me ha costado nada.

Convertir una carpeta en un repositorio

Abre una terminal y muévete a tu carpeta de proyecto con cd (abreviatura de "change directory"), y luego ejecuta un solo comando, git init:

$ cd weather-app
$ git init
Initialized empty Git repository in /Users/mara/projects/weather-app/.git/

Esa carpeta ahora es un repositorio: un proyecto que Git vigila, listo para registrar instantáneas de él mientras trabajas. git init hace exactamente lo mismo cada vez que lo ejecutas. Busca una carpeta oculta llamada .git, la crea si no existe, y desde ese momento la carpeta queda bajo la vigilancia de Git.

La rama predeterminada de un repositorio nuevo se llama main. Si te encuentras con un tutorial más antiguo, un repositorio más viejo, o un curso grabado hace algunos años, verás que se usa master para exactamente lo mismo: es la misma rama inicial con un nombre anterior. Este manual siempre usa main.

¿Qué es una rama?

Una rama es una línea de historia separada donde pueden aterrizar tus commits, y main es la que trae todo repositorio nuevo desde el inicio. Ramas explica cómo crearlas y cómo cambiar entre ellas.

A git init no le importa si la carpeta está vacía. Ejecútalo dentro de weather-app con un index.html y una carpeta src/ ya existentes, y Git empieza a rastrear ese proyecto tal como está; ninguno de los archivos existentes cambia. Ejecutar git init una segunda vez en el mismo repositorio también es inofensivo. Git nota que la carpeta .git ya existe y la reinicializa en el mismo lugar sin tocar el historial que ya tienes, así que ejecutarlo de nuevo por costumbre no te cuesta nada.

git init hace una sola cosa: crea la carpeta .git, que se detalla más adelante en este capítulo. Todo lo relacionado con el repositorio, su historia, su configuración, sus referencias, vive dentro de esa carpeta desde el momento en que init la crea. Los archivos que ves y editas en el proyecto son una copia de trabajo de lo que está rastreado, y la carpeta .git es el repositorio en sí mismo.

JunoConvertir una carpeta en un repositoriogit init convierte cualquier carpeta en un repositorio de Git, listo para que Git empiece a rastrearla. Ejecútalo una vez dentro de una carpeta de proyecto y ya quedas listo, y ejecutarlo de nuevo más adelante no hace ningún daño. Los repositorios nuevos usan por defecto una rama llamada main, aunque los más antiguos que encuentres por ahí suelen llamarla master para lo mismo.

JunoConvertir una carpeta en un repositoriogit init funciona tanto en una carpeta vacía como en una ya llena de archivos, y ejecutarlo de nuevo en un repo que ya configuraste no causa ningún daño, porque Git reconoce que la carpeta .git ya está ahí. El nombre de la rama predeterminada es main; espera encontrar master en cualquier cosa más antigua.

JunoConvertir una carpeta en un repositoriogit init solo crea la carpeta .git, que es el repositorio real. Tus archivos de trabajo son un checkout de lo que esa carpeta rastrea. Ten siempre presente esa división entre tus archivos de trabajo y la carpeta .git que los rastrea.

Decirle a Git quién eres

Antes de tu primer commit, Git necesita saber quién lo está haciendo. Configura dos valores una sola vez, y Git los recordará para cada commit que hagas en esta máquina:

$ git config --global user.name "Mara Chen"
$ git config --global user.email "[email protected]"

Cada commit que crees quedará marcado con ese nombre y ese correo. Si te saltas este paso, Git recurre a algo que adivina a partir del nombre de usuario y el nombre del equipo, así que tus commits terminan con una identidad que nunca elegiste.

Configura tu nombre y tu correo antes de tu primer commit. Si haces el commit primero y configuras esto después, el error queda grabado en el historial de ese commit. Peor aún, algunos servicios (GitHub incluido) relacionan los commits con tu cuenta a partir del correo, así que un commit hecho con la dirección equivocada o una adivinada aparece como el trabajo de un desconocido anónimo en vez del tuyo.

La bandera --global establece un alcance de configuración: --global se aplica en toda tu máquina, mientras que --local se aplica solo al repositorio en el que estás cuando lo ejecutas. Eso te permite superponer configuraciones. Tu correo global cubre todos los repositorios por defecto, y una sobrescritura con --local en un repositorio específico tiene prioridad ahí y solo ahí, algo útil cuando un proyecto de trabajo necesita una dirección distinta a la de tus proyectos personales:

$ cd weather-app
$ git config --local user.email "[email protected]"
$ git config user.email
[email protected]

Ejecutar git config user.email sin ninguna bandera de alcance lee el valor que realmente aplica ahí: el local si lo configuraste, o el global si no.

Ambos alcances son archivos de texto que Git lee en un orden fijo. El global vive en tu carpeta de usuario, en ~/.gitconfig; el local vive dentro de la propia carpeta .git del repositorio, en .git/config. Git lee primero la configuración local y deja que esta sobrescriba a la global, que es todo el mecanismo de superposición, expuesto en archivos de texto plano que puedes abrir y leer tú mismo.

JunoDecirle a Git quién eresgit config --global user.name y git config --global user.email configuran el nombre y el correo que Git marca en cada commit que haces. Configúralos antes de tu primer commit, porque un commit hecho antes de configurar tu correo queda atribuido a una identidad adivinada, y un servicio como GitHub puede incluso no relacionarlo con tu cuenta. Hazlo una vez y todo repositorio en tu máquina lo recordará.

JunoDecirle a Git quién eres--global se aplica a todos los repositorios de tu máquina, y --local lo sobrescribe solo para el repositorio actual, algo útil para separar un correo personal de uno de trabajo. La configuración local gana cuando ambas están definidas, y git config user.email te dice qué valor está realmente activo en un repositorio dado.

JunoDecirle a Git quién eres Los alcances de configuración son archivos de texto superpuestos: el global vive en ~/.gitconfig, el local vive en .git/config dentro del repositorio, y el local gana cuando ambos definen un valor. Si no configuras tu correo, Git recurre a una identidad adivinada a partir de tu nombre de usuario y el nombre de tu máquina, por eso un commit extraño bajo un nombre raro casi siempre se remonta a un user.email sin configurar.

Copiar un proyecto existente con git clone

A veces el proyecto ya existe en otro lugar, y lo que quieres es tener una copia de trabajo en tu máquina. git clone hace eso en un solo comando:

$ git clone https://github.com/octocat/Hello-World.git
Cloning into 'Hello-World'...
remote: Enumerating objects: 13, done.
remote: Total 13 (delta 0), reused 0 (delta 0), pack-reused 13
Receiving objects: 100% (13/13), done.

Git crea una carpeta nueva llamada Hello-World, descarga en ella todo el historial del proyecto y coloca sus archivos en la carpeta para que puedas empezar a leer o editar de inmediato. No se necesita ningún paso adicional de git init. Clonar configura el repositorio por ti como parte de la descarga.

Usa git clone cuando el proyecto ya existe en algún lugar y quieres una copia conectada a él. Usa git init cuando estás empezando algo totalmente nuevo que todavía no existe en ningún lado. Clonar también establece una conexión de vuelta hacia el lugar de donde clonaste, bajo el nombre origin, algo que init por sí solo nunca hace; esa conexión es la que usan los capítulos siguientes para enviar y recibir commits.

Clonar descarga todo el historial del proyecto, cada commit que haya tenido jamás, y llena por completo la carpeta .git en tu máquina, donde git init la habría dejado vacía. Un clon de un proyecto con años de historia puede tomar un momento por esta misma razón, aunque lo que ves después parezca solo una instantánea de los archivos más recientes.

JunoCopiar un proyecto existente con git clonegit clone <url> descarga el repositorio de otra persona, historial completo incluido, en una carpeta nueva con el nombre del proyecto. Úsalo cuando el proyecto ya existe en algún lugar; usa git init cuando empiezas uno desde cero. Cuando termina de clonar, tienes una copia de trabajo completa, lista para revisar o para agregarle cosas.

JunoCopiar un proyecto existente con git clone Clona cuando un proyecto ya vive en algún lugar y quieres una copia conectada a él; usa init cuando todavía no existe nada. Clonar establece automáticamente la conexión de vuelta hacia el lugar de origen, bajo el nombre origin, algo que init por sí solo nunca configura.

JunoCopiar un proyecto existente con git clone Clonar recrea toda la carpeta .git con cada commit que el proyecto haya tenido jamás. Eso incluye el historial completo, por eso un proyecto antiguo puede tardar un momento en clonarse aunque después solo veas sus archivos actuales.

Qué hay dentro de la carpeta oculta .git

Todo repositorio, sin importar si lo creaste con git init o con git clone, tiene una carpeta oculta llamada .git en su raíz. Está oculta por defecto, así que pídele a la terminal el listado completo con ls -a (ls lista el contenido de una carpeta, y -a incluye las entradas ocultas) para verla junto a los archivos normales de tu proyecto:

$ ls -a
.  ..  .git  README.md  src

Esa carpeta es el verdadero repositorio. Ahí se guarda cada commit que has hecho, tus ramas, y la configuración de la sección anterior. Si borras la carpeta .git, el proyecto pierde todo su historial, y vuelve a ser una carpeta común que Git ya no rastrea. Todo lo demás en el proyecto es una copia de trabajo de lo que contiene .git.

Si miras adentro encontrarás algunas piezas reconocibles: un archivo config (la configuración local de la sección anterior), un archivo HEAD, y carpetas llamadas objects y refs. No necesitas abrir ni editar ninguno de estos a mano, pero reconocer los nombres ayuda cuando alguno aparece en un mensaje de error o en un resultado de búsqueda.

Vale la pena conocer bien algunos de estos nombres. La carpeta objects es la base de datos de objetos del repositorio: cada versión de cada archivo y cada commit que has hecho, comprimidos y almacenados según su propio contenido en vez de un nombre de archivo. La carpeta refs contiene tus ramas, cada una como un archivo pequeño que apunta a un id de commit. HEAD es un único archivo que registra qué rama tienes actualmente en uso. config es el archivo de configuración local descrito arriba.

Nada de esto es algo que edites a mano en el día a día. Ver todo tu historial ahí, como archivos comunes, en vez de escondido en algún servidor, explica por qué un clon te da todo el historial sin conexión, y por qué borrar .git no ordena nada: borra cada commit que el proyecto haya tenido jamás.

JunoQué hay dentro de la carpeta oculta .git Todo repositorio tiene una carpeta oculta .git en su raíz, y esa carpeta es el verdadero repositorio: ahí vive todo tu historial y su configuración. Ejecuta ls -a dentro de un proyecto para verla, ya que está oculta por defecto. Nunca la borres a menos que realmente quieras eliminar todo el historial del proyecto, porque borrarla convierte la carpeta en una carpeta común que Git ya no rastrea.

JunoQué hay dentro de la carpeta oculta .git Dentro de .git reconocerás un archivo config (tu configuración local), un archivo HEAD, y las carpetas objects y refs. No los tocarás a mano en el día a día, pero esos nombres aparecen en mensajes de error y en la documentación de Git. Clonar copia toda esta carpeta, por eso un clon llega con el historial completo y no solo con los archivos más recientes.

JunoQué hay dentro de la carpeta oculta .gitobjects es la base de datos de objetos del repositorio, y contiene cada versión de cada archivo y commit, direccionados por contenido en vez de por nombre de archivo. refs guarda tus ramas como archivos simples que apuntan a un id de commit, y HEAD registra cuál tienes actualmente en uso. Nada ahí necesita edición manual, pero verlo como archivos comunes en el disco es la razón por la que clonar te da historial completo sin conexión, y la razón por la que borrar .git lo elimina todo en vez de solo limpiar algo.

Si los términos repositorio y commit todavía se sienten confusos, Qué es Git explica el modelo mental sobre el que se construyen estos comandos, y el Glosario tiene una definición breve para cada término de vocabulario de este capítulo. Una vez que tengas tu identidad configurada y un repositorio en el que trabajar, El ciclo del commit explica el ciclo diario de editar, preparar y confirmar que vas a usar constantemente a partir de ahora.