Git & GitHub — A Beginner's Guide

📖

What is Git — and why does it matter?

Understanding the core idea before touching a command

Imagine working on training notes and saving them as notes.txt, then notes_v2.txt, then notes_FINAL_really_final.txt… Git is a smarter way to track changes so you never need that chaos.

Before vs after using Git

💡 The core analogy

Git is like a time machine for your files. Every time you save a meaningful checkpoint (called a commit), Git remembers exactly what your project looked like at that moment. You can always go back, compare versions, or work on new ideas without breaking what already works.

🗂 Git

A version control system that runs on your own computer. It tracks every change you make to your files over time. On its own, Git only works locally — to share your work or collaborate with others, you need a hosting platform.

☁️ Git hosting platforms

Websites that store your Git project in the cloud so you can back it up, share it, and collaborate with others. Common examples include GitHub, GitLab, and Bitbucket.

💡

Note: Git ≠ GitHub (or GitLab, or Bitbucket) Git is the tool. Hosting platforms are services that let you use it in the cloud — like how email is the tool, and Gmail or Outlook are services that provide it.

🖥

Local vs Remote Repository

Your files live in two places — here's how they relate

A repository (or "repo") is just a folder that Git is tracking. The same project exists in two places: on your personal computer, and on a Git hosting platform in the cloud.

The two environments

☁️ Remote — Git hosting platform

📄 notes.txt
📝 report.docx
📊 data.xlsx
📜 commit history

↑ push

pull ↓

🖥 Local — Your Computer

📄 notes.txt
📝 report.docx
📊 data.xlsx
📁 .git/

💡 Think of it like a shared document

Your local repo is like a printed copy on your desk — you can mark it up freely. The remote repo on your hosting platform is like the master copy in a shared filing cabinet. When you're happy with your changes, you send them up (push). To get the latest version someone else added, you bring it down (pull).

🖥 Local Repository

Lives on your machine. You can edit files, test changes, and use Git — all without internet access.

☁️ Remote Repository

Lives on a Git hosting platform (such as GitHub or GitLab). Serves as the shared, backed-up version that teammates (or your future self) can access.

💡

Note: Changes don't sync automatically Changes you make locally do not automatically appear on your hosting platform. You have to explicitly send them up. This gives you full control over what gets shared.

📦

git add & git commit

Preparing and saving a snapshot of your work

For Git to log the changes made to a file in the local repo, two things need to happen: staging (selecting what to include) and committing (saving the snapshot with a message). Only after committing can you send your updated files to the remote repo.

The three states of a file

🖥 Local Repository

Saved

locked into Git's history

↑ git commit

Staging Area

ready to commit

↑ git add

Draft

edited files

💡 Saved means your changes are recorded in your local repo. Use git push to send them up to your hosting platform.

💡 The packing analogy

Think of sending files from the local repo to the remote repo like shipping a package. git add is putting items into the box — you choose exactly what to include. git commit is sealing and labeling the box before it goes into storage. The label (your commit message) describes what's inside.

git add

Put files in the box

git commit

Seal & label the box

git push

Ship it to GitHub

1

Stage your changes with `git add`

Tell Git which changed files you want to include in the next snapshot.

            $ git add notes.txt
            
# Stage a specific file
            
$ git add .
            
# Stage ALL changed files in the folder

2

Save a snapshot with `git commit`

Lock in your staged changes with a short message describing what you did.

            $ git commit -m "Add lecture notes from week 3"
            
[main 3a2f8c1] Add lecture notes from week 3
            
 1 file changed, 8 insertions(+), 1 deletion(-)

✅

Tip: Write clear commit messages Future you (and teammates) will be grateful. A good message starts with a verb: "Fix login bug", "Add search feature", "Update README".

🔄

git push & git pull

Syncing changes between your computer and GitHub

Once you've committed locally, your changes still only exist on your machine. push sends them to your hosting platform; pull brings the latest changes from your hosting platform down to your machine.

Complete sync workflow

☁️ Remote Repository

↑ push pull ↓

