Git & GitHub Crash Course

Tip: This guide is designed for complete beginners. If you've never typed git in a terminal before, you're in exactly the right place. By the end you'll understand how to track your code changes, collaborate via GitHub, and publish your JIH lab work with the "Publish to GitHub" button.

---

1. What Is Version Control and Why It Matters

Imagine you're writing an essay. You save the file as essay.docx. An hour later you make changes and save again — but you've overwritten the original. If those changes were a mistake, the original is gone.

Now imagine you're building a program with a teammate. You both edit the same file. Whose version wins?

Version control solves both problems. It is software that:

• Tracks every change made to a set of files over time
• Lets you see who changed what and when
• Lets you revert any file (or entire project) to an earlier state
• Lets multiple people work on the same project without overwriting each other

Version control isn't just for large teams — it's as useful for a single developer as it is for a team of 500. Every professional developer uses it daily.

---

2. Git vs GitHub — The Distinction

People often use "Git" and "GitHub" interchangeably, but they are different things:

Think of it this way: Git is the tool; GitHub is where you store and share work done with that tool. You can use Git without GitHub (saving only on your own machine), but you can't use GitHub without Git.

Other platforms (GitLab, Bitbucket) do the same job as GitHub — they're all just hosting services for Git repositories.

---

3. Installing Git

Windows

Download the installer from git-scm.com. Run it and accept the defaults. When it finishes, open Git Bash (installed alongside Git) and type:

git --version

You should see something like git version 2.44.0.

macOS

Open Terminal and type:

git --version

If Git is not installed, macOS will prompt you to install Xcode Command Line Tools — click Install and wait. Alternatively, install Homebrew and then run:

brew install git

Linux (Ubuntu/Debian)

sudo apt update && sudo apt install git -y
git --version

First-time setup (all platforms)

After installing, tell Git your name and email. This information is attached to every commit you make:

git config --global user.name "Your Name"
git config --global user.email "you@example.com"

Tip: Use the same email address you register with on GitHub — this is how GitHub links your commits to your profile.

---

4. Core Concepts

Before looking at commands, understand these five ideas. Everything else is built on them.

Repository (repo)

A repository is a folder tracked by Git. It contains your project files and a hidden .git/ subfolder where Git stores the entire change history. When you say "I'll push my code to the repo," this is what you mean.

Commit

A commit is a saved snapshot of your project at a specific moment. Think of it like a photograph — you decide when to take one, and Git stores it permanently. Every commit has:

• A unique ID (a long hex string like a3f9c2d)
• A short commit message you write describing the change
• A timestamp and your author name/email

Commits are the heartbeat of Git. You commit often and with clear messages.

Branch

A branch is a separate line of development. By default, your repository has one branch called main (or master in older setups). You can create a new branch to work on a feature without touching the main code. When the feature is ready, you merge the branch back.

main:    A --- B --- C
                      \
feature:               D --- E

Branching lets you experiment safely.

Merge

Merging combines changes from one branch into another. If your feature branch added a new function and main has been updated since you branched, Git tries to combine both sets of changes automatically. When two people changed the same line, Git raises a merge conflict for you to resolve manually.

Remote

A remote is a copy of the repository hosted somewhere other than your machine — typically GitHub. The standard remote is named origin. When you push, your commits travel from your machine to the remote. When you pull, you bring down commits others have pushed.

---

5. Essential Commands

git init

Creates a new, empty Git repository in the current folder.

mkdir my-project
cd my-project
git init

Output: Initialized empty Git repository in /path/to/my-project/.git/

git clone

Downloads an existing repository from a URL and sets up the remote automatically.

git clone https://github.com/username/repository-name.git

This creates a folder called repository-name/ with all files and history already inside.

git status

Shows what is currently happening in your working directory — which files are new, modified, or staged.

git status

Read this output often. It tells you exactly what Git sees. A clean repo says:

On branch main
nothing to commit, working tree clean

git add

Moves changes from your working directory into the staging area (also called the index). Only staged changes are included in the next commit.

# Stage a specific file
git add index.html

# Stage all changed files in the current directory
git add .

Tip: Prefer git add <filename> over git add . — it forces you to think about what you're including, preventing accidental commits of debug code or temporary files.

git commit -m

Creates a commit from everything currently staged. The -m flag lets you write the message inline.

git commit -m "Add login form validation"

Write commit messages in the imperative: "Add", "Fix", "Update", not "Added" or "Fixes". Keep them under 72 characters. Be specific — "Fix off-by-one error in loop" is better than "Fix bug".

git log

Shows the commit history.

git log

Press q to quit. For a compact view:

git log --oneline

git push

Sends your local commits to the remote repository.

git push origin main

origin is the remote name; main is the branch name. The first time you push a new branch, add -u to set the upstream:

git push -u origin main

After that, git push alone is enough.

git pull

Fetches commits from the remote and merges them into your current branch.

git pull origin main

Run this before starting any new work to make sure you have the latest changes.

git branch

Lists branches, creates them, or deletes them.

# List all local branches
git branch

# Create a new branch
git branch feature/login

# Delete a branch (after merging)
git branch -d feature/login

git checkout / git switch

Switches to a different branch. git switch is the modern equivalent introduced in Git 2.23 — prefer it for clarity.

# Modern way (Git 2.23+)
git switch feature/login

# Create and switch in one step
git switch -c feature/signup

# Old way (still works)
git checkout feature/login
git checkout -b feature/signup

git merge

Merges another branch into your current branch.

# Switch to main first
git switch main

