Learn IT Fundamentals with Teacher PochiGit Basics
Key points
- Changes in Git are recorded into history through three stages: "working directory" → "staging area" → "repository."
addmoves a change to the staging area,commitrecords it into history, andpush/pullexchange history with a remote.- Grammar matters less than being able to picture which stage your current changes are sitting in.
directory
area
(history)
Keeping track of three locations
The first thing that trips people up in Git is losing track of "which stage am I working in right now." Git has three distinct locations, and files move through them in order.
🔑 A familiar exampleThink of shipping a parcel. The "working directory" is you packing at home, the "staging area" is the items you've picked and lined up by the door, and the "repository" is the package once it's actually been shipped and logged.
git add: move to the staging area
git add is how you pick, out of everything you've changed, what you want to include in the next commit. You don't have to commit every change at once — you can group only the related changes together.
you changed
(pick)
to staging
For example, if you edited a "login fix" and a "minor visual tweak" at the same time, you can add just the login fix first, keeping each commit focused on one logical change.
git commit: record into history
git commit takes whatever is in the staging area and records it as a single checkpoint in the repository's history. Along with the change itself, a commit carries a short description called a "commit message."
area
(one frame of history)
Leaving a message like "Fix login button bug" — one that makes sense when read later — matters a lot in team development.
🔑 A familiar exampleIt's like keeping a diary. Instead of just writing "made a change," adding a line about "what and why" makes it much easier to remember the situation when you read it back later.
git push: send to the remote
Everything up to this point — add and commit — happens entirely within your own local repository. git push sends that local history to a shared repository (a "remote") such as GitHub.
(local)
(remote)
Only after pushing do your changes actually become visible to the rest of the team.
git pull: bring in remote changes
git pull is the opposite of push: it brings the latest history from the remote repository down to your own machine. Use it whenever you want to bring changes made by other members into your own environment.
(remote)
(local)
Pulling before you start work is a basic habit in team development. If your local copy is out of date, you're more likely to run into conflicts with other people's changes later.
Commands for checking status
Between operations, you'll often want to check the current state of things. git status shows which files are changed or staged, and git log shows the commit history so far.
🔑 A familiar exampleIt's the same instinct as glancing back at your work to check "where did I get to?" Making it a habit to run status first whenever you're unsure keeps you oriented.
Summary
Git's basic operations come into focus once you grasp the three-stage flow of working directory, staging area, and repository, plus push and pull for exchanging history with a remote. Early on, focusing on "which stage am I in right now" is a faster path to fluency than memorizing syntax.
Related topics: