Comando Git Clone: Desde el uso básico hasta las técnicas avanzadas

URL y protocolos de Git

Como se ve en el ejemplo anterior de clonación del repositorio «aws-cli», para clonar un repositorio utilizando git clone, necesitamos proporcionar la ubicación del repositorio remoto, lo cual se hace a través de una URL de Git.

Git admite varios protocolos para acceder a repositorios remotos, cada uno con su propia estructura, modelo de seguridad y mejores casos de uso. Comprender los diferentes tipos de URL de Git y cuándo utilizar cada uno de ellos puede ayudarte a trabajar de forma más segura y eficiente, especialmente cuando colaboras con otros equipos o automatizas implementaciones.

Tipos de URL de Git

Al clonar un repositorio, la URL que proporcionas le indica a Git cómo conectarse al servidor remoto. Los tipos de URL de Git más comunes son:

HTTPS

Protocolo seguro de transferencia de hipertexto (HTTPS). Se utiliza más comúnmente para acceder a páginas web a través de un navegador web. Este tipo de URL es fácil de usar y no requiere ninguna configuración al clonar un repositorio público. Aquí tienes algunos ejemplos:

git clone https://github.com/<username>/<repo>.git
git clone https://github.com/aws/aws-cli.git
git clone https://gitlab.com/gitlab-org/gitlab.git

Desglose de la estructura:

• https:// – Protocolo utilizado para la comunicación (seguro y compatible con cortafuegos).
• github.com – Dominio del servicio de alojamiento Git.
• username/repo.git – Ruta al repositorio:
• username es el propietario (usuario u organización)
• repo.git es el nombre del repositorio Git

SSH

Terminal segura (SSH). Un protocolo de red autenticado que requiere que establezcas credenciales con el servidor de alojamiento antes de conectarte. Requiere generar un par de claves SSH y añadir la clave pública a tu proveedor de Git (por ejemplo, GitHub, GitLab).

git clone git@github.com:<username>/<repo>.git
git clone git@github.com:aws/aws-cli.git
git clone git@gitlab.com:gitlab-org/gitlab.git

Desglose de la estructura:

• git@ – Especifica la cuenta de usuario SSH (normalmente solo git).
• github.com: – Dominio del servidor Git, seguido de dos puntos : (no una barra).
• username/repo.git – Ruta al repositorio en el servidor.

Como no he configurado ninguna clave SSH en mi cuenta de GitHub, aparece el siguiente mensaje cuando intento copiar la URL SSH.

No hay ninguna clave SSH configurada

En la siguiente sección explicaré cómo configurar las claves SSH.

GIT

Un protocolo ligero y no autenticado para acceso de solo lectura. Es un protocolo exclusivo de git. Hoy en día se utiliza muy poco debido a problemas de seguridad y a que los principales proveedores, como GitHub y GitLab, lo han dejado obsoleto. Ni siquiera encontrarás la opción de clonar utilizando el protocolo git en GitHub o GitLab.

# Not recommended
git clone git://github.com/<username>/<repo>.git

Desglose de la estructura:

• git// – Protocolo Git (solo lectura, sin autenticación).
• github.com: – Dominio del servidor Git.
• username/repo.git – Ruta al repositorio en el servidor.

Independientemente del protocolo de clonación utilizado, puedes comprobar la URL y el protocolo utilizados ejecutando los siguientes comandos:

git remote -v
git remote show origin

Elegir el protocolo URL adecuado

Cada protocolo tiene sus ventajas y desventajas. En la siguiente tabla, comparamos las ventajas y desventajas de elegir el protocolo adecuado para tu caso de uso.

Procedimientos de clonación específicos del protocolo

Una vez que hayas elegido un protocolo URL Git, el proceso de clonación y el flujo de trabajo de autenticación serán diferentes. Aunque ambos métodos consiguen en última instancia el mismo objetivo (clonar un repositorio remoto en tu máquina local), se adaptan a diferentes preferencias de seguridad, necesidades de los usuarios y complejidades de configuración. 

En esta sección, explicaré cómo clonar un repositorio utilizando tanto HTTPS como SSH, junto con las mejores prácticas, los pasos de configuración y consejos para solucionar problemas, con el fin de garantizar un proceso de clonación seguro y sin problemas.

Flujo de trabajo de clonación Git HTTPS

Clonar un repositorio Git a través de HTTPS es el método más sencillo, lo que lo hace ideal para principiantes y entornos con restricciones (como cortafuegos corporativos o redes restringidas).

Para clonar un repositorio, navega hasta él y copia la URL HTTPS. La siguiente imagen está tomada de GitHub. Será similar a tu proveedor de Git.

Obtener la URL HTTPS de un repositorio en GitHub

