Git, terminal & environments
Version control for your code, the command line to run it, and isolated environments so projects don't collide.
In plain terms
Git is 'track changes' for code: every save (commit) is a checkpoint you can return to. The terminal is texting your computer commands instead of clicking. A virtual environment is a separate toolbox per project so Project A's tools never break Project B.
Why it matters
AI projects churn: you'll try five prompt versions, three libraries, and break things constantly. Git lets you experiment fearlessly because you can always roll back. Employers also read your GitHub as your portfolio.
How it works
Core loop: git add . (stage changes) -> git commit -m "message" (checkpoint) -> git push (upload to GitHub). Environments: python -m venv .venv, activate it, then pip install packages into it - not into your whole computer.
When you use it
Every project, from the first hello-world. Committing small and often is the habit that matters.
Common mistakes
- Committing API keys or huge data files (use
.gitignore). - One giant commit called 'final version 2 REAL' instead of small labeled steps.
- Installing everything globally, then wondering why an old project stopped working.
Best practices
- Commit every time something works, before you try the next risky change.
- Write a
requirements.txt(or useuv) so anyone - including future you - can recreate the project. - Put a README with a run command in every repo.
Try it yourself
Create a repo, make three commits, break your script on purpose, and use git diff + git checkout to see and undo the damage.
Resources
- Oh My Git! (game) Learn git visually by playing.
- GitHub's Hello World guide Repo -> branch -> commit -> PR in 10 minutes.