Sefism.Linux, terminal and Git: Windows

Tauseef Fayyaz

Chapter 05

Git fundamentals

How Git stores work, the daily commands, branching and merging, conflicts, and undoing mistakes safely.

Commits and snapshots

Also called commit, hash, HEAD

What: A commit is a snapshot of the whole project plus a message, author and a pointer to its parent commit, identified by a hash. HEAD points at where you are now.
Why: With this model, branches, merges and undoing all become moves of pointers on a graph.

Watch out

Learning commands as recipes without the model, then panicking at anything unusual.

Working tree, staging area and repository

Also called staging area, index, git add, git status

What: Changes move from the working tree (your files) to the staging area with git add, then into history with git commit.
Why: Staging lets you choose exactly what goes into each commit, even parts of a file.

Shell

git status
git add src/cart.js
git add -p            # choose hunks
git diff --staged     # what will be committed
git commit -m "Fix crash on empty cart"

Watch out

git add . and committing without reading the diff.

git log and git diff

Also called history, git show, git blame

What: git log shows history, git diff shows changes, git show shows one commit and git blame shows who last changed each line.
Why: Reading history tells you why code is the way it is and when a bug arrived.

Shell

git log --oneline --graph --all
git log -p -- src/cart.js
git diff main...feature
git show a1b2c3d
git blame src/cart.js

Commit messages

Also called Conventional Commits

What: A short imperative summary of about 50 characters, a blank line, then a body explaining why when needed. Some teams add prefixes such as feat: and fix:.
Why: Good messages make review, debugging and release notes far easier.
Example: Fix crash when cart is empty followed by a body explaining the cause and linking the issue.

Watch out

Messages such as "update" or "final fix 2" that explain nothing.

.gitignore

Also called gitignore file

What: A file listing patterns Git should not track, such as dependencies, build output, logs and secrets.
Why: Keeps repositories small and stops secrets and machine-specific files being committed.

Code

node_modules/
.venv/
dist/
*.log
.env
.DS_Store

Watch out

Adding a file to .gitignore after it is tracked; you also need git rm --cached file.

Branches

Also called git switch, git branch

What: A branch is a movable name pointing at a commit. New commits move the current branch forward.
Why: Cheap branches let you work on each change separately and keep main working.

Shell

git switch -c fix-empty-cart
git switch main
git branch -a
git branch -d fix-empty-cart

Watch out

Working directly on main and struggling to open a clean pull request later.

git stash

What: Saves uncommitted changes on a stack and cleans the working tree, so you can switch tasks and restore them later.
Why: Useful when you must switch branches quickly without making a half-finished commit.

Shell

git stash push -m "wip cart"
git stash list
git stash pop

Watch out

Leaving work in the stash for weeks and forgetting it exists; a work-in-progress branch is safer.

Merge

Also called fast-forward, merge commit

What: Combines another branch into the current one, with a merge commit when histories diverged or a fast-forward when they did not.
Why: Keeps the true history of how work came together, and is safe on shared branches.

Shell

git switch main
git pull
git merge fix-empty-cart

Rebase

Also called interactive rebase, git rebase -i, squash

What: Replays your commits on top of another branch, creating new commits with new hashes. Interactive rebase lets you reorder, squash and reword your own commits.
Why: Gives a straight, readable history and tidy commits before review.

Shell

git switch feature
git fetch origin
git rebase origin/main
git rebase -i HEAD~3
git push --force-with-lease

Watch out

Rebasing commits other people have already pulled, which rewrites their history.

Merge conflicts

Also called conflict markers

What: When two branches change the same lines, Git stops and marks the file with <<<<<<<, ======= and >>>>>>> sections for you to resolve.
Why: Resolving conflicts well protects both people's work.

Shell

git status               # lists conflicted files
# edit the file, remove the markers
git add src/cart.js
git commit               # or: git rebase --continue
git merge --abort        # start over

Watch out

Accepting one side everywhere without reading, silently dropping a teammate's change.

Undoing changes

Also called git restore, git revert, git reset, amend

What: restore discards or unstages changes, commit --amend fixes the last local commit, revert adds a commit that undoes another, and reset moves a branch back.
Why: Choosing the right undo keeps shared history intact and avoids losing work.

Shell

git restore file.js
git restore --staged file.js
git commit --amend
git revert a1b2c3d        # safe on shared branches
git reset --soft HEAD~1   # local only

Watch out

git reset --hard or force-pushing to fix a mistake already on a shared branch.

git reflog

Also called reflog

What: A local log of every position HEAD has been at, including commits no branch points to any more.
Why: After a bad reset or rebase, reflog usually finds the "lost" commits so you can restore them.

Shell

git reflog
git switch -c rescue a1b2c3d

Watch out

Assuming committed work is gone without checking the reflog first.

Go deeper