🖥 Local Repository

Saved

commits

↑ git commit

Staging Area

ready to commit

↑ git add

Draft

edited files

0

Connect your local machine to your remote repo with `git clone`

Before you can push or pull, you need a local copy of your remote repository. Run this once to download it and set up the connection automatically.

            $ git clone https://github.com/yourname/git-practice.git
            
Cloning into 'git-practice'...
            
remote: Counting objects: 3, done.
            
Receiving objects: 100% (3/3), done.

💡

Note: You only need to run git clone once per project. After that, use git pull to keep your local copy up to date.

💡

Note: git init git clone is used when a remote repository already exists. If you were starting a brand new project locally from scratch, you would use git init instead — but that is outside the scope of this tutorial.

↑

Send your commits to your hosting platform with `git push`

Uploads all your local commits to the remote repository.

            $ git push origin main
            
# "origin" = your remote, "main" = the branch name
            
Enumerating objects: 5, done.
            
To https://github.com/yourname/myproject.git
            
   3a2f8c1..9b4e2d0  main → main

↓

Get the latest changes with `git pull`

Downloads new commits from your hosting platform and merges them into your local copy.

            $ git pull origin main
            
remote: Enumerating objects: 3, done.
            
Updating 3a2f8c1..9b4e2d0
            
Fast-forward
            
 README.md | 4 ++--

✅

Tip: Always pull before you start working Run git pull at the start of each session. This ensures you're working from the latest version, especially when collaborating.

💡

Note: git pull ≠ Pull Request git pull is a command that downloads the latest changes from a remote repository to your local machine. A Pull Request is a separate concept — it's a request on the hosting platform asking teammates to review and approve your changes before they are merged. We cover Pull Requests in Section 7.

🍴

Fork & Clone

Copying someone else's project to work on it yourself

Sometimes you want to work on a project you don't own — maybe to contribute, or to use it as a starting point. That's where fork and clone come in. They're related but different.

Fork then Clone workflow

🍴 Fork (hosting platform action)

Creates a copy of someone else's remote repo under your own account. Done on the hosting platform with one click. The copy is fully yours — you can change it freely without affecting the original.

⬇️ Clone (Git command)

Downloads a repository from your hosting platform to your local computer. Used after forking, or any time you want to work on a project locally for the first time.

1

Fork the repo on your hosting platform

Go to the repository page, click the Fork button. The hosting platform creates a copy under your account.

💡

Note: No terminal needed This step happens entirely on the hosting platform website.

2

Clone your fork to your computer

Copy the URL of your forked repo from your hosting platform, then run:

            $ git clone https://github.com/you/training-notes.git
            
Cloning into 'training-notes'...
            
remote: Counting objects: 42, done.
            
Receiving objects: 100% (42/42), done.

This creates a folder training-notes/ on your machine with all the files inside.

3

Make changes, then push to your fork

Work locally, commit your changes, and push them to your fork on the hosting platform — not the original.

            $ git add .
            
$ git commit -m "Fix typo in README"
            
$ git push origin main

✅

Tip: You now know the full workflow! Fork → Clone → Edit → Add → Commit → Push. This is the foundation of contributing to almost any open-source project on GitHub.

🌿

Branches

Working on a separate draft without touching the main version

When you're collaborating on training content, you don't want everyone editing the same files at the same time. A branch lets you work on your own version of the project — like a separate draft — without affecting what the rest of the team sees.

💡 The draft analogy

Think of the main branch as the published, approved version of your training content — the one everyone relies on. A new branch is like opening a fresh draft copy. You can revise it freely, and when it's ready and reviewed, it gets merged back into the published version. Until then, the original is completely untouched.

How branches relate to main

🖥 Local

☁️ Remote

Your draft changes

update-week3-notes

merge →

Approved content

stable, shared version

↑ git commit

Staging Area

ready to commit

↑ git add

Draft

your edits

1

Create and switch to a new branch

Give your branch a short, descriptive name that reflects what you're working on.

            $ git checkout -b update-week3-notes
            
