Day 05/13 of Git 101 Series
Add, Commit, Amend
staging is where you prepare a snapshot. git add writes file contents into blobs and records what should go into the next commit in the index. git commit turns that index into a commit object that points at a tree. git commit –amend replaces the most recent commit with a new one that uses whatever is currently staged. Use amend to fix small mistakes before you push. Never amend public history that others depend on.
Concept Explanation
Git does not commit your working directory directly. It commits the contents described by the index, also called the staging area. The index is a binary file that lists which blobs (file contents) and tree structure should become the next commit. You stage changes to tell Git exactly what you want in the next snapshot. When you run git commit, Git takes the index, builds a tree object representing the staged file tree, writes a commit object that points to that tree and to its parent, and moves HEAD to that new commit.
Staging lets you:
Split large work into multiple logical commits
Craft clean, focused commit messages
Exclude WIP parts from the next snapshot
Commands — what to run and when
Basic workflow
stage a file or files
git add file1.txt file2.py
stage everything changed in the working tree
git add -A
show staged vs unstaged
git status
git diff
git diff --staged
create a commit from the index
git commit -m "Short, imperative message"
amend the previous commit with current staged state
git commit --amend -m "Improved commit message"
if you only want to change the message but not the tree
git commit --amend --no-edit # keeps existing message
Useful staging shortcuts
git add -p
git add -i
git restore --staged
If commit has been pushed and others may rely on it, do not amend. Amending rewrites history and will require force push.
If the commit is local and unshared, amend is efficient for small fixes.
Example
Scenario: you changed two files but only want to commit one change now.
edit a.txt and b.txt
git status
shows modified: a.txt, modified: b.txt
git add a.txt
git diff --staged
shows staged changes from a.txt only
git commit -m "Implement feature X in a.txt"
later realize you forgot to remove console.log in a.txt
make the fix, stage it
git add a.txt
fix commit message and include the tiny fix
git commit --amend -m "Implement feature X in a.txt; remove debug log"
Result: the last commit now contains the staged state at amend time. The old commit object still exists in the object database until garbage collection cleans it, but your branch reference now points at the new commit object.
Real world use case
polishing commit history
When preparing a feature branch for review:
Use git add -p to create small, logical commits from your working changes.
Write clear, imperative commit messages.
If you spot a small mistake in the last commit, stage the fix and run git commit –amend to fold the fix into the same logical change instead of creating a noisy extra commit.
If you need to rewrite multiple recent commits, use interactive rebase (git rebase -i).
Under Hood Explanation
git add
Git computes the blob object for the file contents: the contents are hashed with SHA-1 or SHA-256 depending on configuration and written into .git/objects as a blob object.
The index is updated to record the blob hash, file path, file mode, and timestamps. The index acts as the authoritative list of what will go into the next commit.
git commit
Git builds tree objects from the index. A tree records file names, modes, and either blob hashes or other tree hashes for directories.
Git writes the tree object to the object store.
Git creates a commit object containing:
the tree hash
parent commit hash(es)
author and committer metadata (name, email, timestamps)
the commit message
Git writes the commit object into the object database.
Git updates the current branch reference to point to the new commit.
HEAD now refers to that commit. Reflog records the move so you can recover previous positions.
Commit –amend specifics
git commit –amend essentially performs another commit creation but uses the parent of the previous commit as the parent for the new commit, unless you change parent pointers. It replaces the branch tip with the new commit object. The old commit stays in the object database until pruned.
you can read the series of @blogs in here. and i do write a lot in twitter @yswnth
Tomorrow : Day 06/13 of Git 101 Series - Status, Log, Diff