Status, Log & .gitignore

Seeing What's Going On

Command	Shows
`git status`	What's changed, staged, or untracked right now
`git log`	Commit history
`git log --oneline`	Compact one-line-per-commit history
`git diff`	Line-by-line unstaged changes
`git diff --staged`	What's staged for the next commit

git status is the single most-run Git command in the world, and for good reason - it doesn't just report state, it tells you what to type next:

$ git status
On branch main
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        modified:   readme.md

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
        modified:   app.py

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        notes.txt

Three different situations, three different meanings: readme.md is staged and will be in the next commit; app.py has been edited but that edit isn't staged yet; notes.txt is a brand-new file Git has never been told to track at all.

$ git log --oneline
a1b2c3d Add readme
9f8e7d6 Initial commit

Tip: git status is your best friend - run it constantly, especially before and after every add and commit. It literally tells you how to stage, unstage, or discard whatever it's showing you.

.gitignore - keep junk out

Some files should never be committed at all: secrets and API keys, build output your tools regenerate anyway, huge dependency folders, editor swap files. List patterns for them in a file named .gitignore at the project root, and Git will stop mentioning them in git status and never stage them with git add ..

# .gitignore
node_modules/
.env
*.log
dist/

Warning: .gitignore only affects files Git doesn't already know about. If a file was committed before you added it to .gitignore, Git keeps tracking it - ignoring it now does nothing retroactively. You have to explicitly stop tracking it with git rm --cached <file> (which removes it from future commits but leaves it on disk), then commit that removal.

Danger: Never commit secrets (.env, API keys, private keys). Once pushed, they're in history forever - even deleting the file in a later commit doesn't remove it from the earlier commits where it still exists; anyone who clones the repo can dig it out. Add sensitive filenames to .gitignore before the very first commit that would include them, and if a secret does slip in, rotate/invalidate it immediately rather than relying on rewriting history.