Un git clone crea una copia de trabajo y generalmente añade el repositorio remoto bajo el nombre origin. La trampa llega antes del primer comando: una URL SSH utiliza tu clave, una URL HTTPS a menudo solicita un token, y la carpeta de destino no debe contener ya archivos útiles. Tómate dos minutos para verificar estos tres puntos antes de lanzar un script recuperado en línea.
Elegir HTTPS o SSH antes de clonar
Utiliza HTTPS para recuperar un proyecto público o cuando no deseas configurar una clave en esta máquina. Para luego subir a GitHub, GitLab o tu forja, la contraseña de la cuenta generalmente ya no es suficiente: el servicio solicita un token de acceso personal.
Utiliza SSH si tu clave pública ya está asociada a tu cuenta en la forja. Este método evita volver a escribir un token, pero falla si se propone la clave equivocada o si el agente SSH no la carga. Comienza por leer la identidad utilizada:
ssh -T [email protected]
ssh-add -lAdapta el primer host a tu forja. Una respuesta de autenticación sin shell remoto es normal en varios proveedores de Git. Si gestionas varias claves, controla tu archivo ~/.ssh/config con ssh -G [email protected] antes de acusar a Git. Nuestra guía para configurar SSH para varios servidores explica cómo fijar una clave y una cuenta por alias.
Crear la copia en una carpeta vacía e identificable
Colócate en un directorio reservado para tus proyectos. Sin segundo argumento, Git crea una carpeta a partir del nombre del repositorio. Con un nombre explícito, evitas confundir una copia de prueba con la que contiene tus modificaciones.
mkdir -p ~/proyectos
cd ~/proyectos
pwd
ls -la
git clone https://github.com/octocat/Hello-World.git hello-test
cd hello-testNo inicies un clon en una carpeta cuyo contenido no conoces. Git generalmente rechaza un directorio no vacío, pero es más seguro verificar pwd y ls -la antes del comando. Para una copia destinada solo a leer el código, HTTPS sigue siendo la opción más sencilla.
Con SSH, la misma operación se parece a esto:
git clone [email protected]:mi-cuenta/mi-proyecto.git mi-proyecto
cd mi-proyectoReemplaza el host, la cuenta y el repositorio por los valores mostrados por tu forja. Nunca copies una URL recibida en un mensaje dudoso. Abre primero la página oficial del proyecto y compara el propietario, el nombre del repositorio y la URL de clonación.
Controlar el remoto y los archivos antes de ejecutar cualquier cosa
Después del clon, verifica el origen, la rama activa y el estado del directorio. Estos comandos no modifican el proyecto:
git remote -v
git branch --show-current
git status
git log -1 --oneline
find . -maxdepth 2 -type f -name 'README*' -o -name 'INSTALL*'git remote -v muestra las URLs utilizadas para recuperar y enviar los cambios. Verifícalas antes de un primer git push, especialmente si el proyecto contiene una configuración de despliegue. Luego lee el README, los archivos INSTALL, las dependencias y los scripts de inicio. Un repositorio Git puede contener un script válido, antiguo o francamente arriesgado; no adquiere tu confianza solo porque el clon haya tenido éxito.
Para recuperar una actualización más tarde, permanece en la carpeta clonada y comienza por controlar tu trabajo:
git status
git fetch origin
git log --oneline HEAD..origin/$(git branch --show-current)
git pull --ff-onlygit pull --ff-only se niega a una fusión automática si tus commits locales y el repositorio remoto divergen. Es preferible a una actualización que mezcle cambios cuando aún no has revisado la rama ni el remoto.
La documentación oficial de git clone detalla las opciones como --depth, --branch y --recurse-submodules. Guárdalas para una necesidad identificada. Para un primer clon, una URL verificada, una carpeta limpia y la lectura del README ya evitan la mayoría de los errores.