Git & GitHub — How Code Actually Ships 🐙

Picture this. You spend two days building a brilliant trading model. It works perfectly... on your laptop. Now your teammate needs it, your boss wants to review it, and it has to run on a server. Do you email a zip file? Drop it in a shared folder and pray nobody overwrites your work?

No. You use Git — and so does every professional engineer on the planet. This one skill is the difference between "I can code" and "I can ship."

Git vs GitHub — don't mix them up. Git is the tool on your machine that records every change you make. GitHub is the website that stores your Git project in the cloud so a team can share it. (GitLab and Bitbucket do the same job.)

🧠 The mental model: a save-game with infinite slots

Think of Git like the save system in a video game — but you can save anywhere, name every save, branch the timeline, and instantly jump back to any save if you mess up. A commit is one save. GitHub is the shared cloud save your whole party can load from.

The 3 zones (this is the part everyone gets confused by)

Your changes travel through three places:

Then git push uploads your commits to GitHub.

One-liner to remember: Stage it (add), snapshot it (commit), ship it (push).

The 4 commands that do 90% of the work

bash
git status                              # what changed? (run this constantly)
git add .                               # put ALL changes in the basket
git commit -m "feat: add Sharpe ratio"  # take the snapshot (locally)
git push origin main                    # upload it to GitHub

Branches & Pull Requests — how teams avoid chaos

On a real team you never push straight to main (the live, shared version). You make a branch (your own copy of the timeline), do your work, push the branch, and open a Pull Request (PR) — a polite "please review and merge my changes" that teammates approve first.

bash
git checkout -b feature/sharpe   # branch off — your private workspace
# ...work, add, commit...
git push origin feature/sharpe   # then open a PR on GitHub

Analogy: main is the published book. You draft your chapter on a branch. The PR is submitting it to the editor — it only joins the book after review.

Conventional Commits — write messages a human (and a robot) can read

Good commit messages follow type: description:

🔧 Try it for real (5 minutes, your own machine)

bash
mkdir my-first-repo && cd my-first-repo
git init                                 # start tracking this folder
echo "# My Project" > README.md
git add README.md
git commit -m "docs: initial commit"
# create an empty repo on github.com, then:
git remote add origin https://github.com/<you>/my-first-repo.git
git push -u origin main

Refresh your GitHub page — your file is in the cloud. You just shipped. 🎉

Your Task

Build a conventional commit message for a new feature, then print the three commands that ship it. (Run it, then try changing change_type to "fix" and re-run — see how the message updates.)