Skip to content
This page has been auto-translated and may contain errors.View in English

Tu primer repositorio

docs.scrimba.com

Hay dos formas en que usualmente terminas aquí. O tienes una carpeta de proyecto ya, una weather-app que has estado construyendo localmente, y quieres que Git comience a registrar su historial. O alguien más ya construyó el proyecto, vive en GitHub, y quieres tu propia copia de trabajo en tu máquina. Ambas comienzan con tres comandos pequeños, y al final de este capítulo habrás usado los tres de verdad. Pero primero, una verificación que toma diez segundos: asegurarse de que Git esté en tu máquina en absoluto.

¿Tienes Git instalado?

Todo en este manual sucede en la terminal, así que la primera parada es abrirla. Una terminal es una aplicación donde escribes comandos como texto y los programas responden en texto. Ya está en tu computadora:

  • macOS: la aplicación se llama Terminal. Presiona Cmd+Espacio, escribe "terminal" y presiona Intro.
  • Windows: abre PowerShell por ahora (busca "powershell" en el menú Inicio). Instalar Git a continuación también añade Git Bash, una terminal construida exactamente para esto, y cualquiera ejecuta los mismos comandos de Git.
  • Linux: busca una aplicación llamada Terminal o Console; Ctrl+Alt+T la abre en muchas distribuciones.

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

Entonces, la verificación. Escribe esto en tu terminal y presiona Intro:

bash
$ git --version
git version 2.45.1

Un número de versión de vuelta significa que Git está instalado y estás listo. Tu número probablemente diferirá del mío, y eso está bien. Si en su lugar ves "command not found" o "git is not recognized", Git aún no está en tu máquina, e instalarlo es un trabajo de una sola vez:

  • macOS: ejecutar git --version usualmente abre un diálogo ofreciendo instalar las Command Line Tools de Apple. Acéptalo, y macOS instala Git para ti.
  • Windows: descarga Git for Windows desde git-scm.com/downloads y ejecuta el instalador. Los valores predeterminados son todas opciones razonables, e instala Git Bash en el camino.
  • Linux: instala el paquete git con el gestor de paquetes de tu distribución, por ejemplo sudo apt install git en Ubuntu y Debian.

Una vez que termina la instalación, cierra tu terminal, abre una nueva, y ejecuta git --version de nuevo. Un número de versión significa que estás hecho con la configuración para siempre; nada más en este manual necesita instalar.

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

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

Git es un único programa independiente, no un servicio. Nada se ejecuta en segundo plano, nada vigila tus carpetas, y no hay cuenta en la que iniciar sesión: cada comando comienza, lee o escribe archivos dentro del repositorio, imprime su respuesta y sale. Eso también es por qué todo funciona sin conexión. Ejecuta which git (o where git en Windows) para ver exactamente dónde vive el programa en el disco.

Un problema de plataforma que vale la pena saber: en macOS, Apple distribuye su propia compilación de Git con las Command Line Tools, usualmente una o dos versiones atrás del lanzamiento más reciente en git-scm.com. Para todo en este manual, y casi todo en el trabajo diario, esa brecha no importa.

Juno¿Tienes Git instalado? Git es un programa con el que hablas 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 instalarlo desde git-scm.com o el instalador de tu sistema. Solo haces esta parte una vez. La configuración es la parte menos divertida de cualquier manual, ¡así que bien hecho llegando hasta aquí!
Juno¿Tienes Git instalado?git --version resuelve la pregunta de instalación en una línea. Cualquier cosa razonablemente reciente funciona, aunque los verbos switch y restore que este manual usa necesitan Git 2.23 o más reciente, así que actualiza si estás atrás. Las herramientas GUI como GitHub Desktop ejecutan este mismo programa por debajo, lo que significa que todo lo que aprendes aquí se transfiere a ellas gratis.
Juno¿Tienes Git instalado? Git es un programa local único sin daemon y sin cuenta: se ejecuta cuando escribes, toca archivos en el repositorio y sale, que es por qué cada bit de él funciona sin conexión. which git te muestra el binario. La compilación incluida de Apple va atrás del lanzamiento más reciente por una o dos versiones, y en catorce años esa brecha no me ha costado nada.

Convirtiendo una carpeta en un repositorio

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

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

Esa carpeta es ahora un repositorio: un proyecto que Git vigila, listo para registrar instantáneas del mismo mientras trabajas. git init hace lo mismo cada vez. Busca una carpeta .git oculta, crea una si falta, y a partir de ese momento la carpeta está bajo la vigilancia de Git.

La rama predeterminada de un nuevo repositorio se llama main. Si caes en un tutorial antiguo, un repositorio antiguo, o un curso grabado hace algunos años, verás master usado para la misma cosa: es la misma primera rama bajo un nombre antiguo. Este manual siempre usa main.

¿Qué es una rama?

