Setting Up Your First Git Connection to a Remote Repository

What a Git connection actually does

A Git connection links your local folder on your computer to a remote repository — usually on GitHub, GitLab, or another hosting service. Once connected, you can push your work up to the remote and pull changes down from it. The connection itself is just configuration: Git stores the remote's web address and your authentication details so it knows where to send your code and how to prove you have permission to do it.

You establish this connection once per repository. After that, every time you push or pull, Git uses the stored connection details automatically. If you're starting from scratch, you'll create a new repository locally, add a remote address, and authenticate. If you're cloning an existing repository, Git sets up the connection for you in one step.

Key Takeaways

A Git connection requires three things: a remote repository URL, a way to prove your identity (SSH key or personal access token), and a local folder where Git is initialized.
SSH keys are more secure than passwords because they use cryptography instead of a string you type, and they don't expire unless you delete them.
Personal access tokens work over HTTPS and are easier to set up if you're behind a corporate firewall, but they expire and need renewal.
You can test your connection before pushing real work by running git remote -v to see what Git has stored, and ssh -T git@github.com (or your host) to verify authentication works.

SSH keys versus personal access tokens

SSH keys and personal access tokens are the two main ways to prove your identity to a remote repository. SSH uses a pair of files — a private key that stays on your computer and a public key that you upload to the hosting service. When you push or pull, Git uses the private key to sign a request, and the remote checks it against the public key you uploaded. This works over SSH protocol and is the default for most developers.

Personal access tokens are strings of characters that you generate on the hosting service (GitHub, GitLab, etc.) and paste into Git when prompted. They work over HTTPS protocol and are simpler to set up if you're on a network that blocks SSH. The trade-off is that tokens expire — GitHub tokens last 90 days by default, though you can set them longer — and you have to regenerate and re-enter them when they expire.

For a first connection, SSH is more convenient long-term because you set it up once and it doesn't expire. But if you're on a corporate network or behind a firewall that blocks SSH port 22, HTTPS with a token is often your only option. Check your network policy or ask your IT team if you're unsure which protocol is allowed.

Creating and uploading an SSH key

To create an SSH key, open your terminal or command prompt and run ssh-keygen -t ed25519 -C "your.email@example.com". Replace the email with your actual email. The tool will ask where to save the key — press Enter to accept the default location (usually ~/.ssh/id_ed25519 on Mac and Linux, C:\Users\YourName\.ssh\id_ed25519 on Windows). It will then ask for a passphrase. You can leave this blank for convenience, or enter one for extra security — if you use a passphrase, you'll type it once per session, not every time you push.

After the key is created, you need to upload the public key to your hosting service. The public key is in the same folder with a .pub extension. On GitHub, go to Settings → SSH and GPG keys → New SSH key, then paste the entire contents of your id_ed25519.pub file into the box. GitLab and other services have similar pages — look for "SSH keys" in account settings. Give the key a name like "My Laptop" so you can identify it later if you need to delete it.

Once uploaded, test the connection by running ssh -T git@github.com (replace github.com with your hosting service if different). If it works, you'll see a message like "Hi username! You've successfully authenticated." If it fails, check that you pasted the entire public key, including the ssh-ed25519 part at the start.

Connecting a local repository to a remote

If you already have a folder with Git initialized on your computer, you add the remote connection by running git remote add origin https://github.com/username/repository-name.git (use the SSH URL if you set up SSH keys, or the HTTPS URL if you're using a token). Replace username and repository-name with the actual values from your hosting service. The word origin is the default name for the main remote — you can use a different name, but origin is the convention.

To find the correct URL, go to your repository on GitHub, GitLab, or your hosting service and click the green Code button (or equivalent). Copy the SSH URL if you have SSH keys set up, or the HTTPS URL if you're using a token. Paste it into the command above.

After adding the remote, verify it was stored correctly by running git remote -v. You should see two lines: one labeled origin with (fetch) and one with (push), both pointing to the same URL. If you see nothing, the remote wasn't added. If you see the wrong URL, delete it with git remote remove origin and add the correct one.