A continuación, ejecuta el comando « git clone » en el destino (por ejemplo, tu ordenador portátil o un canal de CI/CD) donde deseas clonar el repositorio.

git clone https://github.com/aws/aws-cli.git

Comando básico git clone

Para clonar un repositorio público, como hemos hecho con el repositorio «aws-cli», no se requiere autenticación, ya que el repositorio es público. Siempre que tengas instalado git en tu sistema, podrás clonar el repositorio público inmediatamente sin necesidad de configuración alguna.

Sin embargo, si estás clonando un repositorio privado, se requiere autenticación. Puedes autenticarte a través de:

• Token de acceso personal
• Claves maestras

Para demostrar la autenticación mediante un token de acceso personal, he creado un servidor en AWS EC2 y he instalado Git. Al ejecutar el comando « git clone » en un repositorio privado, se solicita un nombre de usuario y una contraseña. Introduce tu nombre de usuario de GitHub como nombre de usuario y tu token de acceso personal como contraseña.

Autenticación HTTPS mediante nombre de usuario/contraseña

Debido al aumento de las políticas de seguridad, GitHub y otros proveedores ahora requieren un token de acceso personal en lugar de una contraseña.

Clonación con instrucciones para el token de acceso a URL HTTPS. Fuente: GitHub

Si no introduces tu token de acceso personal, aparecerá el siguiente error:

Se ha eliminado la compatibilidad con la autenticación mediante contraseña.

Para crear untoken de acceso personal, ve a Crear un token de GitHub y sigue las instrucciones: 

Crea un token de acceso personal en GitHub.

Para evitar tener que introducir tu token de acceso personal cada vez que Git requiera autenticación a través de HTTPS, puedes utilizar un asistente de credenciales para almacenar tus credenciales de forma segura. Una opción popular es Git Credential Manager. 

En macOS, Git se integra perfectamente con el llavero de macOS, que es lo que yo utilizo personalmente para almacenar mis credenciales. En mi caso, me autentico utilizando claves almacenadas en el llavero, lo que me permite disfrutar de una experiencia segura y fluida.

Ver asistente de credenciales

Claves maestras en MacOS

Para configurar una clave de acceso, ve a la configuración de contraseñas y autenticación de GitHubysigue las instrucciones.

Crear una clave maestra en GitHub

Aunque GitHub te permite crear un token de acceso personal sin caducidad, la mayoría de las organizaciones aplican políticas de seguridad que exigen que los tokens tengan fecha de caducidad. Esto significa que si un token se utiliza en entornos automatizados, como canalizaciones de CI/CD, y caduca, la canalización fallará debido a errores de autenticación. Es esencial regenerar de forma proactiva el token antes de que caduque y actualizar su uso en consecuencia.

Sin los controles adecuados, los programadores pueden crear y utilizar inadvertidamente múltiples tokens de acceso personal sin una documentación clara ni un seguimiento. Esto puede generar rápidamente confusión sobre qué token se utiliza y dónde, lo que dificulta el mantenimiento y la auditoría. Para una mejor higiene, se recomienda mantener el uso de tokens al mínimo, documentarlo y vincularlo a casos de uso específicos.

Metodología de clonación SSH

SSH ofrece un método de autenticación seguro y persistente, especialmente adecuado para colaboradores habituales y usuarios avanzados. Una vez configurado, proporciona una forma sencilla de interactuar con los repositorios sin tener que introducir repetidamente las credenciales.

Para configurar la autenticación SSH, primero debemos generar un par de claves SSH, que consta de una clave pública y una privada.

# ed25519 specifies the key type
ssh-keygen -t ed25519 -C "your_email@google.com"

Crear un par de claves SSH

Como ya tengo una clave SSH existente en ~/.ssh/id_ed25519, sobrescribí el directorio predeterminado donde se almacenarán las claves. Pero si estás creando la clave SSH por primera vez en tu dispositivo, acepta el directorio predeterminado.

Navega hasta las claves SSH y GPC en GitHub para configurar tu clave SSH.

Configurar la clave SSH en GitHub

Copia el contenido de la clave pública en la sección «Clave». En mi caso, es el contenido de id_ed25519.pub.

Pega el contenido de id_ed25519.pub

SSH utiliza cifrado de clave pública/privada. Mantén tu clave privada segura y protegida en tu equipo. Con esto, ya estás listo para clonar un repositorio, ya sea público o privado, a través de SSH.

Después de configurar correctamente SSH, al seleccionar la URL de SSH ya no aparece el mensaje de advertencia, como se ve en la sección «Tipos de URL de Git» anterior.

Obtener la URL SSH de un repositorio en GitHub

