Basic Snapshotting

• git status → Show working directory status
• git add <file> → Stage a file
• git add . → Stage all changes
• git reset <file> → Unstage a file
• git commit -m "message" → Commit staged changes
• git commit -am "message" → Add & commit tracked files in one step

git status

git status [options] [--] [<pathspec>…]

# Basic status check: → Shows branch, staged changes, unstaged changes, and untracked files.
git status

# Check specific file status:
git status file.txt

# Short format:
git status -s → Compact output with symbols (M = modified, ?? = untracked).

# Show branch info in short format:
git status -sb

• Description: The git status command shows the current state of your working directory and staging area.
• Usage: It shows staged changes (ready to commit), unstaged changes (modified but not yet added), lists untracked files (new files not yet added), displays branch information and whether your branch is ahead/behind the remote.
• Think Tank: Status options to work with:

• Best Practices:
  • Run git status frequently to avoid confusion about file states.
  • Use -s for quick checks in large projects.
  • Combine with git diff to see actual changes.
  • Use --ignored to confirm ignored files are working as expected.
  • Always check status before committing or pushing to avoid mistakes.

Git - git-status Documentation

git-status Documentation

git add

git add [options] [--] <pathspec>...

# Stage a single file:
git add file.txt

# Stage multiple files:
git add file1.txt file2.txt

# Stage everything (tracked and untracked):
git add -A

# Stage changes in the current directory:
git add .

# Stage only tracked files’ modifications:
git add -u

# Interactive staging (choose hunks):
git add -p

• Description: The command git add moves changes into the staging area, giving you precise control over what goes into each commit.
• Usage:  It stages new files by tracking untracked files, add changes to already-tracked files, stage parts of files or specific hunks, changes aren’t recorded in history until git commit.
• Think Tank: . stages all changes in current directory
• Best Practices:
  • Review before committing: Run git status and git diff --staged to confirm exactly what will be committed.
  • Use .gitignore: Prevent accidental staging of build artifacts, secrets, and temporary files.
  • Prefer -p for clean history: Stage only relevant hunks to keep commits focused.
  • Be explicit in large repos: Use pathspecs or lists instead of blanket . or -A.
  • Normalize line endings: Define *.txt text eol=lf or platform-appropriate rules in .gitattributes.

Git - git-add Documentation

git-add Documentation

Working of Commit

• Staging area → Commit: Only changes staged with git add are included.
• Commit object: Contains:
  • Tree: Snapshot of project files.
  • Parent(s): Link to previous commit(s).
  • Author/committer info: From git config.
  • Message: Describes the commit.
• Branch update: HEAD moves forward to point to the new commit.

git commit

git commit [options] [--] [<pathspec>...]

# Commit staged changes with a message:
git commit -m "Add new feature"

# Commit all tracked changes directly:
git commit -a -m "Fix bug in module"

# Amend the last commit:
git commit --amend -m "Corrected commit message"

# Commit interactively:
git commit -p

# Commit only specific files:
git commit file1.txt file2.txt -m "Update selected files"

• Description: Records changes from the staging area into the repository’s history as a new commit object.
• Usage: It captures a snapshot of staged changes, creates a commit object with metadata (author, date, message, parent commit), advances the current branch pointer (HEAD) to the new commit, forms the backbone of Git’s version history.
• Think Tank: -an automatically stages tracked files. Commits should have meaningful messages.

• Best Practices:
  • Always write clear, descriptive commit messages
  • Stage only relevant changes to keep commits focused
  • Use --amend for quick fixes before pushing, but avoid rewriting public history
  • Sign commits for security in collaborative projects
  • Follow team conventions (e.g., Conventional Commits, semantic messages)

Git - git-commit Documentation

git-commit Documentation

git reset

git reset [options] [<commit>]
git reset [<commit>] -- <pathspec>...

# Unstage files (keep changes):
git reset         # default --mixed
git reset <file>  # unstage a specific file

# Unstages changes while preserving modifications in your working directory.
Rewrite the last commit (keep staged):
git reset --soft HEAD~1
# Moves HEAD back one commit; your changes remain staged to recommit differently.

# Discard local changes:
git reset --hard
git reset --hard <commit>
# Resets index and working directory to match the target; all local changes are lost.

# Reset specific paths to HEAD:
git reset -- path/to/file
#Restores the index entry for that path to the last commit’s version (HEAD) without moving HEAD

• Description: Moves the current branch (HEAD) to a specified commit and optionally updates the staging area (index) and working directory.
• Usage: It move HEAD backward to an earlier commit, reset files from the staging area back to the working directory, reset both index and working directory to match a commit.
• Think Tank: Reset options to work with:

How it works: HEAD, index, and working directory:

• Three areas: Git tracks state in the commit tree (HEAD), the staging index, and the working directory. git resetmanipulates one or more of these depending on the mode you choose.
• Core idea: Choose a target commit, then decide whether to update only HEAD, HEAD+index, or HEAD+index+working directory.
• Best Practices:
  • Always write clear, descriptive commit messages
  • Stage only relevant changes to keep commits focused
  • Use --amend for quick fixes before pushing, but avoid rewriting public history
  • Sign commits for security in collaborative projects
  • Follow team conventions (e.g., Conventional Commits, semantic messages)

Git - git-reset Documentation

git-reset Documentation