Git básico I: crear y clonar repositorios

Primera entrega de la serie Git básico. Forma parte de un recorrido más amplio por git en tres niveles: básico, intermedio y avanzado. Tiempo de lectura estimado: 5 minutos.

Arrancamos una serie de nueve posts sobre git organizados en tres niveles: básico, intermedio y avanzado. Tres comandos por entrega, tres entregas por nivel. La idea es cubrir lo que de verdad se usa cada día, sin teoría de relleno ni diagramas de grafos dirigidos acíclicos.

En este primer post, los tres comandos con los que empiezas todo: git init, git clone y git status. Son los primeros que tecleas en un repo y los últimos que dejas de usar.

git init: convertir una carpeta en un repositorio

git init convierte un directorio normal en un repositorio de git. Lo ejecutas dentro de la carpeta que quieres versionar y crea un directorio oculto .git/ con toda la maquinaria: referencias, objetos, configuración local. El resto del directorio sigue exactamente como estaba.

mkdir mi-proyecto
cd mi-proyecto
git init

A partir de ese momento, git sabe que esa carpeta es un repositorio. No ha trackeado todavía ningún fichero, ni ha hecho commits, ni ha creado la rama principal (aunque la tiene "prevista" como main en versiones modernas). Solo ha montado la infraestructura.

Variantes útiles:

git init -b main            # fuerza que la rama inicial se llame main
git init --bare repo.git    # repo sin working tree, para usar como remoto

La versión --bare es la que montas en un servidor cuando quieres un repo central al que la gente pueda hacer push. Un repo normal no está pensado para recibir push a su rama actual; uno bare sí.

Un error típico: ejecutar git init dentro de una carpeta que ya es un repo, o peor, dentro de una subcarpeta de un repo existente. No rompe nada, pero te queda un repo anidado con comportamientos raros. Antes de teclear git init, verifica con git status que no estás ya dentro de un repositorio.

git clone: traerte un repo que ya existe

git clone hace una copia local de un repositorio remoto. Es lo que ejecutas cuando alguien te pasa una URL de GitHub, GitLab o un servidor interno:

git clone https://github.com/usuario/proyecto.git
git clone [email protected]:usuario/proyecto.git

La primera forma usa HTTPS, la segunda SSH. Funcionalmente son equivalentes para la mayoría de operaciones, pero SSH es más cómodo cuando vas a hacer push frecuente porque no te pide credenciales cada vez (usa tu clave SSH).

clone hace bastantes cosas en un solo comando:

1. Crea una carpeta con el nombre del repo (o el que le pases como segundo argumento).
2. Ejecuta git init dentro.
3. Configura origin apuntando a la URL desde la que clonaste.
4. Descarga todos los objetos del repo remoto.
5. Hace checkout de la rama principal.

Opciones que uso a menudo:

git clone --depth 1 URL           # clone "shallow", solo el último commit
git clone --branch desarrollo URL # clona y hace checkout de una rama concreta
git clone URL carpeta-destino     # clona en una carpeta con otro nombre

El --depth 1 es útil cuando el repo es gigante y solo lo quieres para compilar, no para trabajar en él. Reduce el tamaño descargado muchísimo. Si luego necesitas más historial, siempre puedes hacer git fetch --unshallow.

git status: qué tiene mi repo ahora mismo

Si tuviera que quedarme con un solo comando de git, sería este. git status te dice en qué rama estás, qué ficheros han cambiado, cuáles están preparados para commit, cuáles tienes sin trackear, y si tu rama está adelantada o atrasada respecto al remoto.

$ git status
On branch main
Your branch is up to date with 'origin/main'.

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   README.md

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        notas.txt

no changes added to commit (present, use "git add" -p to track)

Git te da pistas dentro del propio output: "use git add", "use git restore". Léelas. Git está diseñado para enseñarte los siguientes pasos si prestas atención a lo que te dice.

Variantes que uso:

git status -s    # versión corta, una línea por fichero
git status -sb   # corta + muestra el estado de la rama

La versión -sb es la que acabas usando cuando el output por defecto te parece demasiado verboso. Con dos caracteres por línea te dice todo: ?? es untracked, M modificado, A añadido, D borrado. La primera columna es el staging area, la segunda es el working tree.

El flujo mental básico

Con estos tres comandos ya tienes el punto de partida:

1. O empiezas un proyecto nuevo con git init, o te bajas uno existente con git clone.
2. Trabajas en los ficheros.
3. Cada cierto tiempo, lanzas git status para ver qué has tocado.

El hábito de lanzar git status constantemente es lo que diferencia a quien se maneja bien con git de quien teclea comandos a ciegas. En una sesión normal, yo ejecuto git status probablemente cincuenta veces. Antes de cualquier operación que no sea trivial, verifico el estado.

Errores típicos cuando empiezas

Clonar dentro de otro repo. Si estás en tu carpeta ~/proyectos/trabajo/ y haces git clone allí, el nuevo repo queda dentro de cualquier otro repo que haya en una carpeta padre. Confuso y peligroso. git status te salva aquí también.

Olvidar que git init no añade ficheros. Iniciar un repo no trackea nada. Tienes que añadir ficheros con git add y hacer commit. Lo vemos en el siguiente post.

Clonar con HTTPS cuando necesitas push frecuente. Si cada push te pide contraseña, cambia a SSH. Actualizar la URL del remote se hace con git remote set-url origin git@....

Lo que viene

Con el repo creado y el hábito de consultar su estado, el siguiente paso es guardar cambios. En la segunda entrega de la serie toca el ciclo básico: git add, git commit y git diff. Es decir, cómo preparas un commit, cómo lo creas y cómo revisas lo que estás a punto de guardar antes de hacerlo.

Si ya dominas lo básico, puedes saltar directamente a la serie intermedia (ramas, deshacer y stash) o a la avanzada (rebase, bisect, worktree).