git cloneDado que la clave privada SSH reside en mi dispositivo local, demostraré la conexión de SSH utilizando SSH en mi dispositivo local en lugar del servidor EC2.

git clone git@github.com:aws/aws-cli.git

Clonar repositorios públicos y privados utilizando SSH

¡Hemos realizado correctamente la operación git clone utilizando SSH!

Las ventajas de SSH incluyen su seguridad y su uso generalizado en organizaciones, ya que permite la autenticación sin contraseña, lo que resulta ideal para interacciones frecuentes. Las conexiones SSH también son resistentes a las interrupciones de red y suelen ser más rápidas que HTTPS en largas distancias.

Sin embargo, los programadores suelen encontrar problemas durante la configuración de la clave SSH, ya que copian la clave pública incorrecta al proveedor de Git. Si tienes varias claves privadas para diferentes fines, debes definir en el archivo ~/.ssh/config qué clave se debe utilizar para cada host. De lo contrario, al autenticarte en GitHub, se podría utilizar la clave privada destinada a Bitbucket, lo que provocaría un error de autenticación.

Host github.com
  HostName github.com
  User git
  IdentityFile ~/.ssh/id_ed25519

Para comprobar la conectividad y verificar la clave que se está utilizando:

Verifica la conectividad SSH

Ejemplos de uso de git clone

Los ejemplos de git clone vistos hasta ahora cubren las funciones básicas que ofrece el comando.

En esta sección, te guiaré a través de las diversas opciones del comando, que te permiten adaptar el proceso de clonación de un repositorio a tu máquina local. Tanto si trabajas con ramas específicas como si optimizas la velocidad, comprender estas variaciones te ayudará a utilizar git clone de forma más eficaz.

Clonación básica del repositorio

El uso más sencillo de git clone, como hemos visto, consiste en clonar un repositorio remoto en tu máquina local.

# HTTPS protocol
git clone https://github.com/aws/aws-cli.git

# SSH protocol
git clone git@github.com:aws/aws-cli.git

Estos comandos crean una carpeta llamada «aws-cli» e inicializan una copia local del repositorio dentro de ella, con el historial de versiones y la configuración de seguimiento remoto.

Clonar en una carpeta específica

De forma predeterminada, git clone crea un directorio con el nombre del repositorio. Para especificar un nombre de directorio de destino diferente, simplemente indícalo como segundo argumento. 

Esto clona el contenido de aws-cli.git en la carpeta local denominada my-project-folder:

git clone https://github.com/aws/aws-cli.git my-project-folder

Clonar en una carpeta específica

Clonar una rama o etiqueta específica

Utiliza la bandera « --branch » (o « -b ») para comprobar la rama especificada después de clonar todas las ramas desde el control remoto. La rama especificada se convierte en la «HEAD» extraída, y las demás ramas quedan disponibles localmente para su extracción.

Utilizando nuestro ejemplo de repositorio «aws-cli», la rama predeterminada es develop.. Intentemos clonar y comprobar la rama master.

# Clone a branch
git clone --branch master https://github.com/aws/aws-cli.git

Clonar una rama específica

También podemos clonar una etiqueta específica: 

# Clone a tag (read-only snapshot)
git clone --branch 2.27.43 https://github.com/aws/aws-cli.git

Clonar una etiqueta específica

Esta bandera es útil cuando se trabaja en una rama específica relacionada con una versión o un entorno (por ejemplo, staging, hotfix o release).

Clon superficial (profundidad limitada)

Si solo necesitas la última versión del proyecto sin el historial completo de confirmaciones, utiliza la bandera --depth para realizar un clon superficial. La bandera --depth especifica cuántas confirmaciones deseas clonar.

# Download only the latest commit history
git clone --depth 1 https://github.com/aws/aws-cli.git

Clon superficial

Esto acelera el proceso de clonación y reduce el uso del disco, lo que resulta ideal para canalizaciones CI/CD o cuando no te interesa el historial de confirmaciones. Esto resulta especialmente útil para el repositorio «aws-cli» que hemos estado clonando. Dado que el repositorio «aws-cli» tiene un largo historial de confirmaciones, la diferencia de tiempo en la inclusión de la bandera « --depth » es enorme.

Diferencia de tiempo con y sin clonación superficial

Al omitir el historial de confirmaciones, excepto el más reciente, se redujo la cantidad de información que se debía descargar y, por lo tanto, se redujo el tiempo necesario.

Configuraciones avanzadas de clonación

Aunque el comando « git clone » se utiliza más comúnmente en su forma básica, Git ofrece varias opciones avanzadas que proporcionan un mayor control, eficiencia y personalización durante el proceso de clonación.

