Git & GitHub

Working with Remotes

3 min read
Focus: GIT
⚡

TL;DR — Quick Summary

  • A remote is a copy of your repo hosted on a server (GitHub, GitLab, etc.) accessible by your team.
  • git clone = download a repo for the first time. git push = upload. git pull = download + merge.
  • origin is the default alias for your remote — verify it any time with git remote -v.
  • Fetch before you push — always stay in sync with the remote to prevent push rejections.

Lesson Overview

🌐 What is a Remote Repository?

A remote is a version of your repository hosted somewhere on the internet or a network. While your local repo lives on your laptop, a remote lives on a server — making it accessible to your entire team.

The most popular remote hosting platforms are:

  • GitHub — the largest developer platform, used by 100M+ developers
  • GitLab — popular for DevOps and self-hosted setups
  • Bitbucket — common in enterprise Atlassian environments

📡 The Four Core Remote Operations

  • clone: Download an entire remote repository to your local machine for the first time.
  • push: Upload your local commits to the remote repository.
  • fetch: Download remote changes to your local machine without merging them into your current branch.
  • pull: Download remote changes AND immediately merge them into your current branch (fetch + merge in one command).

🏷️ Understanding 'origin'

When you clone or connect a remote, Git gives it the alias origin by default. It's just a shortcut name — you could call it anything, but origin is universal convention. You can verify it with git remote -v.

Rule of thumb: fetch before you push. Always pull down others' changes before trying to push your own — this prevents rejection and reduces conflicts.

Conceptual Deep Dive

Think of a remote repository like a shared Google Doc in the cloud, while your local repo is your own copy on your laptop. When you push, you're uploading your edits to the shared version. When you pull, you're downloading the latest edits others have made. Fetch vs. Pull: git fetch downloads changes but doesn't touch your working files — it's like downloading a package but not opening it yet. git pull downloads AND immediately merges — like downloading and installing at the same time. Experienced developers often prefer fetch because it lets them review changes before merging.

Implementation Lab

Connecting to GitHub and Pushing Your First Code
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
# Scenario: You have a local repo and want to put it on GitHub
# 1. Create a new repo on GitHub (no README, no .gitignore)
# 2. Copy the repo URL (e.g., https://github.com/you/my-project.git)
 
# Connect your local repo to the remote
git remote add origin https://github.com/you/my-project.git
 
# Verify the remote was added
git remote -v
# origin  https://github.com/you/my-project.git (fetch))
# origin  https://github.com/you/my-project.git (push))
 
# Push your main branch to origin for the first time
# -u sets 'origin main' as the default upstream (only needed once)
git push -u origin main
 
# After the first push, you can just use:
git push
The Daily Collaboration Workflow
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
# Morning: get the latest changes from your team
git pull origin main
 
# Create your feature branch
git checkout -b feature/add-search
 
# ... do your work and commit ...
git add .
git commit -m "Add full-text search to products page"
 
# Before pushing, make sure you're up to date
git pull origin main
# If there are conflicts, resolve them now
 
# Push your feature branch to the remote
git push origin feature/add-search
 
# On GitHub: open a Pull Request from feature/add-search into main
Fetch vs Pull — Understanding the Difference
1
2
3
4
5
6
7
8
9
10
11
12
13
14
# FETCH: downloads changes but doesn't modify your working directory
git fetch origin
# Now you can inspect what changed without merging:
git log HEAD..origin/main --oneline
# See the diff:
git diff HEAD origin/main
# Decide to merge when ready:
git merge origin/main
 
# PULL: fetch + merge in one step (less control but faster)
git pull origin main
 
# PULL with rebase (keeps history linear — preferred by many teams)
git pull --rebase origin main
Cloning a Repository
1
2
3
4
5
6
7
8
9
10
11
12
13
14
# Clone a repo from GitHub to your local machine
git clone https://github.com/facebook/react.git
 
# Clone into a specific folder name
git clone https://github.com/user/repo.git my-custom-folder
 
# Clone a specific branch only (faster for large repos)
git clone --branch develop https://github.com/user/repo.git
 
# After cloning, 'origin' remote is automatically set up
cd react
git remote -v
# origin  https://github.com/facebook/react.git (fetch))
# origin  https://github.com/facebook/react.git (push))

Pro Tips — Senior Dev Insights

1

Set up SSH authentication (ssh-keygen + add public key to GitHub) — eliminates password prompts on every push/pull.

2

Use git pull --rebase instead of git pull to keep history linear — avoids unnecessary merge commits when syncing.

3

git remote rename origin upstream is useful when you've forked a project — rename the original to upstream and your fork becomes origin.

4

Enable branch protection on GitHub: require Pull Request reviews and passing CI checks before anything can be merged to main.

Common Developer Pitfalls

!
Pushing directly to main on a shared repository — use feature branches and Pull Requests instead.
!
Using git push --force on a shared branch — this overwrites teammates' commits and causes serious data loss and confusion.
!

Never pulling before starting work — leads to diverging histories and painful merge conflicts.

!

Committing and pushing sensitive data (API keys, passwords) to a public repo — once it's on GitHub, assume it's compromised forever.

Interview Mastery

git fetch downloads the latest changes from the remote repository into your local copy of the remote branches (e.g., origin/main), but does NOT merge them into your current working branch. Your files are untouched. git pull is essentially git fetch followed by git merge — it downloads AND integrates the changes immediately. Use fetch when you want to inspect changes before merging; use pull when you want to update quickly.

git push uploads your commits. -u (or --set-upstream) establishes a tracking relationship between your local branch and the remote branch. After setting this once, you can just type git push or git pull without specifying origin main every time. You only need -u the very first time you push a new branch.

This means someone else pushed commits to the same branch since your last pull. The fix: (1) run git pull origin main to fetch and merge their changes locally, (2) resolve any conflicts if they exist, (3) then git push again. Never use git push --force on a shared branch — it would overwrite your teammate's commits.

Real-World Blueprint

On a 10-person engineering team, every morning developers run git pull origin main to sync the overnight changes from teammates in different time zones. They branch, build their feature, push to origin, and open a Pull Request on GitHub. The PR triggers automated tests (CI/CD), a team member reviews the code, and when approved it's merged — all coordinated through the remote repository on GitHub.

Hands-on Lab Exercises

1
Create a new repo on GitHub, connect it to a local project with git remote add origin, and do your first git push -u origin main.
2
Clone any public GitHub repository, make a change, and see how git status shows your local changes vs. what was cloned.
3
Practice git fetch followed by git log HEAD..origin/main to see what changed remotely before merging.
4

Push a feature branch to GitHub and explore the GitHub UI to see the branch listed on the repository page.

Real-World Practice Scenarios

You try to push and get 'rejected' because the remote is ahead. What exact commands do you run to fix this?

A teammate says 'I pushed the new API file to the feature branch on origin.' How do you get that file onto your local machine?

You're joining an open-source project for the first time. What's the first command you run and what does it give you?

You pushed a commit with a debug console.log and a hardcoded API key to a public GitHub repo. What do you do?