Git Basics For Beginners

TLDR

git init (Turns the current folder into a repo)
git clone <url> (Downloads someone else's repo)
git status (Shows what's changed)
git add <file> (Stages a file)
git commit -m "message" (Saves a snapshot)
git push (Uploads your commits)
git pull (Downloads everyone else's commits)

The Actual Explanation

If you've ever ended up with a folder full of files named project_final.py, project_final_v2.py, and project_final_v2_ACTUALLY_FINAL.py, you already understand the problem Git solves. Git is a version control system — it keeps a full history of every change you've made to a project, so you can always go back, compare, or undo, without ever needing to rename a file "final" again.

A Git-tracked project is called a repository (or "repo" for short). To turn any folder into one, navigate to it in your terminal and run:
git init

If you're starting from a project that already exists somewhere else (like on GitHub), you don't need git init at all — you clone it instead, which downloads the whole repo, history included:
git clone <repository-url>

Staging and Committing

Git doesn't save every change automatically — you decide when a set of changes is worth keeping. This happens in two steps.

• Staging tells Git which changed files you want to include in the next snapshot: git add filename.py (or git add . to stage everything that's changed).
• Committing actually takes that snapshot and saves it to the project's history, along with a short message describing what changed: git commit -m "Fix the login bug"

Run git status at any point to see what's been changed, what's staged, and what isn't tracked yet — I run it constantly, and you should too.

Working With a Remote (GitHub)

A commit only exists on your machine until you upload it. The copy of the repo that lives online (on GitHub, GitLab, etc.) is called a remote. Once your remote is set up:

• git push uploads your local commits to the remote.
• git pull downloads any commits made by others (or by you, on a different machine) and merges them into your local copy.

A good habit: git pull before you start working, and git push once you're done, so your local copy and the remote don't drift too far apart.

Branches, Briefly

A branch is an independent line of development. Every repo starts on one (usually called main), but you can create new ones to work on a feature without touching the working version: git branch new-feature creates a branch, and git checkout new-feature (or git switch new-feature) moves you onto it. When you're happy with the change, you merge it back into main. This is genuinely a whole topic on its own, so I won't pretend to cover it fully here — just know it exists.

One More Thing: .gitignore

Not everything in a project folder belongs in version control — things like build output, dependency folders, or files containing secrets should stay out of your repo entirely. Add a file named .gitignore to your project root and list one pattern per line (e.g. __pycache__/ or .env) to tell Git to ignore them.

Troubleshooting

1. "nothing to commit, working tree clean" when you run git commit means you forgot to git add your changes first. Git can't commit what hasn't been staged.
2. Merge conflicts happen when Git can't automatically combine two sets of changes to the same lines of a file. Git will mark the conflicting section directly in the file — open it, decide which version (or combination) you want to keep, remove the conflict markers, then git add and git commit as usual.

That's genuinely most of what you'll use day to day. If you're just getting started with a Python project too, check out my other post, Python Virtual Environments For Beginners, to round things out.