Estas características son especialmente útiles cuando se trabaja con repositorios grandes, se gestionan repositorios a nivel de infraestructura o se optimizan flujos de trabajo de desarrollo específicos. 

En esta sección, exploraremos operaciones específicas de ramas, clones superficiales y parciales, especializaciones de repositorios y configuraciones de clonación detalladas que empoderan tanto a programadores como a ingenieros de DevOps.

Operaciones de clonación específicas de ramas

De forma predeterminada, git clone recupera todas las ramas y selecciona la predeterminada. Sin embargo, cuando trabajas con repositorios grandes o contribuyes a una función específica, suele ser más eficiente clonar solo una rama. Esto se puede lograr utilizando el indicador « --single-branch ».

git clone --branch <branch-name> --single-branch <repo-url>
git clone --branch feature/cliq --single-branch https://github.com/aws/aws-cli.git

Clonar una rama específica

Las ventajas incluyen un tamaño y un tiempo de descarga reducidos, una configuración más rápida para el desarrollo de funciones específicas y la eliminación del historial de ramas innecesarias.

Este enfoque es ideal cuando deseas trabajar en una rama de lanzamiento o evitar descargar todas las ramas en repositorios CI/CD activos. Si no se especifica el nombre de la rama en el comando, Git solo clonará la rama predeterminada.

Para obtener más información sobre cómo clonar una rama específica, consulta el tutorial Clonar una rama de Git.

Tipos de repositorios especializados

Cuando clonamos un repositorio, se clonan dos componentes: el repositorio (carpeta.git ) y el directorio de trabajo. El directorio de trabajo también se conoce comúnmente como copia de trabajo, árbol de trabajo o espacio de trabajo.

Diferencia entre directorio de trabajo y repositorio

El contenido de la carpeta « .git » es el siguiente:

Contenido de la carpeta .git

Esto nos lleva al tema de los repositorios vacíos.

Repositorios vacíos

Un repositorio vacío solo contiene la carpeta .git y no tiene ningún directorio de trabajo.

git clone --bare <repo-url>
git clone --bare https://github.com/aws/aws-cli.git

Clonar un repositorio vacío

De lo anterior, podemos ver que el contenido de lo que se clonó utilizando el indicador « --bare » es simplemente el contenido de la carpeta « .git » del repositorio no básico. Como se trata de un repositorio vacío, no hay ningún directorio de trabajo, lo que significa que no podemos ejecutar los comandos git, tal y como se muestra en la siguiente imagen:

La operación debe ejecutarse en un árbol de trabajo

Los repositorios vacíos se suelen utilizar como repositorio central en un entorno compartido para la colaboración o la duplicación, más que para el desarrollo activo. Para demostrar la clonación desde el repositorio vacío, utilizaré el repositorio vacío «aws-cli» que tengo en mi equipo local.

Clonar desde mi repositorio local vacío

Podemos ver que este repositorio «aws-cli-non-bare» contiene el directorio de trabajo. Ejecuta git remote -v para comprobar que hace referencia al repositorio vacío.

Repositorios duplicados

El comando « git clone --mirror » configura un espejo del repositorio de origen. La bandera --mirror implica --bare, lo que significa que el repositorio espejo tampoco contiene un directorio de trabajo.

git clone --mirror <repo-url>
git clone --mirror https://github.com/aws/aws-cli.git

Clonar un repositorio (central) para crear un repositorio espejo

Sin embargo, en comparación con --bare, --mirror no solo asigna las ramas locales del origen a las ramas locales del destino, sino que también asigna todas las referencias (incluidas las ramas de seguimiento remoto, las notas, etc.) y configura una configuración refspec de tal manera que un git remote update en el repositorio de destino sobrescribe todas estas referencias. Esto nos proporciona una copia más completa, que incluye todas las referencias (ramas, etiquetas, etc.).

Puedes consultar la documentación de GitHub para obtener los pasos completos para duplicar un repositorio.

Duplicar un repositorio en otra ubicación. Fuente: GitHub

Filtros de clonación parcial y reducción del tamaño de los clones

Los clones parciales permiten a los usuarios recuperar solo un subconjunto de objetos del repositorio utilizando el indicador « --filter », lo que los hace muy adecuados para programadores que solo necesitan parte de una base de código, especialmente en entornos con limitaciones de ancho de banda o disco. Algunos ejemplos comunes de la bandera « --filter » son:

• --filter=blob:none: omite el contenido del archivo (blobs)
• --filter=blob:limit=: excluye archivos de un tamaño determinado y superior
• --filter=tree:: omite todos los blobs y árboles cuya profundidad desde el árbol raíz es mayor o igual que la profundidad definida.

blob:none

La bandera --filter=blob:none se utiliza para optimizar las operaciones de clonación evitando la descarga inmediata del contenido de los archivos (blobs).

