If you have used git by copying commands off a colleague's screen and hoping, this chapter is for you. Nothing here is advanced. It is the set of ideas that everything else assumes.

Git is a program that runs on your machine and records versions of your files. It works with no internet connection and no account anywhere. GitHub is a website that holds a shared copy of a git project and adds the things git has no opinion about — a place to discuss a proposed change, issue tracking, who is allowed to do what, and automation that runs when something happens.

You can use git entirely on your own, forever, and never create a GitHub account. Plenty of people do.

git switch -c fix-login-timeout     # make a branch and move onto it
                                    # ...edit files...
git add .                           # choose what goes in this checkpoint
git commit -m "Raise login timeout to 30s; the gateway was cutting us off"
git push -u origin fix-login-timeout

# then open the pull request — on the website, or:
gh pr create --fill

The commit message is worth more care than it usually gets. In two years somebody will ask why a line exists, run the command that shows who last changed it, and get your sentence back as the only surviving explanation. Write why you changed it. The diff already shows what you changed.

A pull request is a request to merge one branch into another, wrapped in a page where people can discuss it line by line. It is not a git concept at all — git has no such command — which is exactly why you cannot find it in git's documentation. GitHub invented it; GitLab calls the same idea a merge request.

What it is for is the interesting part. Not gatekeeping. A pull request is the place where a change is explained to somebody who was not in your head when you wrote it, and where automated checks report before anyone spends attention. A good pull request description says what problem this solves and how you know it works. A bad one repeats the commit messages.

GitHub Actions runs commands automatically when something happens in the repository — most commonly, running the tests every time a pull request opens. It is a file in your project describing what to run and when:

# .github/workflows/test.yml
name: tests
on: [pull_request]          # run this whenever a PR is opened or updated

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4      # get the code
      - run: pip install -r requirements.txt
      - run: pytest

The point is not automation for its own sake. It is that a reviewer should never be the first thing to discover the tests fail. By the time a human looks, the machine should already have said whether it builds and passes.