Working with Remotes

So far you have been making commits on your own machine. Those commits live only on your computer. A remote is a copy of your Git repository that lives somewhere else — usually on a hosting service like GitHub, GitLab, or your own server. Remotes are how you back up your work, share it with teammates, and deploy it. In this page you will learn how to connect a local project to a remote, send your commits up with push, and bring other people’s commits down with pull and fetch.

What is a remote?

A remote is just a named bookmark that points to another copy of your repo, stored at a URL (a web or SSH address). You can have several remotes, but most projects have one called origin.

• origin — the default name Git gives to the remote you cloned from (or the first remote you add). It is “your” main copy on the server. Think of it as home base.
• upstream — a second remote you add by convention when you have forked (made your own copy of) someone else’s project. upstream points to the original project so you can pull in their new changes, while origin points to your personal fork.

The names origin and upstream are just conventions, not magic keywords. You could call a remote banana and Git would not care. Sticking to the conventions keeps your commands readable and matches every tutorial and teammate.

When to use a remote (and when not)

Situation	Use a remote?
You want a backup of your code off your laptop	Yes — push to GitHub
You collaborate with other people	Yes — everyone shares one remote
You deploy code to a server	Yes — pull on the server or via CI/CD
A throwaway script you will never reuse	No — a local repo (or no repo) is fine
Secrets like passwords or .env files	Never push them — use .gitignore first

Cloning an existing repository

If the project already exists on GitHub, you do not “add a remote” — you clone it. Cloning downloads the full history and automatically sets up origin for you.

git clone https://github.com/devcraftly/example-app.git

Output:

Cloning into 'example-app'...
remote: Enumerating objects: 248, done.
remote: Counting objects: 100% (248/248), done.
remote: Compressing objects: 100% (130/130), done.
Receiving objects: 100% (248/248), 1.21 MiB | 4.50 MiB/s, done.
Resolving deltas: 100% (96/96), done.

This creates a folder called example-app with the code inside and origin already pointing at the GitHub URL. You can confirm with git remote -v (the -v means “verbose”, so it shows the URLs):

cd example-app
git remote -v

Output:

origin  https://github.com/devcraftly/example-app.git (fetch)
origin  https://github.com/devcraftly/example-app.git (push)

Connecting a local repo to a new GitHub repo

The other common case: you already started a project locally and now want to put it on GitHub for the first time.

Step 1 — create the empty repo on GitHub. On the GitHub website, click New repository, give it a name (for example my-server-app), and importantly do not tick “Add a README” or any license — you want it completely empty so it does not clash with your local files. GitHub then shows you a URL.

Step 2 — make sure your local repo has at least one commit. From your project folder on Ubuntu:

git init
git add .
git commit -m "Initial commit"

Step 3 — add the remote. This is where git remote add origin comes in. It creates the origin bookmark pointing at your new GitHub URL:

git remote add origin [email protected]:devcraftly/my-server-app.git

That command produces no output when it succeeds (Git is quiet on success). The address above is the SSH form (recommended — it uses your SSH key so you do not type a password every time). The HTTPS form (https://github.com/...) also works but asks for a Personal Access Token.

Step 4 — push your code with -u. The first push needs the -u flag:

git push -u origin main

Output:

Enumerating objects: 5, done.
Counting objects: 100% (5/5), done.
Writing objects: 100% (5/5), 412 bytes | 412.00 KiB/s, done.
Total 5 (delta 0), reused 0 (delta 0)
To github.com:devcraftly/my-server-app.git
 * [new branch]      main -> main
branch 'main' set up to track 'origin/main'.

The -u (short for --set-upstream) tells Git to link your local main branch to the remote origin/main. After this one-time setup, you can just type git push and git pull with no extra arguments — Git remembers where they go. The last line of the output, “set up to track”, confirms the link.

Pushing and pulling day to day

Once tracking is set up, the daily loop is simple.

Send your local commits to the remote:

git push

Bring teammates’ new commits down to your machine:

git pull

Output:

remote: Enumerating objects: 8, done.
Unpacking objects: 100% (5/5), 980 bytes | 245.00 KiB/s, done.
From github.com:devcraftly/my-server-app
   a1b2c3d..e4f5g6h  main       -> origin/main
Updating a1b2c3d..e4f5g6h
Fast-forward
 src/app.js | 12 ++++++++++--
 1 file changed, 10 insertions(+), 2 deletions(-)

Always git pull before you start a fresh chunk of work for the day. Pulling first reduces the chance of merge conflicts (two people changing the same lines) and keeps you in sync with the team.

fetch vs pull — what is the difference?

This trips up almost every beginner. Both bring data down from the remote, but they differ in one big way: pull automatically changes your working files, while fetch does not.

• git fetch downloads the latest commits from the remote into your local copy of the remote branches (like origin/main), but it does not touch your current branch or your files. It is the “look but don’t apply” command. You can then inspect what changed before merging.
• git pull is really git fetch plus git merge in one step. It downloads and immediately merges those commits into your current branch, updating your files.

Command	Downloads commits	Changes your files	Safe to run anytime
git fetch	Yes	No	Yes — never disruptive
git pull	Yes	Yes (merges)	Mostly, but can cause conflicts

A safe inspection workflow looks like this:

git fetch origin
git log HEAD..origin/main --oneline

Output:

e4f5g6h Add rate limiting to API
9z8y7x6 Fix typo in config loader

That shows you exactly which incoming commits you have not merged yet. When you are happy, run git merge origin/main (or just git pull) to apply them.

Inspecting and changing remotes

git remote -v                 # list all remotes and their URLs
git remote rename origin gh   # rename a remote
git remote remove origin      # delete a remote
git remote set-url origin [email protected]:me/repo.git   # change the URL

Use set-url when you switch from HTTPS to SSH, or when a repository moves to a new organisation.

Best Practices

• Use SSH URLs for GitHub so you authenticate with a key instead of typing tokens; set up your key once with ssh-keygen and add the public key to GitHub.
• Run git pull at the start of every work session to stay in sync and minimise conflicts.
• Push small, frequent commits rather than one giant push — it makes backups continuous and reviews easier.
• Prefer git fetch then review with git log when you are unsure what changed, instead of blindly pulling.
• Never push secrets, credentials, or large binaries; add them to .gitignore before your first commit.
• Keep the origin / upstream convention: origin is your copy, upstream is the project you forked from.
• Verify your remotes with git remote -v after cloning or adding, so you never push to the wrong place.

Related Topics

• Git basics: add, commit, status
• Branching and merging
• Resolving merge conflicts
• GitHub and GitLab
• Pull requests