Git and GitHub: The Commands You Need

10 minute read · Last updated 2026-10-31 · Written and reviewed by the Code.House editorial team

Git tracks snapshots of a project over time. GitHub is a hosting service for those snapshots plus collaboration tools on top. Most people only need about a dozen commands, plus a clear idea of what each one moves.

The three places your work lives

Every change passes through three areas: the working directory (files as they are now), the staging area (changes marked for the next snapshot), and the repository (committed history). Nearly every confusing Git moment comes from losing track of which area something is in.

git status            # what changed, and where it sits
git add file.py       # working directory -> staging
git add .             # stage everything changed
git commit -m "Add tax calculation"   # staging -> repository
git log --oneline     # the history, one line per commit

Write commit messages that say what changed and why. "Fix bug" tells a future reader nothing; "Fix rounding error in tax total for multi-currency orders" tells them everything.

Branching

git switch -c feature/contact-form   # create and move to a branch
# ...work, add, commit...
git switch main
git merge feature/contact-form
git branch -d feature/contact-form

A branch is a movable label pointing at a commit — creating one is instant and costs nothing. Keep main deployable and do work on short-lived branches. Long-lived branches drift and produce painful merges.

Working with a remote

git clone https://github.com/user/project.git
git pull                 # fetch and merge others' work
git push                 # publish your commits
git push -u origin feature/contact-form   # first push of a new branch

Pull before you start work, and push often. The longer local and remote histories diverge, the harder the eventual reconciliation.

Pull requests

A pull request proposes merging one branch into another and gives people a place to review the change. A good one is small, has a description that explains the intent, and passes whatever automated checks the project runs. Reviewing in chunks of a few hundred lines catches far more than reviewing a thousand-line change, where attention collapses.

Undoing things

Prefer revert over reset for anything already pushed: it adds a new commit that undoes the change rather than rewriting history other people have pulled. And a committed secret is not removed by deleting the line in a later commit — rotate the credential, because the old commit still contains it.

A .gitignore that saves grief

.venv/
node_modules/
.env
*.log
.DS_Store
dist/

Environment files and dependency folders do not belong in version control. The first leaks credentials; the second bloats the repository and conflicts constantly.

Common questions

Is GitHub the only option?

No. GitLab, Bitbucket, Codeberg and self-hosted options all speak the same Git protocol. The commands in this guide are identical across them.

What is the difference between git switch and git checkout?

checkout does several unrelated jobs. switch (branches) and restore (files) were introduced to split those jobs into clearer commands. Both still work.

Keep reading

Spotted something out of date? Send a correction — guides are revised rather than quietly deleted.