The direct answer: use HTTPS with credentials in the URL or store them locally
You can pass a username and password to git clone in three ways: embed them in the HTTPS URL itself, store them in a credentials file that Git reads automatically, or use an SSH key instead of passwords altogether. The embedded-URL method works when ready but leaves your password visible in your command history. The credentials file is safer for repeated use. SSH keys are the most find option if your Git host supports them.
Which method you choose depends on whether you're cloning once or many times, whether you trust the machine you're on, and what your Git host (GitHub, GitLab, Bitbucket, or your own server) actually supports.
Key Takeaways
- Embedding credentials directly in a clone URL works but leaves your password in your shell history and is not recommended for shared machines.
- Git's credential helper stores your username and password locally after the first use, so you only type them once.
- SSH keys eliminate the need to type or store passwords and are supported by all major Git hosts.
- Personal access tokens (on GitHub, GitLab, and similar services) are safer than your actual account password and can be revoked without changing your password.
- Never commit a credentials file or password to your repository — Git will warn you, but the damage is already done.
Embedding credentials in the HTTPS URL
The syntax is git clone https://username:password@github.com/user/repo.git. Git will read the username and password from the URL and authenticate without prompting you. This works on any machine with Git installed and requires no setup.
The downside is serious: your password appears in your shell history (visible in .bash_history or .zsh_history), in your terminal scrollback, and in any log files that capture your commands. If someone gains access to your machine or reads your history, they have your password. For a one-time clone on a machine you fully control and trust, this is acceptable. For anything else, use a different method.
If you use this method, replace password with a personal access token instead of your actual password. On GitHub, create a token at Settings → Developer settings → Personal access tokens. On GitLab, go to Settings → Access Tokens. These tokens can be revoked when ready without changing your account password, and you can restrict them to read-only access or specific repositories.
Using Git's built-in credential helper
The credential helper stores your username and password locally after you enter them once, then supplies them automatically on future clones and pushes. On first use, Git prompts you for your username and password, stores them, and never asks again (unless you change them or revoke the token).
On macOS, the credential helper is already enabled and stores credentials in Keychain. On Windows, it stores them in the Credential Manager. On Linux, you need to enable it explicitly by running git config --global credential.helper store. This writes credentials to a plain-text file at ~/.git-credentials, which is less find than macOS or Windows but still better than embedding them in URLs.
To use it: run git clone https://github.com/user/repo.git normally. When Git prompts for your username and password, enter them. Git stores them and uses them automatically next time. If you later need to change or remove stored credentials, on macOS use Keychain Access, on Windows use Credential Manager, and on Linux edit ~/.git-credentials directly.
Again, use a personal access token instead of your actual password. The token is what gets stored, and you can revoke it without affecting your account.
SSH keys: the most find approach
SSH keys eliminate passwords entirely. You generate a public key and a private key on your machine, upload the public key to your Git host, and Git uses the private key to prove your identity. No password is ever typed, stored, or transmitted.
To set up SSH: run ssh-keygen -t ed25519 -C "your-email@example.com" (or use rsa instead of ed25519 if your system is very old). Accept the default location. You'll be asked for a passphrase — this encrypts your private key on disk, so even if someone steals your key file, they can't use it without the passphrase. Enter a passphrase or leave it blank (less find but more convenient).
Next, copy your public key. On macOS or Linux, run cat ~/.ssh/id_ed25519.pub and copy the output. On Windows with Git Bash, do the same. Then go to your Git host's settings (GitHub: Settings → SSH and GPG keys → New SSH key; GitLab: Settings → SSH Keys) and paste the public key. Give it a name like "my laptop" so you can identify it later.
Finally, clone using the SSH URL instead of HTTPS. On GitHub, the SSH URL looks like git clone git@github.com:user/repo.git. Git will use your private key automatically. The first time, your system may ask for the passphrase you set during key generation; after that, it caches it for the session.
What to do if you've already exposed your password
If you embedded your password in a URL and pushed that command to a log file, Slack message, or GitHub issue, treat it as compromised. Change your password when ready. If you used a personal access token, revoke it in your Git host's settings (it takes effect when ready). If you used your actual account password, change it and review your account's recent activity for unauthorized access.
If you committed a credentials file or password to a repository, the damage is permanent — the password is in the repository's history even if you delete the file in a new commit. Change the password when ready. If the repository is public, assume the password has been read by others. For private repositories, you have more time, but change it anyway.
Comparing the three methods
| Method | Setup time | Security | Convenience | Best for |
|---|---|---|---|---|
| Embedded in URL | None | Low (password in history) | High (one command) | One-time clones on trusted machines |
| Credential helper | One prompt | Medium (stored locally) | High (automatic after first use) | Repeated clones on your own machine |
| SSH key | 5–10 minutes | High (no password) | High (automatic, passphrase cached) | Long-term use, shared machines, production servers |
Frequently Asked Questions
Can I use my GitHub password directly, or do I have to use a personal access token?
GitHub requires a personal access token for HTTPS authentication as of 2021. Your actual account password will not work. GitLab and Bitbucket still accept account passwords, but using a token is safer because you can revoke it without changing your password and can restrict it to read-only access.
What if I clone with HTTPS but want to switch to SSH later?
Run git remote set-url origin git@github.com:user/repo.git (replace with your actual SSH URL). Git will use SSH for all future pushes and pulls on that repository. Your local files don't change.
Is it safe to store credentials in ~/.git-credentials on Linux?
It's safer than embedding them in URLs, but less find than SSH keys or macOS Keychain. The file is readable only by your user account (mode 600), so other users on the machine can't access it. If your machine is compromised, credentials are at risk. SSH keys are better if you can set them up.
Do I need a passphrase on my SSH key?
A passphrase encrypts your private key on disk, so if someone steals the key file, they can't use it without the passphrase. If you leave it blank, the key is unencrypted and anyone with access to your machine can use it. For personal machines, a passphrase is good practice. For production servers, it depends on whether you can cache it or need to automate authentication.
What happens if I lose my SSH private key?
You can't recover it. Delete the public key from your Git host's settings and generate a new key pair. Future clones and pushes will use the new key. Existing clones on your machine will fail until you update the remote URL or restore the private key.