Switched to a new branch 'update-week3-notes'

2

Work, add, and commit as usual

All your changes stay on this branch. The main branch is unaffected.

            $ git add notes.txt
            
$ git commit -m "Update week 3 notes with new examples"

3

Push your branch to GitHub

Share your draft branch with the team by pushing it to the remote repo.

            $ git push origin update-week3-notes
            
Branch 'update-week3-notes' set up to track remote branch.

✅

Tip: Never edit directly on main Always create a new branch before making changes. This keeps the shared, approved version of your content safe.

🌿 main branch

The default, approved version of your project. Think of it as the published copy everyone on the team relies on.

🌱 feature branch

Your personal draft. Make all your changes here until they're ready to be reviewed and merged into main.

🔀

Pull Requests

Proposing your changes and getting them reviewed before merging

Once your branch is pushed to your hosting platform, you don't merge it into main straight away. Instead, you open a Pull Request (PR) — a formal way of saying "I'd like to merge my draft. Can someone review it first?"

💡

Note: A Pull Request is not the same as git pull Despite the similar name, a Pull Request is a feature of your hosting platform — not a Git command. Think of it as a conversation, not a command.

💡 The editorial review analogy

Think of a pull request like submitting a draft to an editor. You've finished your revisions on your own copy and you're now asking a colleague to look it over before it goes into the official, published version. They can leave comments, request changes, or approve it. Only once it's approved does it get merged into the main content.

The pull request workflow

☁️ Remote

Merged into main

Your changes are now part of the official content

↑ approved

Under Review

Teammates leave comments or request changes

↑ open pull request

Your Branch

update-week3-notes

🖥 Local

1

Open a Pull Request on GitHub

After pushing your branch, go to the repository on GitHub. You'll see a prompt to open a Pull Request. Give it a clear title and description explaining what you changed and why.

💡

Note: No terminal needed This step happens entirely on the GitHub website.

2

Team reviews your changes

Teammates can read through your changes line by line, leave inline comments, and request edits. You can keep pushing new commits to the same branch to address feedback — the PR updates automatically.

            # After addressing feedback, push again to the same branch
            
$ git add notes.txt
            
$ git commit -m "Revise week 3 notes based on feedback"
            
$ git push origin update-week3-notes

3

Merge into main once approved

When a teammate approves the PR, click Merge Pull Request on GitHub. Your changes become part of the official main branch, visible to the whole team.

✅

Tip: Delete the branch after merging It's served its purpose — keeping things tidy helps the whole team.

Quick Reference — All Commands

`git clone <url>`	Copy a remote repo to your computer (once)
`git init`	Initialise a brand new local repository from scratch
`git add .`	Stage all changed files
`git commit -m "msg"`	Save a snapshot with a message
`git push origin main`	Upload commits to your hosting platform
`git pull origin main`	Download latest from your hosting platform
`git checkout -b <name>`	Create and switch to a new branch
`git push origin <branch>`	Push a branch to your hosting platform
`git status`	Check what's changed or staged

What is Git — and why does it matter?

🗂 Git

☁️ Git hosting platforms

Local vs Remote Repository

🖥 Local Repository

☁️ Remote Repository

git add & git commit

Stage your changes with git add

Save a snapshot with git commit

git push & git pull

Connect your local machine to your remote repo with git clone

Send your commits to your hosting platform with git push

Get the latest changes with git pull

Fork & Clone

🍴 Fork (hosting platform action)

⬇️ Clone (Git command)

Fork the repo on your hosting platform

Clone your fork to your computer

Make changes, then push to your fork

Branches

Create and switch to a new branch

Work, add, and commit as usual

Push your branch to GitHub

🌿 main branch

🌱 feature branch

Pull Requests

Open a Pull Request on GitHub

Team reviews your changes

Merge into main once approved

Stage your changes with `git add`

Save a snapshot with `git commit`

Connect your local machine to your remote repo with `git clone`

Send your commits to your hosting platform with `git push`

Get the latest changes with `git pull`