# Binary Large Objects (BLOB)
git clone --filter=blob:none <repo-url>
git clone --filter=blob:none https://github.com/aws/aws-cli.git

Clonar con filtro=blob:none

Esto resulta especialmente útil en repositorios grandes o cuando solo se necesita una parte del proyecto. Por ejemplo, en monorepos, no todos los equipos o programadores necesitan toda la base de código. 

Un ingeniero frontend que trabaja únicamente en frontend/ no necesita servicios backend ni bibliotecas compartidas. El uso del indicador --filter acelera la clonación y reduce el almacenamiento al posponer la descarga de blobs hasta que sean necesarios (por ejemplo, cuando se abre el archivo). La siguiente imagen muestra lo que Git está haciendo en segundo plano cuando abro un archivo, descargando el blob del archivo bajo demanda.

Git descarga el blob del archivo cuando se solicita.

Otro ejemplo sería en los procesos de CI/CD. A menudo, las tuberías no necesitan el historial completo del repositorio ni todos los archivos. Cuando se combina con sparse-checkout, --filter=blob:none permite que el canal clone solo los directorios relevantes (por ejemplo, scripts de implementación).

blob:limit=<size>

La bandera --filter=blob:limit= es útil para programadores que desean evitar la descarga de archivos grandes (blobs) durante la clonación, sin dejar de recuperar inmediatamente los archivos más pequeños. Esto forma parte de la funcionalidad de clonación parcial de Git y resulta especialmente útil cuando se trabaja con repositorios que contienen contenido de distintos tamaños.

Por ejemplo, en algunos proyectos, especialmente aquellos que utilizan Git LFS o con activos multimedia comprometidos (por ejemplo, vídeos, grandes conjuntos de datos, activos de juegos), es posible que los programadores quieran omitir los archivos grandes durante la clonación, acelerando así la clonación inicial y aplazando la descarga de archivos grandes hasta que sean explícitamente necesarios.

# Binary Large Objects (BLOB)
git clone --filter=blob:limit=<size> <repo-url>
#  The suffixes k, m, and g can be used to name units in KiB, MiB, or GiB
git clone --filter=blob:limit=<n>[kmg] <repo-url>
git clone --filter=blob:limit=1m https://github.com/aws/aws-cli.git

Clonar con filtro=blob:límite

árbol:&lt;profundidad&gt;

La bandera ` --filter=tree: ` se utiliza para limitar la profundidad de la estructura de directorios en la que Git recupera los objetos tree durante una clonación, lo que ayuda a reducir el tamaño de la transferencia de datos, especialmente útil cuando se trabaja con proyectos muy anidados, como los monorepos. Por ejemplo, si deseas inspeccionar rápidamente una estructura monorepo grande, con fines de auditoría, incorporación o revisión, descargar árboles profundos es un desperdicio.

git clone --filter=tree:<depth> <repo-url>
git clone --filter=tree:0 https://github.com/aws/aws-cli.git

Clonar con filtro=árbol

Ten en cuenta que el servidor Git desde el que estás clonando (en este caso, GitHub) solo admite determinados valores para la profundidad del filtrado de árboles.

El filtro de árbol permite una profundidad máxima de 0.

Configuración específica para clones

Git ofrece varias opciones para personalizar el comportamiento durante la clonación:

• --origin : establece un nombre remoto personalizado en lugar de origen
• --template : utiliza un directorio de archivos de plantilla para la configuración inicial de .git.
• --single-branch: evita recuperar otras ramas
• --recurse-submodules: inicializa y clona automáticamente los submódulos.

Estas opciones son útiles cuando se configuran entornos estandarizados, se trabaja con repositorios modulares o se integra con herramientas de implementación.

origen

La bandera --origin permite a los programadores personalizar el nombre del control remoto desde el que se clona el repositorio. Por defecto, Git nombra el remoto origin, pero esta bandera te permite cambiarlo por otro nombre durante la operación de clonación.

git clone --origin <remote name> <repo-url>
# Name the remote as “upstream”
git clone --origin upstream https://github.com/aws/aws-cli.git

Cambia el nombre del remoto de origen a upstream.

Es posible que los programadores tengan que cambiar el nombre remoto para mayor claridad, ya que más adelante podrían necesitar añadir otro remoto (por ejemplo, origen ascendente frente a origen bifurcado). Cambiar el nombre del primer mando a distancia ayuda a evitar confusiones y conflictos.

plantilla

La bandera --template permite a los programadores especificar un directorio de plantillas personalizado que Git utilizará al crear el directorio .git en el repositorio recién clonado. Los directorios de plantillas te permiten predefinir enlaces, archivos de configuración o estructuras de directorios que se aplican automáticamente al repositorio durante la inicialización.

