Un git clone crea una copia de trabajo y generalmente agrega el repositorio remoto bajo el nombre origin. El problema aparece 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 ejecutar un script descargado en línea.
Elegir HTTPS o SSH antes de clonar
Usa HTTPS para recuperar un proyecto público o cuando no deseas configurar una clave en esta máquina. Luego, para hacer un push a GitHub, GitLab o tu forge, generalmente la contraseña de la cuenta ya no es suficiente: el servicio requiere un token de acceso personal.
Usa SSH si tu clave pública ya está asociada a tu cuenta en la forge. Este método evita volver a escribir un token, pero falla si se ofrece la clave incorrecta 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 forge. Una respuesta de autenticación sin un 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 un directorio vacío e identificable
Colócate en un directorio reservado para tus proyectos. Sin un segundo argumento, Git crea una carpeta con el nombre del repositorio. Con un nombre explícito, evitas confundir una copia de prueba con aquella 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 clone 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 ve así:
git clone [email protected]:mi-cuenta/mi-proyecto.git mi-proyecto
cd mi-proyectoSustituye el host, la cuenta y el repositorio por los valores que muestra tu forge. 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 clone, 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 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 riesgoso, no adquiere tu confianza porque el clone 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 rechaza una fusión automática si tus commits locales y el repositorio remoto divergen. Es preferible a una actualización que mezcla cambios mientras 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 clone, una URL verificada, una carpeta limpia y la lectura del README ya evitan la mayoría de los errores.