Una rama es una línea separada de historial para que tus commits caigan, y main es la que cada nuevo repositorio comienza. Branches cubre crearlas y cambiar entre ellas.

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 sentada allí, y Git comienza a rastrear ese proyecto desde donde sea que 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 su lugar sin tocar ningún historial que ya tengas, así que ejecutarla de nuevo por hábito no te cuesta nada.

git init hace una cosa: crea la carpeta .git, desempacada en detalle más adelante en este capítulo. Todo sobre el repositorio, su historial, sus configuraciones, sus refs, 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 se rastrea, y la carpeta .git es el repositorio en sí.

JunoConvirtiendo una carpeta en un repositoriogit init convierte cualquier carpeta en un repositorio de Git, listo para que Git comience a rastrearlo. Ejecútalo una vez dentro de una carpeta de proyecto y estás listo, y ejecutarlo de nuevo después no hace daño. Los nuevos repositorios usan por defecto una rama llamada main, aunque los más antiguos que encuentres usualmente se llaman master por la misma cosa.
JunoConvirtiendo una carpeta en un repositoriogit init funciona en una carpeta vacía o una ya llena de archivos, y ejecutarlo de nuevo en un repositorio que ya configuraste no causa daño ya que Git reconoce que la carpeta .git ya está allí. El nombre de rama predeterminado es main; espera master en cualquier cosa más antigua.
JunoConvirtiendo 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. Mantén esa separación entre tus archivos de trabajo y la carpeta .git que los rastrea.

Diciéndole a Git quién eres

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

bash
$ git config --global user.name "Carlos Rodríguez"
$ git config --global user.email "[email protected]"

Cada commit que creas se marca con ese nombre y correo electrónico. Salta este paso, y Git vuelve a algo adivinado del nombre de usuario y nombre de host de tu computadora, así que tus commits llevan una identidad que nunca elegiste.

Establece tu nombre y correo electrónico antes de tu primer commit. Haz el commit primero y establécelos después, y el error se hornea en el historial de ese commit. Peor aún, algunos hosts (GitHub incluido) coinciden commits con tu cuenta por correo electrónico, así que un commit hecho bajo la dirección equivocada o una adivinada aparece como trabajo de un extraño anónimo en su lugar del tuyo.

El flag --global establece un alcance de configuración: --global aplica en todas partes en tu máquina, mientras que --local aplica solo al repositorio en el que estás cuando lo ejecutas. Eso te permite hacer capas de configuraciones. Tu correo electrónico global cubre cada repositorio por defecto, y un override --local en un repositorio específico toma prioridad sobre él allí y en ningún otro lado, útil cuando un proyecto de trabajo necesita una dirección diferente que tus proyectos personales:

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

Ejecutar git config user.email sin flag de alcance lee cualquier valor que realmente aplique aquí: el local si lo estableciste, el global en caso contrario.

Ambos alcances son archivos de texto que Git lee en un orden fijo. El global vive en tu carpeta de inicio en ~/.gitconfig; el local vive dentro de la carpeta .git del repositorio, en .git/config. Git lee primero la configuración local y deja que anulen las globales, que es toda la mecánica de capas, dispuesta en archivos de texto plano que puedes abrir y leer tú mismo.

JunoDiciéndole a Git quién eresgit config --global user.name y git config --global user.email establecen el nombre y correo electrónico que Git marca en cada commit que hagas. Establécelos antes de tu primer commit, porque un commit hecho antes de establecer tu correo electrónico se atribuye a una identidad adivinada, y un host como GitHub puede no conectarlo a tu cuenta en absoluto. Hazlo una vez y cada repositorio en tu máquina lo recuerda.
JunoDiciéndole a Git quién eres--global aplica a cada repositorio en tu máquina, y --local lo anula solo para el repositorio actual, útil para dividir un correo electrónico personal de uno de trabajo. La configuración local gana cuando ambas se establecen, y git config user.email te dice qué valor realmente está activo en un repositorio dado.
JunoDiciéndole a Git quién eres Los alcances de configuración son archivos de texto en capas: global vive en ~/.gitconfig, local vive en .git/config dentro del repositorio, y local gana siempre que ambas establezcan un valor. Salta establecer tu correo electrónico y Git vuelve a una identidad adivinada construida a partir de tu nombre de usuario y nombre de máquina, que es por qué un commit extraviado bajo un nombre extraño casi siempre se remonta a un user.email faltante.

Copiando un proyecto existente con git clone

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

bash
$ 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 nueva carpeta llamada Hello-World, descarga el historial completo del proyecto en ella, y coloca sus archivos en la carpeta para que puedas comenzar a leer o editar de inmediato. No se necesita un paso git init separado. Clonar configura el repositorio para ti como parte de descargarlo.

