Git for Beginners: Working Directory, Staging Area, Repository, Common Commands, and a Complete Workflow

Git is an essential version control tool, but many get stuck on concepts like "why do we need a staging area" and "what's the difference between commit and push." This guide starts with the three areas, gives a common command list, and walks through a complete workflow — follow along once and you will have it. All commands work in macOS and Linux terminals as well as Windows Git Bash. For more developer tools, follow the dev tools category.

1. The Three Areas: Working Directory, Staging Area, Repository

  • Working directory: the folder you are editing; changes happen here first;
  • Staging area (index): the "to-do list" before committing. Use git add to place changes you want to commit — like picking what to pack;
  • Repository (.git): where Git actually stores history; only git commit permanently records the staged content.

In one sentence: add picks; commit stamps and archives.

Configure your identity first: run git config --global user.name "Your Name" and git config --global user.email "[email protected]" so commits carry an author. To ignore temporary files (caches, secrets, logs), create a .gitignore in the repository root and list the filenames. A typical loop is: edit files → git status to see changes → git add to pick → git commit to archive → git push to sync; repeating this loop is everyday development. For an existing project, git clone <repo-url> copies it locally with the full history — more complete than a manual download.

2. Common Command List

Command What it does
git init Initialize a repository in a directory
git status Show the current change state
git add <file> Add changes to the staging area
git commit -m "message" Archive the staged content
git log Show commit history
git branch List or create branches
git checkout -b <branch> Create and switch to a branch
git push origin <branch> Push local commits to remote
git pull Pull the latest remote code

These commands cover 80% of daily work: init to start, add+commit to record changes, push/pull to sync, log to review, and branch/checkout to switch lines of work. When stuck, run git status — it is Git's built-in hint for "where am I and what can I do next." To see which files a commit changed, run git show <commit>.

3. Branches and Merging

A branch is a parallel line of development. The main line is called main (formerly master). When building a feature, create a branch, finish it, then merge back into main to avoid chaos.

main: A -- B -- C
                \
feature:          D -- E  →  merge back to main

In team work, git pull before developing, and resolve conflicts manually when they occur. For common patterns, see Git workflow for website development. During a conflict, Git marks the differences between <<<<<<< HEAD and >>>>>>>; pick the content, git add, then git commit. Name branches descriptively, like feature/add-nav, fix/typo, or docs/readme, instead of test1 or asdf. After merging back to main, delete the feature branch (git branch -d <branch>) to keep the list clean.

4. A Complete Workflow Example

Deploying a static site, for example:

# 1. Initialize and make the first commit
git init
git add .
git commit -m "init: first commit"

# 2. Push to remote (create the remote repo first)
git remote add origin [email protected]:you/site.git
git push -u origin main

# 3. Develop a new feature
git checkout -b add-nav
# ...edit files...
git add .
git commit -m "feat: add navigation"

# 4. Merge back to main and push
git checkout main
git pull
git merge add-nav
git push

# 5. View history
git log --oneline

To deploy automatically, trigger CI/CD after push — see GitHub Actions CI/CD and website CI/CD pipeline.

Tip: make each commit do one thing with a clear message so rollbacks are fast. Use prefixes like feat:, fix:, and docs: to skim git log quickly. Pull before you push so you reduce conflicts when others have pushed new commits.

5. Advanced Commands Cheat Sheet

Command What it does
git diff Show unstaged changes in detail
git stash Temporarily shelve uncommitted changes
git log --oneline View history in a compact list
git reset --soft HEAD~1 Undo the last commit but keep changes
git revert <commit> Undo with a new commit, without rewriting history
git rm --cached <file> Stop tracking a file but keep it locally

reset rewrites history; revert does not. For commits already pushed and shared, prefer revert. To see who changed a specific line, run git blame <file>; to hunt down a regression, git bisect does an automatic binary search. If you staged a file by mistake, git reset <file> unstages it.

6. FAQ

Q: What's the difference between commit and push?
commit archives locally; push syncs the archive to the remote. Commit without push, and others will not see your changes.

Q: What if I accidentally commit sensitive information?
Remove the file and rotate the secret immediately. If already pushed, treat it as leaked and replace it. For safer practices, see the Git deployment workflow.

Q: Can I fix a wrong commit message?
For the last commit, use git commit --amend -m "new message". Rewriting history on pushed branches rewrites history — use sparingly in team settings.

Q: How do I split changes into multiple commits?
Use git add <file> to stage specific files instead of git add . for everything, then commit each group separately — history stays cleaner.

Q: What is the difference between git fetch and git pull?
fetch downloads the latest remote state locally without touching your working tree; pull is fetch + merge, merging into the current branch. When you want to look before merging, fetch is safer.