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

Let's see how well you understood the concepts! These exercises will help reinforce what you just learned.

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?