# Specify the directory from which templates will be used
git clone --template=<template-directory> <repo>
git clone --template=./git-template https://github.com/aws/aws-cli.git

Uso de la bandera --template

Trataré el tema de la bandera de plantilla con más detalle en la sección «Aplicación del directorio de plantillas».

rama única

La bandera ` --single-branch ` se utiliza para clonar solo el historial de la rama especificada, en lugar de todas las ramas del repositorio remoto. Esto puede reducir significativamente la cantidad de datos clonados, especialmente en repositorios con muchas ramas de larga duración o un historial de confirmaciones extenso.

Cuando se te asigna trabajar en una función específica o en una rama de lanzamiento (por ejemplo, feature/login-ui, release/v2.0), no es necesario clonar el historial de otras ramas no relacionadas.

git clone --branch feature/login-ui --single-branch <repo-url>

# If you do not specify a branch, Git will clone only the remote's default branch, usually main or master
git clone --single-branch <repo-url>
git clone --single-branch https://github.com/aws/aws-cli.git

Un programa típico de control de versiones como git clone realiza un seguimiento de todas las ramas remotas, tal y como se muestra en la salida de git branch -r a continuación.

Se realiza un seguimiento de todas las ramas remotas.

Mientras que la adición de --single-branch lona solo la historia de la rama especificada.

Solo se realiza un seguimiento de la rama predeterminada.

recurse-submodules

Los submódulos Git son una referencia a otro repositorio, fijados a una confirmación específica. Te permite mantener el otro repositorio Git como un subdirectorio de tu repositorio Git, lo que se suele utilizar para incluir código de terceros, bibliotecas compartidas o componentes específicos de un proveedor. 

He creadoun repositorio público en GitHub para demostrar este concepto.

Demostrar submódulos

Cuando clonamos un proyecto que contiene un submódulo, por defecto obtenemos los directorios que contienen los submódulos, pero no los archivos que hay dentro de ellos.

Carpeta de submódulos vacía

En lugar de ejecutar « git submodule init » para inicializar tu archivo de configuración local y « git submodule update » para recuperar todos los datos de ese proyecto, podemos utilizar el indicador « --recurse-submodules » con el comando « git clone » para inicializar y clonar automáticamente todos los submódulos definidos en el archivo « .gitmodules » de un repositorio.

git clone --recurse-submodules <repo-url>

Clonar archivos dentro del directorio del submódulo

Aplicación de directorio de plantillas

Git permite el uso de directorios de plantillas para definir enlaces predeterminados, configuraciones y otros archivos durante la clonación o la inicialización del repositorio:

La estructura del directorio de plantillas puede ser similar a la siguiente, con hooks/pre-commit que contiene un script de terminal para bloquear las confirmaciones sin un ID de JIRA, y hooks/commit-msg que contiene la plantilla para los mensajes de confirmación.

/home/devops/git-template/
├── config
├── description
├── hooks/
│   ├── pre-commit
│   └── commit-msg
├── info/
│   └── exclude

Una vez definidos los archivos necesarios en el directorio de plantillas, puedes utilizarlos para tus operaciones de clonación git.

git clone --template=</path/to/template> <repo-url>
git clone --template=/home/devops/git-template https://github.com/aws/aws-cli.git

Esto es ideal para:

• Aplicación de políticas de repositorios mediante hooks (por ejemplo, pre-commit)
• Predefinición de archivos de configuración para CI/CD o herramientas
• Proyectos de arranque con una estructura común

Los directorios de plantillas agilizan los flujos de trabajo en equipo y garantizan la coherencia entre los repositorios clonados.

Clonación en diferentes sistemas operativos

Aunque el comando « git clone » funciona básicamente igual en todas las plataformas, la experiencia puede variar ligeramente en función del sistema operativo.

Las consideraciones específicas del entorno, como las herramientas de terminal, los formatos de ruta de archivo y el manejo de permisos, pueden afectar la forma en que los programadores interactúan con Git. En esta sección, te guiaré por el proceso de clonación en Windows, Linux/Ubuntu y macOS para ayudarte a resolver cualquier duda.

Ventanas

En Windows, los programadores suelen utilizar Git Bash, PowerShell o el símbolo del sistema para ejecutar los comandos de Git. Podemos instalar Git desde la página de descargas, que viene junto con Git Bash, un terminal similar a Unix diseñado para el uso de Git en Windows.

git clone en Git Bash

git clone en PowerShell

Algunas consideraciones a tener en cuenta:

