Git Remote

What a Remote Is

A remote is a reference to a repository hosted somewhere else, usually on a platform such as GitHub, GitLab, or Bitbucket. It gives your local repository a way to exchange commits with shared repositories.

The most common remote name is origin.

Check your current remotes:

git remote -v

You might see:

origin  https://github.com/example/devops-notes.git (fetch)
origin  https://github.com/example/devops-notes.git (push)

Adding and Removing Remotes

If you started a repository locally and later created a hosted repository, add a remote like this:

git remote add origin https://github.com/example/devops-notes.git

Verify it:

git remote -v

To remove a remote:

git remote remove origin

To rename a remote:

git remote rename origin upstream

Tip: In fork-based workflows, origin often points to your fork, while upstream points to the original project.

Downloading Information with git fetch

git fetch downloads new commits and remote references without changing your working files.

git fetch origin

This updates your knowledge of remote branches such as origin/main, but it does not merge them into your current branch.

Why fetch Is Safe

Because it does not change your working branch automatically, fetch is a safe way to inspect remote changes before deciding what to do next.

You can compare local and remote history after fetching:

git log --oneline main..origin/main

Bringing Changes In with git pull

git pull is essentially a fetch followed by integration, usually a merge.

git pull origin main

If your current branch tracks a remote branch, you can often just run:

git pull

Be aware that pull can change your working tree immediately, which is why many developers prefer to fetch first when they want more control.

Sending Changes Out with git push

Use git push to send local commits to a remote repository.

git push origin main

If you are pushing a new branch for the first time:

git push -u origin feature/login

The -u flag sets the upstream relationship, which means future pushes and pulls can use shorter commands.

Tracking Branches and Upstream

A tracking branch is a local branch linked to a remote branch. This relationship makes commands like git pull and git push more convenient.

When you run:

git push -u origin feature/login

Git remembers that your local feature/login branch tracks origin/feature/login.

You can inspect tracking details with:

git branch -vv

Sample output:

* feature/login 3f91ab2 [origin/feature/login] Add login validation
  main          1de2049 [origin/main] Update README

Setting Upstream Manually

If the branch already exists remotely, set the upstream manually:

git branch --set-upstream-to=origin/feature/login

Now simple git pull and git push commands work as expected from that branch.

Common Remote Workflow

A typical day might look like this:

git switch main
git fetch origin
git pull origin main
git switch -c feature/update-docs
# make changes
git add .
git commit -m "Improve Git tutorial examples"
git push -u origin feature/update-docs

This sequence updates local main, creates a feature branch, and publishes it to the remote for review.

Troubleshooting Common Confusion

“Why Don’t I See Remote Changes?”

You may need to fetch first:

git fetch origin

“Why Did git pull Change My Files?”

Because pull integrates remote changes into your current branch. Use fetch first if you want to inspect before updating.

“Why Does Git Ask Me for an Upstream?”

Your local branch is not yet linked to a remote branch. Push with -u or set the upstream manually.

Note: Authentication for push operations may use HTTPS tokens or SSH keys depending on your platform setup.

What You Should Remember

Remotes connect your local repository to shared repositories. git remote manages the connection, git fetch downloads information safely, git pull downloads and integrates changes, and git push publishes your commits. Tracking branches and upstream settings reduce repetitive typing and make collaboration smoother.

If you are unsure whether you want your working tree changed, fetch first.

Test Your Understanding

Exercise 1: Inspecting before integrating

Scenario: You want to see what changed on origin/main before your current branch is modified.

Question: Which command from the tutorial is the safest first step?

Exercise 2: First push of a new branch

Scenario: You just created feature/login locally and want future git push and git pull commands to be shorter.

Question: Which command sets that upstream relationship while publishing the branch?

Exercise 3: Fork workflow naming

Question: In the fork-based setup described in the lesson, what does upstream usually refer to?

---

Frequently Asked Questions

What is the difference between git fetch and git pull?

git fetch downloads commits and updates your remote-tracking branches such as origin/main, and changes nothing in your working directory. It is always safe to run. git pull is fetch followed immediately by a merge (or rebase) into your current branch, so it does alter your files and can produce conflicts. The useful habit is git fetch then git log origin/main..main to see what diverged before deciding how to integrate it, rather than letting pull decide for you.

How do I fix "rejected, non-fast-forward" when pushing?

The remote branch has commits you do not have locally, so accepting your push would discard them. Run git pull --rebase to replay your work on top of theirs, resolve any conflicts, then push. Do not reach for git push --force, which deletes their commits. If you genuinely must overwrite, after an intentional rebase of your own feature branch, use git push --force-with-lease, which refuses the push if the remote has moved since you last fetched.

What does git push -u origin main actually do?

-u (short for --set-upstream) records origin/main as the upstream of your local main, in addition to pushing. That association is what lets you type bare git push, git pull and git status afterwards and have Git know which remote branch you mean, including the "your branch is ahead by 2 commits" line in git status. You need it once per branch; after that the plain commands work. git branch -vv shows which branches have an upstream set.

Why don't I see a colleague's new branch?

Your local copy of the remote's branch list is only updated when you fetch. Run git fetch (or git fetch --all for every remote) and then git branch -r lists the remote branches you know about. The reverse problem is stale entries for branches that have been deleted upstream, which git fetch --prune clears; git config --global fetch.prune true makes that automatic on every fetch.

What is the difference between origin and upstream?

They are just remote names, not Git concepts. origin is the conventional name for the repository you cloned from, set automatically by git clone. upstream is the convention in fork-based workflows for the original project you forked: origin is your fork and upstream is the source. That is what makes git fetch upstream && git rebase upstream/main the standard way to bring a fork up to date. Add it with git remote add upstream <url>, and git remote -v lists what you have.

How do I change a remote's URL, for example from HTTPS to SSH?

git remote set-url origin git@github.com:user/repo.git, then confirm with git remote -v. This is the usual fix when HTTPS pushes start asking for a password that no longer works. GitHub stopped accepting account passwords for Git operations, so HTTPS needs a personal access token while SSH uses your key. Switching to SSH avoids the credential prompt entirely once your key is added to the account.