Your guide to the fundamental Git operations you'll use in daily development work.
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
- Working Directory: Where you modify files
- Staging Area (Index): Where you prepare changes for commit
- 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
Check the status of your working directory:
git statusgit status -sOr:
git status --shortStatus codes in short format:
??= Untracked filesA= Files added to stageM= Modified filesD= Deleted files- Left column = staging area, Right column = working directory
Stage files for the next commit:
git add filename.txtgit add file1.txt file2.txtgit add .git add -AOr:
git add --allReview each change:
git add -pOr:
git add --patchgit add -uOr:
git add --updateUse a .gitignore file to exclude files from being tracked:
touch .gitignoreCommon 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
.gitignoretemplates for various project types at github.com/github/gitignore
Git treats renaming as a delete and add operation, but provides a shortcut:
git mv old-name.txt new-name.txtgit mv file.txt path/to/new/location/Remove files from both the working directory and the index:
git rm filename.txtgit rm --cached filename.txtgit rm -r directory/Record staged changes as a commit:
git commit -m "Add feature X"Opens editor:
git commitgit commit -am "Fix bug in feature Y"git add -A && git commit -m "Implement feature Z"git commit file1.txt file2.txt -m "Update specific files"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.
Update the most recent commit:
git commit --amend -m "New commit message"git add forgotten-file.txt
git commit --amend --no-editgit commit --amend --author="New Name <new.email@example.com>"
⚠️ 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 Atomic Changes: Each commit should represent a single logical change
- Commit Frequently: Smaller, more focused commits are easier to understand and review
- Write Meaningful Messages: Explain what changed and why (not how)
- Use Present Tense: "Add feature" instead of "Added feature"
- Reference Issues: Include issue/ticket numbers in commit messages when applicable
Compare your working directory or staging area with the repository:
git diffgit diff --stagedOr:
git diff --cachedgit diff HEADgit diff -- filename.txtView the commit history of your repository:
git loggit log --graphgit log --onelinegit log -pgit log --statgit log -- filename.txtgit log --since="2 weeks ago"git log --until="yesterday"Inspect specific commits in detail:
git show commit_hashgit show commit_hash:filename.txtgit show commit_hash:filename.txtDiscard uncommitted changes:
git restore filename.txtOr (older syntax):
git checkout -- filename.txtgit restore .Or (older syntax):
git checkout -- .Remove changes from the staging area:
git restore --staged filename.txtOr (older syntax):
git reset HEAD filename.txtgit restore --staged .Or (older syntax):
git reset HEADCreate new commits that undo previous commits:
git revert HEADgit revert commit_hashgit revert older_commit_hash..newer_commit_hashgit 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.
Move branch pointer to a different commit (use with caution):
Leaves working directory unchanged:
git resetgit reset --hardgit reset commit_hashgit reset --hard commit_hashgit reset --mixed commit_hash
⚠️ Warning:git reset --hardpermanently discards changes. Be absolutely certain before using it.
Git has several ways to refer to commits:
HEAD: Points to the latest commit in the current branchHEAD^: Parent of HEAD (previous commit)HEAD~2: Grandparent of HEAD (2 commits back)main: Points to the latest commit in the main branchtag_name: Points to the commit associated with a specific tag
git rev-parse HEADgit show HEAD^git show HEAD~3Every commit in Git has a unique hash identifier:
git rev-parse HEADgit show a1b2c3d💡 Tip: You only need the first few characters of a commit hash (usually 7+) to uniquely identify it.
| Command | Common Options | Description |
|---|---|---|
git status |
-s, --short |
Check repository status |
git add |
., -p, -A, -u |
Stage changes |
git commit |
-m, -am, --amend |
Record changes |
git diff |
--staged, --name-only |
View changes |
git log |
--oneline, --graph, -p |
View history |
git show |
commit_hash, HEAD |
Inspect specific commit |
git restore |
--staged, --source=HEAD |
Undo changes |
git rm |
--cached, -r |
Remove files |
git mv |
Move/rename files |