• Las rutas de archivo en Git Bash utilizan el formato de Unix (/c/Users/username/), mientras que PowerShell y el símbolo del sistema utilizan el formato de Windows (C:\Users\username\).
• Si utilizas PowerShell, asegúrate de que Git está añadido a la ruta PATH de tu sistema.

Linux/Ubuntu

Las distribuciones de Linux como Ubuntu ofrecen una experiencia Git perfecta a través de su terminal nativa. Para el siguiente ejemplo, he creado una instancia EC2 de Ubuntu en AWS y me he conectado a ella a través de SSH.

Conéctate mediante SSH a la instancia EC2 de Ubuntu.

Git se ha instalado de forma predeterminada. No obstante, si no aparece en tu sistema, simplemente ejecuta el comando « sudo apt install git ».

Instalar git en Ubuntu

Navega hasta el directorio deseado y ejecuta el comando « git clone ».

git clone en Ubuntu

Algunas consideraciones a tener en cuenta:

• Asegúrate de que las claves SSH estén correctamente configuradas para los repositorios privados (~/.ssh/id_rsa).
• Los permisos de archivo y la propiedad de los directorios pueden afectar a las operaciones del repositorio, especialmente al clonar en rutas de nivel del sistema.

Mac

macOS ofrece un entorno basado en Unix muy similar a Linux, lo que hace que las operaciones con Git sean intuitivas. Git suele venir preinstalado. Si no es así, al instalar las herramientas de línea de comandos de Xcode (xcode-select --install) también se instalará Git.

Abre Terminal y ejecuta el comando « git clone ».

git clone en Mac

Algunas consideraciones a tener en cuenta:

• Al igual que con Linux, la gestión de claves SSH es importante para los repositorios privados.
• Los usuarios de macOS suelen utilizar clientes GUI como GitHub Desktop o Sourcetree; asegúrate de que la configuración subyacente de Git sea correcta.

Escenarios prácticos de implementación

Aunque git clone se utiliza a menudo para obtener simplemente una copia de un repositorio, su utilidad va mucho más allá en los flujos de trabajo de ingeniería del mundo real. 

En esta sección, examino cómo se pueden aplicar las estrategias de clonación en escenarios prácticos, cada uno de los cuales requiere un enfoque personalizado para maximizar la eficiencia y la coherencia.

Flujo de trabajo de desarrollo empresarial

En grandes organizaciones, la clonación eficiente de repositorios es crucial para agilizar la incorporación de programadores y estandarizar la configuración de proyectos. Se pueden adoptar las siguientes estrategias:

• En primer lugar, los clones superficiales (--depth=1). Se utiliza a menudo para reducir el tiempo de configuración de los nuevos programadores que no necesitan el historial completo de confirmaciones.
• En segundo lugar, los repositorios de plantillas. No confundir con los directorios de plantillas. Los repositorios de plantillas contienen estructuras de carpetas predefinidas, enlaces y submódulos que se pueden clonar para iniciar rápidamente un proyecto. En GitHub, puedes habilitar un repositorio como repositorio de plantillas en la configuración.

Configuración del repositorio de plantillas

Después de habilitarla, encontrarás el botón «Usar esta plantilla» en la página de inicio de tu repositorio.

Utiliza el repositorio como plantilla.

• Por último, disponer de espejos internos de repositorios externos reduce la dependencia de redes públicas y acelera la clonación en entornos seguros.

Procedimiento de migración del repositorio

Las organizaciones pueden migrar repositorios entre plataformas (por ejemplo, de GitHub a GitLab) por diversos motivos, entre ellos, cuestiones de seguridad, cumplimiento normativo o consideraciones financieras. La migración requerirá un clon espejo para garantizar una copia completa, incluyendo todas las ramas, etiquetas e historial de confirmaciones.

Un proceso típico puede ser el siguiente:

# --mirror flag clones all refs and configuration.
git clone --mirror https://source-url.com/your-repo.git
cd your-repo.git
git push --mirror https://target-url.com/your-new-repo.git

Este método conserva mejor los metadatos de Git que un clon estándar seguido de un push. Después de la migración, actualiza las URL remotas y verifica los permisos de acceso.

Optimización del proceso de CI/CD

En entornos automatizados, la optimización de las operaciones de clonación ahorra tiempo y reduce el uso de recursos, especialmente en implementaciones de alta frecuencia. Podemos seguir estas prácticas recomendadas para garantizar un flujo eficiente del proceso:

• En primer lugar, utiliza clones superficiales (--depth=1) para acelerar los tiempos de inicio de los trabajos.

git clone --depth 1 <repository-url>

• En segundo lugar, clona solo la rama necesaria para evitar referencias innecesarias.

git clone --branch <branch-name> --single-branch <repo-url>

