Un git clone crea una copia di lavoro e aggiunge generalmente il repository remoto con il nome origin. La trappola si presenta prima del primo comando: un’URL SSH usa la tua chiave, un’URL HTTPS richiede spesso un token e la cartella di destinazione non deve già contenere file utili. Prenditi due minuti per verificare questi tre punti prima di lanciare uno script scaricato online.
Scegliere HTTPS o SSH prima di clonare
Utilizza HTTPS per recuperare un progetto pubblico o quando non vuoi configurare una chiave su questa macchina. Per successivamente inviare su GitHub, GitLab o il tuo forge, la password dell’account spesso non è più sufficiente: il servizio richiede un token di accesso personale.
Utilizza SSH se la tua chiave pubblica è già associata al tuo account sul forge. Questo metodo evita di reinserire un token, ma fallisce se viene proposta la chiave sbagliata o se l’agente SSH non la carica. Inizia a leggere l’identità utilizzata:
ssh -T [email protected]
ssh-add -lAdatta il primo host al tuo forge. Una risposta di autenticazione senza shell remota è normale presso diversi host Git. Se gestisci più chiavi, controlla il tuo file ~/.ssh/config con ssh -G [email protected] prima di incolpare Git. La nostra guida per configurare SSH per più server spiega come fissare una chiave e un account per alias.
Creare la copia in una cartella vuota e identificabile
Posizionati in una directory riservata ai tuoi progetti. Senza un secondo argomento, Git crea una cartella dal nome del repository. Con un nome esplicito, eviti di confondere una copia di test con quella che contiene le tue modifiche.
mkdir -p ~/progetti
cd ~/progetti
pwd
ls -la
git clone https://github.com/octocat/Hello-World.git hello-test
cd hello-testNon avviare un clone in una cartella di cui non conosci il contenuto. Git rifiuta generalmente una directory non vuota, ma è comunque più sicuro controllare pwd e ls -la prima del comando. Per una copia destinata solo alla lettura del codice, HTTPS rimane la scelta più semplice.
Con SSH, la stessa operazione assomiglia a questa:
git clone [email protected]:mon-compte/mon-projet.git mon-progetto
cd mon-progettoSostituisci l’host, l’account e il repository con i valori visualizzati dal tuo forge. Non copiare mai un’URL ricevuta in un messaggio sospetto. Apri prima la pagina ufficiale del progetto e confronta il proprietario, il nome del repository e l’URL di clonazione.
Controllare il remote e i file prima di eseguire qualsiasi cosa
Dopo il clone, verifica l’origine, il ramo attivo e lo stato della directory. Questi comandi non modificano il progetto:
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 mostra gli URL utilizzati per recuperare e inviare le modifiche. Controllali prima di un primo git push, soprattutto se il progetto contiene una configurazione di deployment. Leggi poi il README, i file INSTALL, le dipendenze e gli script di avvio. Un repository Git può contenere uno script valido, obsoleto o decisamente rischioso, non acquisisce la tua fiducia solo perché il clone ha avuto successo.
Per recuperare un aggiornamento più tardi, rimani nella cartella clonata e inizia a controllare il tuo lavoro:
git status
git fetch origin
git log --oneline HEAD..origin/$(git branch --show-current)
git pull --ff-onlygit pull --ff-only rifiuta una fusione automatica se i tuoi commit locali e il repository remoto divergono. Questo è preferibile a un aggiornamento che mescola modifiche mentre non hai ancora guardato il ramo né il remote.
La documentazione ufficiale di git clone dettaglia le opzioni come --depth, --branch e --recurse-submodules. Conservale per una necessità identificata. Per un primo clone, un’URL verificata, una cartella pulita e la lettura del README evitano già la maggior parte degli errori.