# Merge the feature branch in
git merge feature/login

If there are no conflicts, Git makes a "fast-forward" or "merge commit" automatically. If there are conflicts, open the flagged files, resolve them, then git add and git commit to complete.

---

6. The GitHub Workflow

Here is the standard process for starting a project on GitHub and making your first push.

Step 1 — Create a repository on GitHub

1. Go to github.com and sign in (or create a free account).
2. Click the + icon in the top-right corner → New repository.
3. Give it a name (e.g. my-first-project).
4. Leave it Public for now (or Private if you prefer).
5. Do not add a README, .gitignore, or licence at this stage — you will push those from your machine.
6. Click Create repository.

GitHub shows you a page of setup instructions. You want the "push an existing repository from the command line" section.

Step 2 — Connect your local repo and push

# Initialise Git in your project folder (skip if already done)
git init

# Add and commit your files
git add .
git commit -m "Initial commit"

# Point the remote to your GitHub repo
git remote add origin https://github.com/username/my-first-project.git

# Push to GitHub
git push -u origin main

Refresh the GitHub page — your files are now there.

Step 3 — Create a pull request

A pull request (PR) is a GitHub concept (not a Git command). It is a formal proposal to merge changes from one branch into another — usually from a feature branch into main. PRs are where code review happens.

To create one:

1. Push your feature branch: git push -u origin feature/my-feature
2. Go to your repository on GitHub — GitHub shows a banner: "Compare & pull request". Click it.
3. Write a title and description explaining what you changed and why.
4. Click Create pull request.

If you're working alone, you can merge it immediately. In a team, a colleague reviews it first.

---

7. The JIH Lab Publish Flow

When you click "Publish to GitHub" in a JOBITECH Innovation Hub lab, the platform:

1. Takes your current lab code (the files in your in-browser editor).
2. Creates a GitHub Gist — a lightweight way to share a single file or small set of files — under your connected GitHub account.
3. Returns a public URL to that Gist.

This is not a full repository push — it is a Gist publish, which is simpler and doesn't require you to create a repo yourself.

Connecting your GitHub account

Before publishing, you need to connect your GitHub account to your JIH profile:

1. In the lab publish section, click "Connect GitHub to publish".
2. You'll be redirected to GitHub's authorisation page.
3. Click Authorise — this grants JIH permission to create Gists on your behalf.
4. You're returned to the lab. The button now shows your GitHub username.

Once connected, clicking "Publish to GitHub" creates the Gist and shows you a "View on GitHub ↗" link. Share that link in your portfolio or with an employer to prove you completed the lab.

---

8. Common Mistakes and How to Fix Them

"I committed to the wrong branch"

# Move the last commit to a new branch
git switch -c correct-branch
git switch main
git reset --hard HEAD~1

This takes the last commit off main and puts it onto correct-branch.

"I wrote the wrong commit message"

If you haven't pushed yet:

git commit --amend -m "Correct message here"

If you have pushed, avoid amending — it rewrites history and will confuse collaborators. Instead, make a new commit with a note like "Update commit message" or leave it and move on.

"I staged a file I didn't mean to"

git restore --staged filename.txt

This moves the file back out of the staging area without discarding your changes.

"I want to discard changes to a file entirely"

git restore filename.txt

Warning: This is permanent. The changes in the file are gone. Use git status first to make sure you know exactly what you're discarding.

"I have a merge conflict"

Git marks conflicts inside files like this:

<<<<<<< HEAD
Your version of the code
=======
Their version of the code
>>>>>>> feature/their-branch

Open the file in your editor, decide which lines to keep (or combine both), delete the <<<, ===, >>> markers, then:

git add filename.txt
git commit

Most code editors (VS Code, IntelliJ) have a visual merge conflict resolver — look for a panel that shows "Current Change" vs "Incoming Change" with Accept buttons.

"I accidentally deleted a file"

git restore filename.txt

If the file was deleted in a previous commit (not just unstaged), you need to find the commit that last had the file:

git log --all -- filename.txt
git checkout <commit-hash> -- filename.txt

Using git reset

git reset moves the branch pointer back in history. There are three modes:

# Soft — uncommit but keep changes staged
git reset --soft HEAD~1

# Mixed (default) — uncommit and unstage, keep files on disk
git reset HEAD~1

# Hard — uncommit and delete the changes entirely
git reset --hard HEAD~1

Tip: git reset --hard is destructive. Use it only when you are certain you want to discard the commits. Never use it on shared branches.

---

9. Glossary

---

10. Next Steps

You now have enough Git knowledge to work effectively on solo projects and contribute to team projects. Here is where to go deeper:

Official documentation

• git-scm.com/doc — the official Git reference manual and the free Pro Git book (available online)
• docs.github.com — GitHub's own guides, covering Actions, Issues, Pull Requests, and more

Recommended reading (no external video links — self-host your video player in the lab)

• Pro Git by Scott Chacon and Ben Straub — free at git-scm.com/book — the most comprehensive beginner-to-advanced Git book available
• GitHub Skills at skills.github.com — short, interactive courses run entirely inside GitHub repositories
• MDN's guide to contributing to open source — covers Git workflow in the context of real projects

Practice

The single best way to learn Git is to use it on every project, even personal ones. The muscle memory for git add, git commit, git push builds quickly. Make commits often — small, focused commits are always better than one giant "everything" commit at the end of the day.

---

This guide is part of the JOBITECH Innovation Hub reference library. It is not part of the course catalogue and carries no XP or completion tracking.