git clone para coding agents: un repo, luego worktree

git clone no es “otro checkout”. El man (git-clone(1); git-scm.com/docs/git-clone HTTP 200): clona a un directorio recién creado, arma remote-tracking branches (git branch --remotes) y hace checkout de una rama inicial forkeada de la rama activa del remoto. Fija remote.origin.url y remote.origin.fetch. Un segundo clone del mismo URL es otro objeto store, no un worktree.

GitHub Docs (HTTP 200, 2026-09-04, Cloning a repository): el repo en GitHub es el remoto; clonar crea una copia local y puedes sync. “Pulls down a full copy of all the repository data … including all versions of every file and folder”. Un coding agent no clona el monorepo entero en cada sesión. Contrato: clonar una vez a un path dedicado; sesiones = worktree.

Qué hace el clone (oficial)

Tras el clone, un git fetch sin args actualiza todos los remote-tracking. Un git pull sin args además mergea la rama default del remoto en la rama actual — falso si usaste --single-branch. Esa config default vive en refs/remotes/origin + remote.origin.*.

git clone https://github.com/org/repo.git /path/al/repo
cd /path/al/repo
git status -sb
git remote -v

El directorio no existía. Si el path ya es un repo, no clones encima: worktree add.

Lo que el agente sí / no corre

Quiero	Comando	Trampa
Primer clone	git clone <url> <dir>	Clonar en un dir que ya tiene .git
Rama distinta al HEAD remoto	git clone -b <rama> <url> <dir>	-b + --mirror
Sesión extra	worktree add	Segundo git clone
Ver qué hay	git remote -v + status	Confiar en el cwd del humano

Prohibido en autónomo:

• --shared / -s. El man: “possibly dangerous”. El clone no copia objetos; usa objects/info/alternates. Si el origen borra ramas o git maintenance run --auto limpia dangling, el clone se corrompe. git repack -a rompe la dependencia; un agente no monta esa trampa.
• --bare / --mirror. --bare hace del directorio el $GIT_DIR: no hay working tree. --mirror implica --bare y mapea todos los refs; un git remote update sobrescribe esos refs. Un agente necesita disco para editar.
• --local / -l contra un repo de otro usuario. El man: no funciona por seguridad; hace falta --no-local. Path local + symlinks en $GIT_DIR/objects → el clone falla (no seguir symlinks). Path local corre en paralelo con writes al origen “similar to cp -r”.
• git://. El man (GIT URLS): el transporte nativo no autentica; “use with caution on unsecured networks”. ftp/ftps para fetch: ineficiente y deprecated. HTTPS o SSH.
• --recurse-submodules “por si acaso”. Sin pathspec inicializa todos los submódulos (submodule.active=.). Equivale a git submodule update --init --recursive al terminar. Un agente nombra pathspec o no recursa.
• --depth como default de “repo de trabajo”. El man: history truncada a N commits; implica --single-branch salvo --no-single-branch. Fetches siguientes solo actualizan esa rama. --shallow-submodules = depth 1 en submódulos. Un shallow no es el objeto store para bisect ni para log de rangos largos.
• URL suelta sin directorio destino cuando el cwd no es el home del agente. Nombra <directory>.

--filter=blob:none (partial clone) pide al servidor un subconjunto; los blobs llegan on demand. Útil en monorepos enormes; no es el default de un agente que va a leer el árbol.

Receta (60 segundos)

Si ya hay clone local del mismo remoto: no clones. Worktree.

Si no hay clone:

git clone --origin origin <url> /path/al/repo
cd /path/al/repo
git branch --show-current          # default del remoto; no trabajar aquí
git switch -c agente/<slug>        # o worktree add ../agente-<slug>

-o / --origin nombra el remote (default origin, override clone.defaultRemoteName). -b / --branch apunta HEAD a <name> en vez del HEAD del remoto; en un repo no-bare esa es la rama de checkout.

--config=<key>=<value> setea config local antes de fetch. Un agente no usa eso para saltar TLS ni core.sshCommand opaco.

Cierre del trabajo: PR, no un segundo clone “limpio”.

URLs, shallow y el servidor

GitHub Docs: clona con HTTPS, SSH o GitHub CLI (gh repo clone). El agente pega la URL que ya tiene el harness (origin del humano, o el fork). No inventa hosts.

--single-branch: solo la historia hasta el tip de una rama (--branch o el HEAD remoto). Si el HEAD remoto no apuntaba a una rama, no se crea remote-tracking. --no-tags queda permanente vía remote.<remote>.tagOpt=--no-tags; fetch/pull no siguen tags.

--reject-shallow (y clone.rejectShallow): niega clonar un origen que ya es shallow. Un agente no “completa” un shallow ajeno con otro clone encima.

--sparse: arranca sparse-checkout. Sin cone/patterns del repo, el working tree queda a medias. No es el default.

Tras el clone, integrar remoto es fetch / pull, no volver a clonar.

Checklist

• ¿Ya existe un clone de ese remoto? → worktree, no git clone.
• Destino = directorio nuevo. URL HTTPS o SSH, no git://.
• Cero --shared, --bare, --mirror, --local de otro uid.
• Cero --recurse-submodules sin pathspec. Cero --depth como “repo de trabajo”.
• Tras el clone: rama de trabajo ≠ default. switch o worktree.
• Cierre = PR, no otro clone.

FAQ

¿git clone en el home del humano “más rápido que worktree”? El man: directorio nuevo + objeto store propio. Dos clones = dos copias. Worktree comparte objetos.

¿--depth 1 para CI? Sí, en un job efímero. En el disco del agente, no: implica --single-branch y recorta historia.

¿--recurse-submodules porque el README lo pide? El man inicializa todos si no hay pathspec. Nombra el path o deja que el humano lo pida.

¿--shared entre worktrees? No. Worktree ya comparte el store. --shared apunta alternates a otro repo; borrar el origen corrompe el clone.

El curso instalar un agente cubre el loop local. Hub: comparativas y decisiones. Clone no es fetch: crea el repo; no actualiza uno existente.

Verificado 2026-09-04 contra git-clone(1) (Git 2.50.1 / Apple Git-155), git-scm.com/docs/git-clone (HTTP 200) y GitHub Docs “Cloning a repository” (HTTP 200).