Git & GitHub: How to Push

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

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

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.

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

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)

mkdir my-first-repo && cd my-first-repo
# start tracking this folder
git init
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.)