Git & GitHub: How to Push
- git
- github
- commit
- push
- pull request
- conventional commits
- branches
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:
| Zone | What it is | Command to move forward |
|---|---|---|
| Working directory | The files you're editing right now | - |
| Staging area | A "shopping basket" of changes you've chosen to save | git add |
| Repository | The permanent, saved snapshot | git commit |
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
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.
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:
mainis 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:
| Type | When | Example |
|---|---|---|
feat: | a new feature | feat: add CAPM beta calculator |
fix: | a bug fix | fix: handle divide-by-zero in returns |
docs: | documentation | docs: explain the Sharpe formula |
refactor: | tidy code, no behaviour change | refactor: extract risk helper |
test: | tests | test: cover edge cases in PSI |
🔧 Try it for real (5 minutes, your own machine)
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.)