Learning Objectives
By the end of this lesson you will be able to:
- Copy an entire remote project to your machine with
git clone - Bring new commits down from the server with
git pull - Explain the difference between
fetchandpull - Follow a safe daily routine that avoids merge conflicts
git clone: Getting the Project
Everything so far started with a folder you made yourself. In real work, the project already exists — and you need a copy of it.
cd ~/Projects
git clone https://github.com/acme/payments-service.git
Cloning into 'payments-service'...
remote: Enumerating objects: 1847, done.
Receiving objects: 100% (1847/1847), 4.21 MiB | 6.30 MiB/s, done.
Resolving deltas: 100% (982/982), done.
One command did four things:
- Created a folder named
payments-service - Downloaded the entire history — every commit, every version, since the project began
- Set the remote up as
originautomatically - Checked out the latest version of the default branch into your working directory
You do not run git init afterwards. Cloning already made it a repository — running init inside a clone is a classic beginner move that creates confusion for no benefit.
You now have every tool from this trail available on real code: git log --oneline shows you what the team has been doing, git diff shows you exactly what changed between two builds.
To put it somewhere with a different name:
git clone https://github.com/acme/payments-service.git payments-test-copy
git pull: Getting the Latest Changes
A clone is a snapshot of one moment. The team keeps working. git pull brings their new commits into your copy:
git pull
Updating 4f2a1c9..8d3e7b2
Fast-forward
src/payments/currency.py | 24 +++++++++++++-------
tests/test_checkout.py | 41 ++++++++++++++++++++++++++
2 files changed, 58 insertions(+), 7 deletions(-)
"Fast-forward" means the simplest possible case: you had no local commits of your own, so Git just moved your copy forward to match the server. This is what a pull looks like 95% of the time for a tester.
Notice that the output is itself a change summary. That --stat-style list is your test scope for the new build, delivered as a side effect of updating.
fetch vs pull
Two commands, frequently confused, one small difference:
git fetchdownloads new commits from the remote but does not change your working directory. It updates Git's knowledge of what's on the server, so you can look before you leap.git pullisfetchfollowed immediately by merging those commits into your current branch. It changes your files.
A cautious sequence, useful when you're mid-task and don't want your files moving under you:
git fetch # see what's out there
git log --oneline HEAD..origin/main # what's on the server that I don't have?
git pull # OK, bring it in
Most days, plain git pull is fine. Know that fetch exists for the days it isn't.
Where every command in this trail actually moves your work:
┌─────────────────────────────┐
│ REMOTE (origin) │
│ github.com/acme/app │
└─────────────────────────────┘
▲ │
git push │ │ git clone (the first time)
│ │ git pull (every day after)
│ ▼
┌─────────────────────────────┐
│ YOUR REPOSITORY (.git) │
│ the commits on your disk │
└─────────────────────────────┘
▲ │
git commit │ │ you edit files
│ ▼
┌─────────────────────────────┐
│ WORKING DIRECTORY │
└─────────────────────────────┘
Nothing crosses the top gap on its own. Your commits sit on your disk until a push, and the team's work stays on the server until a pull.
The Safe Daily Routine
Four habits that prevent nearly every mess a beginner runs into:
1. Pull before you start. First thing each session, before you touch a file. Starting from the latest version means you're testing today's code, not Tuesday's.
2. Commit before you pull. If you have uncommitted edits and pull changes to the same files, Git will refuse or complain. Commit your work first — it takes five seconds and removes the whole problem class.
3. Pull before you push. As covered in the last lesson, this turns "push rejected" from an event into a non-event.
4. Never pull into a dirty working directory you care about. If git status isn't clean and you're not ready to commit, either commit or wait. A pull that collides with your uncommitted edits is the most common way beginners meet their first merge conflict.
About Merge Conflicts
Sooner or later a pull will report a conflict: you changed a line, someone else changed the same line, and Git will not guess which one wins. It stops and asks you.
Resolving conflicts is a proper topic that needs branches first, so it lives in the next trail. For now, the honest advice: conflicts are not an emergency and nothing is lost. If you get one and aren't sure, git merge --abort returns everything to exactly how it was before the pull. Nothing you had is destroyed.
Pro Tip: Cloning a repository is completely non-destructive and gives you the full history for free. If you're testing a product whose code you've never looked at, clone it. Even if you never read a line of the source,
git log --oneline --since="1 month ago"will teach you more about where the risk lives than a month of release notes.
Key Takeaways
git clone <url>copies a full repository — history included — and configuresoriginautomatically- Never run
git initinside a cloned repository; it's already a repository git pulldownloads new commits and merges them into your working directory, printing a change summarygit fetchdownloads without changing your files, letting you inspect before merging- Pull before you start, commit before you pull, pull before you push — and
git merge --abortundoes a conflicted pull