Everyday Git is moving work between four places: the working tree, the staging area, the local repository, and a remote. This page explains those places, the commands that move and inspect work between them, a commit workflow, and why secrets must never be committed.
Git’s four places
Almost every everyday Git command either inspects or moves content between four places: the working tree, the staging area, the local repository, and a remote repository.
flowchart LR accTitle: Git's four places and the commands that move work between them accDescr: git add moves changes from the working tree to the staging area, git commit records them in the local repository, git push publishes them to the remote, and git fetch brings remote history back into the local record without touching files. W[Working tree] -->|git add| S[Staging area] S -->|git commit| L[Local repository] L -->|git push| R[Remote repository] R -->|git fetch| L
| Place | What it holds |
|---|---|
| Working tree | The files you see and edit |
| Staging area (index) | The exact content prepared for the next commit |
| Local repository | Commit history on this machine; HEAD normally marks the current branch’s latest commit |
| Remote repository | For example origin; origin/main is your local record of it, only as fresh as your last fetch |
As defined in the operations reference.1 git init creates the hidden .git/ directory that holds the local repository; before that, Git does not know the folder exists.2
Moving and inspecting
git add moves chosen changes into the staging area, git commit records them in history, git push publishes, and git fetch updates remote-tracking branches without touching your files.1 The staging area exists so you can split mixed changes into separate, clean commits, such as a bug fix and a docs update.3
git diff compares the working tree with the staging area; git diff --staged compares the staging area with the last commit; git diff HEAD skips the distinction.4
Divergence
When local and remote history have both moved on from a common commit, Git cannot guess whether you want a merge or a rebase, so it asks for an explicit strategy.1 See Syncing a Git branch.
Basic commands
The seven commands a beginner uses daily, in the order they usually come up.
| Command | Does | Useful flags | Pitfall |
|---|---|---|---|
git init | Turns a folder into a repository | -b main sets the initial branch; --bare for a server-side remote | Never delete .git and re-init an existing repo; do not init in ~ |
git clone | Copies a remote repository with all history and records it as origin | --branch, --depth 1 (shallow), --recurse-submodules | A shallow clone lacks history; git fetch --unshallow before rebase or full log |
git add | Stages chosen changes | -p per hunk, -u tracked files only, -A whole repo | git add . can catch .env files; re-add a file edited after staging |
git status | Shows branch, staged, unstaged, untracked | -s: left column is staging area, right is working tree | Read-only, so run it often |
git commit | Records the staging area as a snapshot with a hash | -m, -a (tracked files only), --amend | Never amend a commit others already pulled; use git revert |
git log | Shows history, newest first | --oneline, --graph --all, -p, --stat, --follow -- file | Press q to leave the pager |
git diff | Shows exact line changes | --staged, --stat, --word-diff | Check --staged before committing so debug code does not slip in |
Collected from the seven chapters.2536784
Reading git status -s
?? is untracked, M modified but not staged, M staged, MM staged then modified again, A a new staged file, and D deleted but not staged.6
Commit messages
The tutorial recommends the Conventional Commits style: a type such as feat, fix, or docs, then a short imperative description under 50 characters, with an optional body explaining why.7 The GitHub guide adds a caution: follow the repository’s existing style and do not add prefixes unless the project uses Conventional Commits.9
Commit workflow
A safe commit is a short loop of look, stage precisely, look again, commit, confirm.
git diffto see what actually changed.git add path/to/filewith explicit paths, so unrelated files stay out; the GitHub guide calls this safer for beginners thangit add ..git diff --stagedto review exactly what the commit will contain; forgetting it is how debug calls and temporary code slip into commits.4git commit, which creates local history only.git show --stat HEADto confirm the commit and its scope.
Before pushing, confirm the branch and target with git branch --show-current, git branch -vv, and git remote -v, then push to an explicit remote and branch.1
If you staged the wrong file, git restore --staged path/to/file keeps the edit but removes it from the next commit.9
Keeping secrets out of Git
Tokens, private keys, .env files, kubeconfig, cloud credentials, production backups, and customer data never belong in a commit.1
Why cleanup does not work
.gitignoreonly affects files that are not yet tracked; adding a rule does not remove a committed file.git rm --cachedstops tracking a file from now on, but leaves it in history and does not invalidate a leaked credential.1- Making a repository private after pushing a secret does not make the secret safe.9
If a credential leaks
Revoke or rotate it first, then assess access logs and exposure, and only then use the platform’s approved history-cleanup process.1
Prevention
git add . will happily pick up .env files, so check git status before committing and add sensitive files to .gitignore.3 Stage explicit paths and review git diff --staged.9