Git & GitHub - DevOps Lab

What You'll Learn

Understand version control and why every team relies on it
Tell the difference between Git (the tool) and GitHub (the host)
Track changes: init → add → commit
Work with branches and merge them
Push to GitHub and collaborate via a pull request

Prerequisites: Module 2 (Linux), plus Git installed (git --version) and a free GitHub account.

Why Version Control

Ever ended up with report_final.doc, report_final_v2.doc, report_FINAL_really.doc? That's manual version control — and it falls apart the moment more than one person is involved.

Without version control

You can't see who changed what or when, you can't safely undo a mistake, and two people editing the same file overwrite each other. For software, that's chaos.

Git records a complete history of every change to your project. You can travel back in time, see exactly what changed, branch off to experiment safely, and merge work from many people. It's the foundation of CI/CD (Module 9) — pipelines trigger on Git events.

Git vs. GitHub

Git is the version-control tool that runs on your machine. GitHub is a website that hosts Git repositories online so you can back them up and collaborate. (GitLab and Bitbucket are alternatives.) Git works fine offline; GitHub is the shared copy.

The Mental Model

Git has three areas your files move through. Understanding this makes every command obvious:

  Working Dir  ──git add──▶  Staging Area  ──git commit──▶  Repository
  (your edits)              (changes to save)            (permanent history)
                                                              │
                                                          git push
                                                              ▼
                                                          GitHub (remote)

Term	What it is
Repository (repo)	A project folder Git is tracking, plus its full history.
Commit	A saved snapshot of your changes, with a message.
Branch	A parallel line of work, so you can experiment without breaking `main`.
Remote	A copy of the repo hosted elsewhere (e.g. GitHub), named `origin`.
Pull Request (PR)	A GitHub proposal to merge one branch into another, with review.

Hands-on Lab: Your First Repo

We'll create the notes-app repository you'll reuse from Module 6 onward. Follow along in your terminal.

1

One-time setup

Tell Git who you are (used to label your commits):

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

2

Create a repo

mkdir notes-app cd notes-app git init # start tracking this folder echo "# Notes App" > README.md

3

Stage and commit

git status               # see what's changed (README is untracked)
git add README.md        # stage it
git commit -m "Initial commit"   # save a snapshot
git log --oneline        # see your history

Good commit messages

Write them in the imperative, present tense: "Add health endpoint", "Fix port mapping". Short, specific, and explaining what the change does. Future-you will be grateful.

4

Ignore what shouldn't be tracked

A .gitignore keeps secrets and junk out of version control:

printf "__pycache__/\n*.pyc\n.env\nvenv/\n" > .gitignore git add .gitignore git commit -m "Add gitignore"

Never commit secrets

Passwords, API keys, and .env files must never be committed — once pushed to GitHub, bots find them in minutes. Add them to .gitignore from day one.

5

Branch & merge

Branches let you work on a feature without touching main. The standard workflow:

git switch -c add-description     # create + switch to a new branch
echo "A tiny notes web app." >> README.md
git add README.md
git commit -m "Describe the app in the README"

git switch main                  # back to main
git merge add-description        # bring the changes in

Why branch?

main should always be working/deployable. You build features on branches, then merge when they're ready — usually via a pull request (next step). This is the heart of team collaboration.

6

Push to GitHub

Create a new empty repo on GitHub (no README), then connect and push:

git remote add origin https://github.com/YOUR_USERNAME/notes-app.git git push -u origin main # upload; -u remembers this for next time

Refresh the GitHub page — your code is now online and backed up. ✅

Authentication

GitHub no longer accepts your account password on the command line. When prompted, use a Personal Access Token (GitHub → Settings → Developer settings → Tokens) as the password, or set up SSH keys.

7

Collaborate with a Pull Request

PRs are how changes get reviewed before merging — the backbone of team workflows (and CI/CD triggers).

git switch -c update-readme echo "Built during the DevOps Lab course." >> README.md git commit -am "Add course note to README" git push -u origin update-readme

On GitHub, click "Compare & pull request".
Add a title and description, then Create pull request.
Review the diff, then Merge it into main.
Back on your laptop: git switch main && git pull to get the merged change.

You now have the workflow

Branch → commit → push → pull request → merge. This exact loop is how virtually every software team ships code — and what triggers your CI/CD pipeline later.

Git Cheat Sheet

Command	What it does
`git init`	Start tracking a folder
`git clone <url>`	Copy a remote repo to your machine
`git status`	See what's changed
`git add <file>` / `git add .`	Stage changes
`git commit -m "msg"`	Save a snapshot
`git log --oneline`	View history
`git switch -c <branch>`	Create & switch to a branch
`git switch <branch>`	Switch branches
`git merge <branch>`	Merge a branch into the current one
`git push` / `git pull`	Upload / download commits
`git diff`	See line-by-line changes
`git restore <file>`	Discard local changes to a file

Troubleshooting

Symptom	Likely cause & fix
Push rejected (auth failed)	Use a Personal Access Token or SSH key, not your password.
`rejected ... fetch first`	Remote has commits you don't — `git pull` then push.
Merge conflict	Two changes clash — edit the marked lines, then `git add` + `git commit`.
Committed a secret by mistake	Rotate the secret immediately; removing from history is hard once pushed.
Committed to the wrong branch	Don't panic — branches are cheap. Ask before rewriting shared history.
`fatal: not a git repository`	You're not inside a repo — `cd` into it or `git init`.

Your Challenge

Add your backup.sh from Module 3 to the repo and commit it.
Create a branch, make a change, open a PR, and merge it on GitHub.
Use git log --oneline --graph --all to visualize your branch history.
Bonus: intentionally create a merge conflict in the README and resolve it.

# Git marks conflicts in the file like this:
<<<<<<< HEAD
your version
=======
their version
>>>>>>> other-branch
# Edit to keep what you want, delete the markers, then:
git add README.md
git commit

Recap & What's Next

You can now

Track changes with commits, branch and merge, push to GitHub, and collaborate via pull requests. You also created the notes-app repo you'll build on for the rest of the course.

Next up: Module 5 — Networking Basics, the last foundation — how apps actually talk to each other, which you'll need the moment you start running containers.