Cloning an existing repository

If you're working with a repository that already exists on GitHub or another hosting service, you don't set up the connection manually — cloning does it for you. Run git clone https://github.com/username/repository-name.git (or the SSH URL). Git will create a new folder with the repository name, download all the code and history, and automatically add the remote as origin pointing back to where you cloned from.

After cloning, you're ready to work immediately. You can start making changes, committing them, and pushing them back to the remote. The only exception is if the repository is public but you don't have write permission — in that case, you can pull and view the code, but pushing will fail with a permission error. If you want to contribute to someone else's repository, you typically fork it first (create your own copy on the hosting service), clone your fork, and then submit a pull request to the original.

Authenticating with a personal access token over HTTPS

If you're using HTTPS instead of SSH, you'll need a personal access token. On GitHub, go to Settings → Developer settings → Personal access tokens → Tokens (classic), then click Generate new token. Give it a name, set an expiration date (or choose no expiration if your organization allows it), and check the repo scope to allow pushing and pulling. Click Generate and copy the token immediately — you won't be able to see it again.

When you push or pull for the first time, Git will prompt you for a username and password. Enter your GitHub username as the username, and paste the token as the password. Git will store this in your system's credential manager so you don't have to re-enter it every time. On Mac, it's stored in Keychain; on Windows, in Credential Manager; on Linux, you may need to set up a credential helper.

When your token expires, GitHub will reject your push or pull with an authentication error. Generate a new token, update it in your credential manager (or delete the old one and let Git prompt you again), and you're back in business. This is more maintenance than SSH, but it's the right choice if your network blocks SSH or if your organization requires it.

Troubleshooting a failed connection

If you get a "permission denied" error when pushing, the most common cause is that your authentication isn't set up correctly. For SSH, run ssh -T git@github.com to test the connection directly — if it fails, your SSH key either wasn't uploaded or wasn't created correctly. For HTTPS, make sure you're using a token that hasn't expired and that you've pasted it correctly into your credential manager.

If you get a "repository not found" error, check that the repository URL is spelled correctly and that you have permission to access it. A common mistake is using the wrong username or repository name in the URL. Copy the URL directly from the hosting service's Code button rather than typing it by hand.

If you added the wrong remote by accident, delete it with git remote remove origin and add the correct one. If you're not sure what's stored, run git remote -v to see all remotes and their URLs. You can also change a remote's URL without deleting it by running git remote set-url origin [new-url].

Frequently Asked Questions

Can I use the same SSH key on multiple computers?

Yes, but it's not recommended. If one computer is compromised, the attacker has access to all your repositories. A better approach is to generate a separate key on each computer and upload each public key to your hosting service. You can name them "Laptop", "Desktop", "Work Machine", etc., so you know which one to delete if a computer is lost or stolen.

What if I lose my SSH private key?

You'll need to generate a new key and upload the new public key to your hosting service. Delete the old key from your account settings so it can't be used. If you had a passphrase on the old key, the new key is still secure even if someone finds the old file on your hard drive — they can't use it without the passphrase.

Do I need a different remote for each branch?

No. A single remote points to the entire repository, including all branches. When you push or pull, you specify which branch to push or pull, but the remote address stays the same. You can have multiple remotes (for example, origin pointing to your fork and upstream pointing to the original repository), but most projects use just one.

Can I change my remote URL after I've already pushed?

Yes. Run git remote set-url origin [new-url] to change where Git sends your pushes. This is useful if you move a repository to a different hosting service or if you realize you cloned from the wrong place. Your existing commits and history stay the same — only the destination changes.

What's the difference between origin and upstream?

Origin is your remote — the repository you push to and pull from. Upstream is typically the original repository you forked from. If you're contributing to someone else's project, you clone your fork (origin), add the original as upstream, and pull from upstream to stay in sync with their changes before submitting a pull request.

This guide is for general information only and is not medical, financial, legal, or other professional advice. For decisions specific to your situation, consult a qualified professional. See our Editorial Policy.