Git Course 0%

clone, remote, fetch, pull, push

Intermediate Git CLI VS Code UI IntelliJ UI GitLab UI GitHub UI ≈ 15 min

Before this lesson

What you will learn

  • Exactly what clone, fetch, pull and push move, and between which areas
  • How to inspect and change a remote with git remote
  • How to read each command's output

After this lesson you can

  • I can name, for any of the four commands, what it changes and what it leaves alone
  • I can add, rename or repoint a remote without breaking my clone

Why this matters

Four commands, four different effects, and beginners routinely reach for the wrong one. This lesson puts them on one picture and shows the output of each, so that "I pulled and my changes vanished" and "I pushed but nobody can see it" stop happening.

The picture

What clone, fetch, pull and push each move Your computer on the left containing the working tree, the local branch main and the bookmark origin/main; the remote on GitLab or GitHub on the right. Clone copies everything once, creating all three. Fetch downloads new commits from the remote into the bookmark only. Pull is fetch followed by merge, so it also updates the local branch and the working tree. Push uploads commits from the local branch to the remote and moves the bookmark forward. YOUR COMPUTER GITLAB / GITHUB Working treeyour files main origin/main main git fetch pull = fetch, then merge upward git push git clone (once, creates all) Only fetch, pull, push and clone use the network. Everything else in Git happens inside the box on the left. git status compares main with origin/main, so it reports the remote as of your last fetch, not as it is now.
Clone creates everything once; fetch fills the bookmark; pull carries the change all the way to your files; push sends your commits out.
Command Direction Changes on your side Changes on the remote
git clone remote → you creates the whole repository, origin, and the working tree nothing
git fetch remote → you the remote-tracking bookmarks (origin/main) only nothing
git pull remote → you bookmarks and your branch and your files nothing
git push you → remote the bookmark, to match the branch you pushed

Everything else Git does happens without a network.

git clone: once per project

Terminal
$ git clone https://gitlab.com/northwind-trails/trailguide.git
Cloning into 'trailguide'...
done.

Over a network you also see remote: Enumerating objects… and Receiving objects: 100%. What you get: a folder, the whole history in .git, origin configured, and the default branch checked out (lesson 4.1).

git remote: the configuration

remote touches no commits; it manages the list of URLs.

Command Effect
git remote -v List remotes and their URLs
git remote show origin Ask the server for the full picture, including which branches are tracked
git remote add <name> <url> Add one, typically origin on a folder made with git init
git remote set-url origin <url> Repoint an existing remote, for example HTTPS to SSH
git remote rename <old> <new> Rename
git remote remove <name> Forget one; commits are untouched
Terminal
$ git remote -v
origin	https://gitlab.com/northwind-trails/trailguide.git (fetch)
origin	https://gitlab.com/northwind-trails/trailguide.git (push)

git fetch: look without touching

Terminal
$ git fetch
From https://gitlab.com/northwind-trails/trailguide
   6050e19..f75f2fe  main       -> origin/main

Read the last line as "the remote's main moved from 6050e19 to f75f2fe, and I have updated your bookmark origin/main to match". Your own main did not move and no file changed. Silence means there was nothing new.

Now git status can tell you where you stand:

Terminal
$ git status -sb
## main...origin/main [behind 1]

And you can read the incoming work before accepting it:

Terminal
$ git log --oneline main..origin/main
f75f2fe docs: link FAQ from README

git pull: fetch, then integrate

git pull is git fetch followed by a merge (or a rebase, if you configured that). When you have no commits of your own, the merge is a fast-forward:

Terminal
$ git pull
Updating 216f956..01268bf
Fast-forward
 docs/faq.md | 4 ++++
 1 file changed, 4 insertions(+)

When both sides have commits, it makes a merge commit:

Terminal
$ git pull
Merge made by the 'ort' strategy.
 data/trails.csv | 1 +
 docs/faq.md     | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)

Because pull changes your files, it refuses when uncommitted work would be overwritten:

Output
error: Your local changes to the following files would be overwritten by merge:
	README.md
Please commit your changes or stash them before you merge.
Aborting

Commit or stash first, then pull again. Lesson 7.5 compares fetch and pull properly.

git push: send your commits

Terminal
$ git push
To https://gitlab.com/you/trailguide.git
   01268bf..127f39e  main -> main

The range 01268bf..127f39e is what the remote's branch moved through. A brand-new branch prints * [new branch] instead and needs -u the first time (lesson 6.4).

Push sends commits, never uncommitted or staged changes. If a colleague pushed first, your push is refused; that is lesson 7.6.

How to do it

The daily rhythm:

Terminal
$ git pull
$ git push

Pull when you start and before you push; push whenever a piece of work is done. Use git fetch plus git status when you want to know what is coming without accepting it yet.

Common mistakes

  • "I committed but my colleague cannot see it." Committing is local; push.
  • "I pulled and my work disappeared." Almost always the work was on another branch, or was never committed. git status, git log --oneline --all --graph and the reflog find it.
  • Pulling with a dirty working tree. Git refuses and names the files; commit or stash.
  • Adding a second remote instead of repointing. git remote set-url, not a second add.
  • Expecting git push to send uncommitted changes. It sends commits only.

Try it yourself

Goal: run all four commands and watch which parts of the repository each one touches.

  1. In the playground with a remote configured, run git remote -v and git remote show origin.
  2. Make a change on the website (edit docs/faq.md in the browser and commit it there).
  3. Run git fetch, then git status -sb, then git log --oneline main..origin/main. Confirm that your local file has not changed.
  4. Run git pull and confirm the file has now changed.
  5. Make a local commit and git push; read the range in the output.

Expected result: after step 3 the status says [behind 1] and the file on disk is unchanged; after step 4 it is up to date and the file has the new text.

Show solution

Step 3 is the whole point of the lesson: fetch moved only the bookmark, so Git knew about the change while your files stayed as they were. That is what makes fetch safe to run at any moment, even mid-edit, and why lesson 7.5 recommends it as the habit.

Check yourself

1. Which command changes the files in your working tree?
2. git push prints 01268bf..127f39e main -> main. What does the range mean?
3. Your clone uses HTTPS and you want to switch it to SSH. What do you run?

Key terms

Clone Fetch Pull Push Remote origin Remote-tracking branch

Related