• Por último, si varias etapas de tu canalización de CI/CD requieren acceso al mismo contenido del repositorio, considera la posibilidad de implementar un mecanismo de almacenamiento en caché para evitar operaciones repetidas de git clone. En lugar de clonar el repositorio en cada etapa, almacena en caché el directorio de trabajo después de la comprobación inicial y pásalo como un artefacto o volumen compartido a las etapas siguientes. 

Este enfoque reduce significativamente las operaciones redundantes, acelera la ejecución del proceso y conserva los recursos informáticos y de red.

Solución de problemas y diagnóstico

Aunque git clone es un comando muy utilizado y sencillo, los programadores pueden encontrar ocasionalmente problemas durante el proceso de clonación, especialmente en entornos con controles de autenticación estrictos, configuraciones de repositorios personalizadas o acceso limitado a la red.

En esta sección, voy a repasar los problemas más comunes que se plantean al clonar y cómo resolverlos de manera eficaz.

Resolución de errores de autenticación

Los errores de autenticación suelen producirse al acceder a repositorios privados o al utilizar credenciales caducadas. Dependiendo del protocolo, HTTPS o SSH, se aplican diferentes mensajes de error y soluciones. En entornos compatibles con MFA, siempre es preferible utilizar SSH o HTTPS con PAT.

En el caso de HTTPS, un error común es el fallo de autenticación. Esto puede deberse al uso de un token de acceso personal caducado. Si la autenticación multifactor (MFA) está habilitada, otra posible razón es que no se utilizó el token de acceso personal como contraseña.

Error de autenticación HTTPS

En el caso de SSH, un error habitual sería el mensaje «Permiso denegado (clave pública)». Esto puede deberse a que la clave pública no se ha añadido a la cuenta del proveedor de Git o a que la clave privada almacenada en tu dispositivo local no se encuentra en el directorio correcto.

Error de autenticación SSH

Puedes validar la conectividad con:

ssh -T git@github.com

Recuperación parcial de objetos clonados

En raras ocasiones, al utilizar clones parciales (--filter o --depth ), es posible que encuentres objetos que faltan (por ejemplo, «error: object &lt;sha&gt; is missing») si Git intenta acceder a partes del repositorio que no se recuperaron inicialmente.

Nunca me había encontrado en esta situación. No obstante, es posible que encuentres errores al acceder a confirmaciones, ramas o etiquetas históricas. Si esto está en una canalización, las herramientas o scripts de compilación podrían fallar. Puedes recuperar explícitamente los datos que faltan utilizando:

# Have Git refetch all objects from the remote, even if it thinks it already has them.
# For dealing with a broken or corrupted partial clone
git fetch --filter=blob:none --refetch

# Convert a shallow clone into a full clone. Retrieves the rest of the commit history that was omitted during the shallow clone.
git fetch --unshallow

# Obtain a deeper history of the branch
git fetch origin <branch> --depth=50

# Fetches 30 more commits from the current branch’s history. Repeat as needed.
git fetch --deepen=30

Haz que Git vuelva a recuperar todos los objetos del control remoto

Mensajes de error comunes de git clone y soluciones

Además de los problemas anteriores que podrías encontrar durantela instalación de git clone, la siguiente tabla cubre otros errores comunes.

Conclusión

El comando « git clone » puede parecer sencillo a primera vista y, para muchos, su uso básico ha sido suficiente. Sin embargo, como ha demostrado este artículo, se trata de una herramienta fundamental con aplicaciones de gran alcance. 

Hemos explicado cómo funciona git clone, hemos explorado los tipos de URL y los protocolos, hemos repasado configuraciones avanzadas y comportamientos específicos de cada sistema operativo, y hemos examinado escenarios reales, como CI/CD, flujos de trabajo empresariales y técnicas comunes de resolución de problemas.

Adaptar git clone a tu entorno, ya sea para clones superficiales en canalizaciones, migraciones de repositorios o colaboraciones a gran escala, puede aumentar significativamente el rendimiento y la eficiencia del equipo. A medida que los entornos de desarrollo modernos se vuelven cada vez más complejos y distribuidos, dominar estas configuraciones garantiza que no solo estés utilizando Git, sino que también lo estés haciendo de forma eficaz.

De cara al futuro, se pueden mejorar los mecanismos de clonación de Git, como clones parciales más inteligentes, mejor compatibilidad con monorepos grandes y un manejo más intuitivo de los submódulos y filtros. A medida que Git evoluciona, estar al día de estas mejoras permitirá a los programadores trabajar de forma más rápida y eficiente en cualquier sistema o escala.

Para obtener más información sobre Git, te recomiendoque realices el curso Introducción a Git. Si quieres llevar tus habilidades al siguiente nivel, ¡el curso Avanzado de Git es para ti!