How Git Works
Working directory, staging area, local and remote repositories — and the commands that move changes between them.
Git keeps your project in four places. Knowing which command moves changes between which places makes Git predictable instead of magical.
Every delivery pipeline starts here: a commit pushed to a branch is the event that triggers builds, tests and deployments.
Diagram
Key concepts
- Commit
- An immutable snapshot of the project with a message, author and parent commit.
- Branch
- A movable pointer to a commit. Creating one is instant and cheap.
- Merge vs rebase
- Merge joins histories with a merge commit; rebase replays your commits on top of another branch for a linear history.
- Pull request
- A request to merge a branch, with review and automated checks.
- Trunk-based development
- Short-lived branches merged to main often, with feature flags for unfinished work.
Trade-offs
Benefits
- Full history and easy rollback
- Cheap branching for parallel work
- Works offline; every clone is a full backup
Costs
- Merge conflicts on long-lived branches
- Rewriting shared history causes confusion
Use it when
- Every codebase, including infrastructure as code and documentation
Common mistakes
- Force-pushing a shared branch
- Committing secrets — they stay in history even after deletion
- Huge, long-lived feature branches
Interview questions
Q1What is the difference between git fetch and git pull?
fetch downloads new commits from the remote without changing your branch. pull fetches and then merges (or rebases) them into your current branch.Q2When should you not rebase?
On commits others have already pulled, because rebasing rewrites their hashes and forces everyone to reconcile.
Q3A secret was committed. Is deleting the file enough?
No. It remains in history and in clones. Rotate the secret immediately, then purge it from history if needed.