What is it?
Git is a version control system that tracks every change to every file in your project. GitHub (or GitLab, Bitbucket) is a hosted layer on top that adds pull requests, issues, and CI. Every team uses some flavor of this; without it you can't ship code with anyone else.
Why it matters
Git is the single most-asked tool in onboarding. A messy commit history, a 500-line PR, a force-push to main — these are the small mistakes that make seniors lose patience. Clean history and small PRs aren't pickiness; they're how teams stay fast.
What to learn
- The three trees: working directory, staging, repository
- Daily commands:
add,commit,push,pull,status,log - Branching:
branch,checkout,switch, naming conventions - Merging vs rebasing — when each is right
- Pull requests: writing a description, requesting reviews, addressing comments
- Conflict resolution without panicking
.gitignoreand what should never be committed
Common pitfall
Force-pushing to a shared branch. If anyone else has pulled, you've
silently nuked their commits. Force-push only on your own branch
that nobody else is using. Set git config --global push.default current
and learn git push --force-with-lease.
Resources
Primary (free):
- Pro Git book (free online) · docs
- GitHub — Git handbook · docs
- Oh Shit, Git!?! · article
Practice
Take any project and rewrite its history. Use git rebase -i HEAD~5 to
squash, reword, and reorder five recent commits. Push to a feature
branch (not main) with --force-with-lease. Done when the new history
tells a cleaner story than the original — and you didn't lose any code.
Outcomes
- Resolve a merge conflict without copying random Stack Overflow.
- Write a PR description that a reviewer actually wants to read.
- Choose merge vs rebase per situation, with a real reason.
- Recover from a "I deleted my work" moment using
reflog.