A git clone creates a working copy and generally adds the remote repository under the name origin. The catch comes before the first command: an SSH URL uses your key, an HTTPS URL often requires a token, and the target folder must not already contain useful files. Take two minutes to check these three points before running a script retrieved online.
Choose HTTPS or SSH before cloning
Use HTTPS to fetch a public project or when you do not want to set up a key on this machine. To push later to GitHub, GitLab, or your forge, the account password is usually no longer sufficient: the service requires a personal access token.
Use SSH if your public key is already associated with your account on the forge. This method avoids retyping a token, but it fails if the wrong key is presented or if the SSH agent does not load it. Start by checking the identity used:
ssh -T [email protected]
ssh-add -lAdjust the first host to your forge. An authentication response without a remote shell is normal with several Git hosts. If you manage multiple keys, check your ~/.ssh/config file with ssh -G [email protected] before blaming Git. Our guide to configuring SSH for multiple servers explains how to fix a key and an account by alias.
Create the copy in an empty and identifiable folder
Make sure you are in a directory reserved for your projects. Without a second argument, Git creates a folder from the name of the repository. With an explicit name, you avoid confusing a test copy with the one containing your changes.
mkdir -p ~/projets
cd ~/projets
pwd
ls -la
git clone https://github.com/octocat/Hello-World.git hello-test
cd hello-testDo not initiate a clone in a folder whose contents you do not know. Git generally refuses a non-empty directory, but it is safer to check pwd and ls -la before the command. For a copy intended only to read the code, HTTPS remains the simplest choice.
With SSH, the same operation looks like this:
git clone [email protected]:mon-compte/mon-projet.git mon-projet
cd mon-projetReplace the host, account, and repository with the values displayed by your forge. Never copy a URL received in a suspicious message. First, open the official project page and compare the owner, the repository name, and the cloning URL.
Check the remote and files before executing anything
After the clone, check the origin, the active branch, and the state of the directory. These commands do not modify the project:
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 displays the URLs used to fetch and send changes. Check them before an initial git push, especially if the project contains a deployment configuration. Then read the README, INSTALL files, dependencies, and startup scripts. A Git repository may contain a valid script, old or frankly risky; it does not earn your trust just because the clone was successful.
To fetch an update later, remain in the cloned folder and start by checking your work:
git status
git fetch origin
git log --oneline HEAD..origin/$(git branch --show-current)
git pull --ff-onlygit pull --ff-only refuses an automatic merge if your local commits and the remote repository diverge. This is preferable to an update that mixes changes when you have not yet looked at the branch or the remote.
The official documentation for git clone details options like --depth, --branch, and --recurse-submodules. Keep them for an identified need. For a first clone, a verified URL, a clean folder, and reading the README already avoid most errors.