Essential Everyday Git Commands and Workflows¶

Your guide to the fundamental Git operations you'll use in daily development work.

The Basic Git Workflow¶

Git operations follow a three-step workflow that moves changes through different areas:

graph LR
    A[Working Directory] -->|git add| B[Staging Area]
    B -->|git commit| C[Repository]
    C -->|git checkout| A

1. Working Directory: Where you modify files
2. Staging Area (Index): Where you prepare changes for commit
3. Repository (.git): Where Git permanently stores changes as commits

This workflow allows you to:

• Work on multiple changes simultaneously
• Craft fine-grained commits that group related changes
• Review and refine changes before committing them

Working with Files¶

Checking Status¶

Check the status of your working directory:

See status with detailed information¶

git status

See a compact status display¶

git status -s

Or:

git status --short

Status codes in short format:

• ?? = Untracked files
• A = Files added to stage
• M = Modified files
• D = Deleted files
• Left column = staging area, Right column = working directory

Adding Files¶

Stage files for the next commit:

Add a specific file¶

git add filename.txt

Add multiple files¶

git add file1.txt file2.txt

Add all files in the current directory¶

git add .

Add all files in the entire repository¶

git add -A

Or:

git add --all

Add files interactively¶

Review each change:

git add -p

Or:

git add --patch

Add all tracked files with modifications¶

git add -u

Or:

git add --update

Ignoring Files¶

Use a .gitignore file to exclude files from being tracked:

Create a .gitignore file¶

touch .gitignore

Common patterns for .gitignore:

# Ignore specific file
specific-file.txt

# Ignore file type
*.log
*.tmp

# Ignore entire directory
logs/
temp/
node_modules/

# Ignore all except specific files
*.json
!package.json
!package-lock.json

# Ignore files with tilde at the end (backup files)
*~

💡 Tip: Find pre-configured .gitignore templates for various project types at github.com/github/gitignore

Moving and Renaming Files¶

Git treats renaming as a delete and add operation, but provides a shortcut:

Rename a file and update the index¶

git mv old-name.txt new-name.txt

Move a file to a different directory¶

git mv file.txt path/to/new/location/

Deleting Files¶

Remove files from both the working directory and the index:

Remove a file¶

git rm filename.txt

Remove a file that has already been deleted from the filesystem¶

git rm --cached filename.txt

Remove a directory recursively¶

git rm -r directory/

Making Commits¶

Creating Commits¶

Record staged changes as a commit:

Create a commit with a message¶

git commit -m "Add feature X"

Create a commit with a multiline message¶

Opens editor:

git commit

Add and commit tracked files in one command¶

git commit -am "Fix bug in feature Y"

Add all changes and commit with a message¶

git add -A && git commit -m "Implement feature Z"

Add only specified files and commit in one step¶

git commit file1.txt file2.txt -m "Update specific files"

Writing Good Commit Messages¶

Structure your commit messages for better readability and history:

Short summary (50 chars or less)

More detailed explanatory text, if necessary. Wrap it to about 72
characters. The blank line separating the summary from the body is
critical (unless you omit the body entirely).

- Bullet points are okay
- Typically a hyphen or asterisk is used, preceded by a space

Relates to: #123

💡 Tip: Follow the "50/72" rule: Keep the first line under 50 characters and other lines under 72 characters.

Amending Commits¶

Update the most recent commit:

Change the commit message of the latest commit¶

git commit --amend -m "New commit message"

Add missed changes to the latest commit without changing the message¶

git add forgotten-file.txt
git commit --amend --no-edit

Amend author information for the latest commit¶

git commit --amend --author="New Name <[email protected]>"

⚠️ Warning: Never amend commits that have been pushed to a shared repository unless you're absolutely certain no one else has based their work on them.

Commit Best Practices¶

1. Commit Atomic Changes: Each commit should represent a single logical change
2. Commit Frequently: Smaller, more focused commits are easier to understand and review
3. Write Meaningful Messages: Explain what changed and why (not how)
4. Use Present Tense: "Add feature" instead of "Added feature"
5. Reference Issues: Include issue/ticket numbers in commit messages when applicable

Viewing Changes¶

Viewing Uncommitted Changes¶

Compare your working directory or staging area with the repository:

Show unstaged changes¶

git diff

Show staged changes¶

git diff --staged

Or:

git diff --cached

Show all changes (staged and unstaged)¶

git diff HEAD

Show changes for a specific file¶

git diff -- filename.txt

Viewing Commit History¶

View the commit history of your repository:

Show commit history¶

git log

Show commit history with a graph¶

git log --graph

Show compact commit history (one line per commit)¶

git log --oneline

Show commits with patches (diffs)¶

git log -p

Show statistics for each commit¶

git log --stat

Show commit history for a specific file¶

git log -- filename.txt

Show commit history with date ranges¶

git log --since="2 weeks ago"

git log --until="yesterday"

Examining Specific Commits¶

Inspect specific commits in detail:

Show details of a specific commit¶

git show commit_hash

Show changes in a specific file from a commit¶

git show commit_hash:filename.txt

Show the content of a file at a specific commit¶

git show commit_hash:filename.txt

Undoing Changes¶

Discarding Working Directory Changes¶

Discard uncommitted changes:

Discard changes to a specific file in working directory¶

git restore filename.txt

Or (older syntax):

git checkout -- filename.txt

Discard all changes in working directory¶

git restore .

Or (older syntax):

git checkout -- .

Unstaging Changes¶

Remove changes from the staging area:

Unstage a specific file¶

git restore --staged filename.txt

Or (older syntax):

git reset HEAD filename.txt

Unstage all files¶

git restore --staged .

Or (older syntax):

git reset HEAD

Reverting Commits¶

Create new commits that undo previous commits:

Revert the most recent commit¶

git revert HEAD

Revert a specific commit¶

git revert commit_hash

Revert multiple commits¶

git revert older_commit_hash..newer_commit_hash

Revert a merge commit¶

git revert -m 1 merge_commit_hash

💡 Tip: Revert is the safest way to undo changes that have been shared with others since it doesn't alter history.

Resetting¶

Move branch pointer to a different commit (use with caution):

Reset staging area to match most recent commit¶

Leaves working directory unchanged:

git reset

Reset staging area and working directory to match most recent commit¶

git reset --hard

Move current branch to a specific commit, keeping changes in working directory¶

git reset commit_hash

Move current branch to a specific commit, discarding all changes¶

git reset --hard commit_hash

Move current branch to a specific commit, keeping changes as unstaged¶

git reset --mixed commit_hash

⚠️ Warning: git reset --hard permanently discards changes. Be absolutely certain before using it.

Working with References¶

HEAD and Other References¶

Git has several ways to refer to commits:

• HEAD: Points to the latest commit in the current branch
• HEAD^: Parent of HEAD (previous commit)
• HEAD~2: Grandparent of HEAD (2 commits back)
• main: Points to the latest commit in the main branch
• tag_name: Points to the commit associated with a specific tag

Show where HEAD points¶

git rev-parse HEAD

Show the parent of HEAD¶

git show HEAD^

Show a commit 3 commits before HEAD¶

git show HEAD~3

Using Commit Hashes¶

Every commit in Git has a unique hash identifier:

Show the full hash of a commit¶

git rev-parse HEAD

Use the short form of a commit hash¶

git show a1b2c3d

💡 Tip: You only need the first few characters of a commit hash (usually 7+) to uniquely identify it.

Command Summary¶

Related Topics¶

• Setting up Git and initializing repositories
• Creating, managing, and navigating branches
• Temporarily storing changes and cleaning working directory
• Viewing project history and comparing changes