Python and Git, Before You Touch Flask: A Crash Course for Beginners

A few people following the Flask maintenance tracker series told me they got lost around the models post, not because Flask is hard, but because they were learning Python syntax while following the tutorial. Fair. That series moves at an intermediate pace on purpose.

So here's the part before the part. Quick, no fluff, just enough to make the rest of what I write actually make sense. I already covered virtual environments in an earlier post; this one builds on that.

I'll say this upfront: You can use AI tools to speed up; I used AI tools while learning some hard stuff, and I still do today to get a boilerplate of what I need, and I think that's a completely reasonable way to speed up a beginner's path today, as long as you're still the one running the code and understanding why it works. This post is the version of that I'd have wanted when I started.

Python, Just Enough

Variables and types: Python doesn't make you declare a type up front:

name = "Regha"
age = 5
is_active = True

Functions: reusable blocks of logic:

def greet(name):
    return f"Hello, {name}"

print(greet("Regha"))

Loops and conditionals: the two things you'll write constantly:

for number in range(5):
    if number % 2 == 0:
        print(f"{number} is even")
    else:
        print(f"{number} is odd")

Lists and dictionaries: the two data structures that show up everywhere, including in every Flask model you'll write:

equipment_names = ["Dispenser 1", "Dispenser 2", "Generator A"]

equipment_record = {
    "name": "Dispenser 1",
    "type": "dispenser",
    "station": "Station A",
}

That's genuinely most of what you need to follow the Flask series without getting lost in syntax. Classes matter too; every model in the tracker series (class Equipment(db.Model):) is just a Python class, but that's worth its own post rather than a rushed paragraph here.

Git, Just Enough

Git is not optional if you're building anything real. It's not about collaboration first — it's your undo button. I've personally lost work to a bad edit and gotten it back purely because I'd committed ten minutes earlier.

Starting a repo:

git init

Checking what's changed:

git status

Staging and committing:

git add .
git commit -m "Add equipment model"

Write commit messages that describe what changed, not "update" or "fix." Future-you, six months from now, will thank present-you.

Seeing your history:

git log --oneline

Ignoring files you don't want tracked: create a .gitignore file:
pycache/
.pyc
venv/
.env
.db
instance/

This matters more than it looks. Without it, you'll eventually commit your local database or your secret keys straight into a public repo, a genuinely common beginner mistake, and an embarrassing one to walk back.

Connecting to GitHub and pushing:

git remote add origin https://github.com/yourusername/your-repo.git
git push -u origin main

Cloning an existing repo (say, if you want to pull down the maintenance tracker code yourself):

git clone https://github.com/iamregha/Maintenance-Tracker.git

Where to Go From Here

If all of that made sense, you're ready for Part 1 of the maintenance tracker series, the models, and everything after it. If any of it felt shaky, that's fine too; sit with it for a day, actually type the commands instead of just reading them, and come back.

What tripped you up first, Python itself, or Git? I'm asking because it'll tell me what the next crash course should be.