Alcanza git clone cuando el proyecto ya existe en algún lugar y quieres una copia conectada del mismo. Alcanza git init cuando estás comenzando algo completamente nuevo que no existe en ningún lado aún. Clonar también prepara una conexión de vuelta a donde clonaste, bajo el nombre origin, algo que init solo nunca hace; esa conexión es lo que capítulos posteriores usan para enviar y recibir commits.

Clonar trae el historial completo del proyecto, cada commit que ha tenido, y puebla la carpeta completa .git en tu máquina, donde git init la dejaría vacía. Un clon de un proyecto con años de historial puede tomar un momento exactamente por esta razón, aunque lo que ves después se parece a una instantánea de los archivos más recientes.

JunoCopiando un proyecto existente con git clonegit clone <url> descarga el repositorio de alguien más, historial completo incluido, en una nueva carpeta llamada según el proyecto. Alcánzalo cuando el proyecto ya existe en algún lado; alcanza git init cuando estás comenzando uno desde cero. Una vez que termina el clonado tienes una copia de trabajo completa, lista para mirar o añadir.
JunoCopiando un proyecto existente con git clone Clona cuando un proyecto ya vive en algún lado y quieres una copia conectada; init cuando nada existe aún. Clonar prepara la conexión de vuelta a donde clonaste automáticamente, bajo el nombre origin, que init por sí solo nunca configura.
JunoCopiando un proyecto existente con git clone Clonar recrea la carpeta .git completa con cada commit que el proyecto ha tenido. Eso incluye el historial completo, que es por qué un proyecto más antiguo puede tomar un momento clonar aunque solo veas sus archivos actuales después.

Qué hay dentro de la carpeta oculta .git

Cada repositorio, ya sea que llegues allí con git init o git clone, tiene una carpeta oculta llamada .git sentada en su raíz. Está oculta por defecto, así que pide a la terminal el listado completo con ls -a (ls lista los contenidos de una carpeta, y -a incluye entradas ocultas) para verla sentada junto a tus archivos de proyecto normales:

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

Esa carpeta es el repositorio real. Contiene cada commit que has hecho, tus ramas, y la configuración de la sección anterior. Elimina la carpeta .git y el proyecto pierde su historial completo, convirtiéndose atrás en una carpeta ordinaria que Git ya no rastrea. Todo lo demás en el proyecto es una copia de trabajo de lo que .git contiene.

Mira adentro y encontrarás algunos fragmentos 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 o editar ninguno de estos a mano, pero reconocer los nombres ayuda cuando uno de ellos aparece en un mensaje de error o un resultado de búsqueda.

Unos pocos de esos nombres vale la pena conocer adecuadamente. La carpeta objects es la base de datos de objetos del repositorio: cada versión de cada archivo y cada commit que has hecho, comprimido y almacenado por el contenido en sí en lugar de un nombre de archivo. La carpeta refs contiene tus ramas, cada una un pequeño archivo apuntando a una id de commit. HEAD es un archivo único registrando qué rama tienes actualmente checked out. config es el archivo de configuración local cubierto arriba.

Nada de esto es algo que edites a mano día a día. Ver tu historial completo sentado allí como archivos ordinarios, en lugar de estar escondido en un servidor en algún lado, explica por qué un clon te da historial completo sin conexión, y por qué eliminar .git no ordena nada: borra cada commit que el proyecto ha tenido.

JunoQué hay dentro de la carpeta oculta .git Cada repositorio tiene una carpeta oculta .git en su raíz, y esa carpeta es el repositorio real: tu historial completo y sus configuraciones viven allí. Ejecuta ls -a dentro de un proyecto para verla, ya que está oculta por defecto. Nunca la elimines a menos que realmente quieras borrar el historial completo del proyecto, ya que eliminarla convierte la carpeta atrás en una carpeta plana 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 carpetas objects y refs. No tocarás estas a mano día a día, pero los nombres aparecen en mensajes de error y documentación de Git. Clonar copia esta carpeta completa, que es por qué un clon llega con historial completo en lugar de solo los archivos más recientes.
JunoQué hay dentro de la carpeta oculta .gitobjects es la base de datos de objetos del repositorio, conteniendo cada versión de cada archivo y commit, direccionados por contenido en lugar de nombre de archivo. refs contiene tus ramas como archivos planos apuntando a una id de commit, y HEAD registra cuál tienes checked out. Nada allí necesita edición a mano, pero verlo como archivos ordinarios en disco es la razón por la que clonar te da historial completo sin conexión, y la razón por la que eliminar .git borra todo en lugar de meramente limpiar.

Si los términos repositorio y commit aún se sienten borrosos, What is Git cubre el modelo mental en el que estos comandos se construyen, y el Glossary tiene una definición corta para cada pieza de vocabulario en este capítulo. Una vez que tu identidad está establecida y tienes un repositorio en el que trabajar, The commit loop cubre el ciclo diario de edición, preparación y confirmación que usarás constantemente de aquí en adelante.