Git and GitHub, untangled

Git turns up in every week of this course, usually as the thing standing between you and a published repo. It has a reputation for being confusing, and most of that confusion is one mix-up: people think Git and GitHub are the same thing. They are not, and once that clicks, the rest is a handful of commands you will use for the rest of your career.

Version control, and why you want it

Version control is a tool that saves snapshots of your project over time, so you can see what changed, when, and undo it if you need to. It is the difference between a folder full of `report-final-v2-REALLY-final.doc` and a tidy history you can actually read. Git is the most widely used version control tool, and it runs on your own machine.

Git is not GitHub

This is the whole knot, so here it is plainly. Git is the tool that takes and stores the snapshots, on your computer, offline, no account required. GitHub is a website where you put a copy of that history so other people, future you, and hiring managers can see it. Git is the camera; GitHub is the photo-sharing site. You can use Git with no GitHub at all, and GitHub is useless without Git underneath it.

The mental model

Git moves your work through three places, and every command makes more sense once you can picture them:

• Your working folder, where you actually edit files.
• The staging area, a holding pen for the changes you want in your next snapshot.
• The repository, the saved history of snapshots, called commits.

And when you want it online, a fourth place: the remote, which is the copy living on GitHub or a similar host. You push commits up to it and pull other people's commits down.

Check it is there

$ git --version

If you have not set your identity yet, do it once. It stamps your name on every commit, so your work is attributed to you.

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

The everyday flow

Ninety percent of Git is four moves: start a project, stage changes, commit them, and push. Here is starting a repo and making the first commit.

$ git init$ git status$ git add .$ git commit -m "First commit"

Then connect the repo to a host and push it up, once you have created an empty repo on the website.

$ git remote add origin https://github.com/you/bug-hunt.git$ git push -u origin main

After that first push, sending new work up and pulling changes down is just:

$ git push$ git pull

And to copy an existing project from a host onto your machine:

$ git clone https://github.com/you/bug-hunt.git

Branches, lightly

A branch is a parallel line of work, so you can try something without touching the known-good version. You make a branch, do your work and commits on it, then merge it back when it is ready. You do not need this in week one, but you will meet it soon, and on a team you will live in it.

$ git switch -c my-feature$ git switch main$ git merge my-feature

Where repos live: the hosts

Here is the freeing part. Git is a standard, so the commands above are identical no matter where your repo lives online. Only the website changes. The main options:

• GitHub (opens in a new tab). The largest by far, with the biggest community and where most open source and most employers look. For a portfolio aimed at getting hired, this is the pragmatic default, and it is what this course assumes.
• GitLab (opens in a new tab). Popular inside companies, with strong built-in pipelines for running tests and deployments. It can also be self-hosted, so firms that want their code on their own servers often choose it.
• Bitbucket (opens in a new tab). From Atlassian, so it sits close to Jira and the rest of that toolset. You will meet it mostly at companies already living in Atlassian.
• Codeberg (opens in a new tab). A smaller, community-run, non-profit option. Worth knowing exists, if you like the idea of code hosting that is not owned by a big company.

Issues, README, and Markdown

Two features you will use beyond the basics. Issues are a host's built-in list of bugs and tasks, which as a tester you will file and read constantly. And a README, the front page of any repo, is written in Markdown, the same light text format the AI help page describes. A clear README is what turns a pile of files into a portfolio piece someone can actually understand.

A word on keeping it secure

When you push for the first time from the terminal, the host will ask you to prove who you are, usually with a personal access token or an SSH key rather than a plain password. It sounds fiddly and it is a one-time setup. GitHub Desktop handles it for you invisibly, which is one more reason to start there. Never paste a token into a chat, an email, or a public repo; treat it like a password, because it is one.

When you want the full deep dive