Just Enough GitHub

Version control fundamentals — Git basics, creating repositories, branching, and collaborating on GitHub.

What this video covers

Git tracks changes to files over time — who changed what, and when — so you can always go back to an earlier version if something breaks. Think “track changes,” but for code, and built for many people editing the same files at once. GitHub is a website that hosts Git projects: Git is the tool, GitHub is where the team stores and shares them. This lesson walks through installing Git, creating and cloning a repository, the handful of commands you’ll use daily, how pull requests keep bad changes out of production, and the automated checks (pre-commit hooks, GitHub Actions) that run behind the scenes on a real data team.

Key moments

• Why analysts need Git — nothing gets lost (bad changes can be reverted), multiple people can edit the same project without overwriting each other, changes get reviewed before they go live, and it’s the shared language with Engineering — if models live in Git, you need Git to work on them too.
• Installing Git — on Mac, the git --version prompt in Terminal or brew install git; on Windows, the installer from git-scm.com (which also gives you Git Bash); on Linux, apt/dnf.
• Repositories — someone creates the repo once on GitHub; as an analyst you’re usually just added to one that already exists, then git clone <url> downloads a full copy to your machine.
• The daily commands — git status, git add, git commit -m "...", git push, and the difference between git fetch (check what’s new) and git pull (check and apply it).
• Branches and pull requests — git checkout -b <branch-name> keeps your work separate until it’s reviewed; a pull request (PR) shows your changes line by line so a teammate can approve before anything reaches main.
• Pre-commit hooks — automatic checks that run right before a commit goes through, catching formatting issues, syntax errors, or accidentally committed secrets.
• GitHub Actions — the same checks run automatically on GitHub itself the moment a PR is opened, so nothing broken slips through even if someone skipped running checks locally.

What is Git, and why analysts need it

Git tracks changes to files over time — who changed what, and when — so you can always go back to an earlier version if something breaks. Think “track changes,” but for code, and built for many people editing the same files at once.

GitHub is a website that hosts Git projects. Git is the tool; GitHub is where the team stores and shares them.

Where it’s used: SQL scripts, dbt models, Airflow DAGs, notebooks, dashboard definitions — anywhere a data team’s logic lives as text files.

Why it matters for analysts:

• Nothing gets lost — bad changes can be reverted.
• Multiple people can edit the same project without overwriting each other.
• Changes get reviewed before they go live.
• It’s the shared language with Engineering — if models live in Git, you need Git to work on them yourself.

Installing Git

Mac

• Easiest: open Terminal, run git --version — if not installed, macOS prompts you to install Command Line Tools. Click install.
• Or via Homebrew: brew install git

Windows

• Download the installer from git-scm.com and run it (default options are fine).
• This also installs Git Bash, a terminal for running Git commands.

Linux

• Debian/Ubuntu: sudo apt install git
• Fedora: sudo dnf install git

Verify it worked (all platforms):

git --version

Creating a repository and cloning it

Create a repository (repo) — usually done once, often by whoever sets up the project:

1. On GitHub, click New repository.
2. Give it a name, choose Public or Private, and click Create repository.

Most of the time as an analyst, you won’t create the repo yourself; you’ll be added to one that already exists.

Clone it — downloads a copy of the repo onto your computer so you can work on it:

git clone <repository-url>

Example:

git clone https://github.com/your-team/analytics-dbt.git

You get the URL from the green Code button on the repo’s GitHub page. Run the command in the folder where you want the project to live. This creates a new folder with the project’s files and full history — you only need to clone a repo once.

Basic commands

git clone <url> Downloads a copy of a repo (with full history) to your machine. One-time, per project.

git fetch Checks GitHub for new changes and downloads them, but does not touch your working files — it just updates your local record of what’s on the server.

git pull Does a git fetch and then merges those changes into your current files. This is what actually updates the code you’re looking at.

Difference: fetch = “see what’s new, don’t touch my files.” pull = “see what’s new AND apply it.” pull is basically fetch + merge.

git status Shows what’s changed in your folder — new files, edited files, what’s staged and what isn’t. Your go-to command to check where things stand before doing anything else.

git add <file> (or git add . for everything) Stages a file — marks it as “ready to be included in the next commit.”

git commit -m "message" Saves the staged changes as a new version in your local history, with a short message describing what changed.

git push Uploads your committed changes from your machine to GitHub, so others can see them.

git branch -a Lists all branches — local ones and the ones that exist on GitHub (remote). Useful to see what other people are working on before you start something new.

git checkout -b <branch-name> Creates a new branch and switches you onto it, in one step. You do this so your changes stay separate from the main branch until they’re reviewed — e.g. git checkout -b fix-revenue-model.

Typical flow: git pull → make changes → git add → git status (check) → git commit -m "..." → git push

For everything else: Git Reference — git-scm.com

Pull requests and the merge process

A pull request (PR) is a request to merge your branch’s changes into the main branch. You push your branch to GitHub, open a PR, and it shows exactly what you changed, line by line.

Basic flow:

1. Push your branch: git push origin <branch-name>
2. On GitHub, open a PR from your branch into main.
3. A teammate reviews it — comments, requests changes, or approves.
4. Once approved, it gets merged into main, and your changes are now part of the shared project.
5. Delete the branch — its job is done.

The point of this: nothing reaches main (and production) without someone else looking at it first.

Pre-commit hooks

Pre-commit is a framework that runs automatic checks on your files right before a commit goes through — catching problems (formatting issues, syntax errors, secrets accidentally included, etc.) before they ever reach GitHub.

Install:

pip install pre-commit

Set up in a repo (usually a .pre-commit-config.yaml file already exists in the project, defining which checks to run):

pre-commit install

This hooks it into Git so the checks run automatically every time you commit.

Use it: just commit as normal — git commit -m "..." — and pre-commit runs the checks first. If something fails, the commit is blocked until you fix it (or, for checks like auto-formatting, it fixes the file and you just re-add and commit again).

To run it manually on everything, without committing:

pre-commit run --all-files

GitHub Actions — running pre-commit on every PR

GitHub Actions is GitHub’s built-in automation — it runs scripts automatically when something happens in the repo (like opening a PR). Instead of trusting everyone to run pre-commit locally, the team adds a workflow that runs those same checks automatically the moment a PR is opened.

This lives in a YAML file in the repo, e.g. .github/workflows/pre-commit.yml:

name: pre-commit

on:
  pull_request:

jobs:
  pre-commit:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
      - uses: pre-commit/action@v3.0.1

What happens: every time someone opens or updates a PR, GitHub spins up a fresh machine, checks out the code, and runs the same pre-commit checks. The result shows up directly on the PR as a green check or a red X — so a broken or unformatted file can’t slip through, even if someone skipped running it locally.

Next steps

Continue with Just Enough Docker — containers and Docker fundamentals for data roles.