20 Git Command-Line Tricks Every Developer Should Know
Git is an essential version control tool for developers. Although GUI tools can simplify some tasks, mastering the Git command line offers deeper control, flexibility, and speed. Here are 20 Git command-line tricks that every developer should know to streamline their workflow.
1. Set Global Configuration
Ensure your commits are tagged with the correct identity.
git config --global user.name "Your Name"
git config --global user.email "you@example.com"
💡 Tip: Use --local instead of --global to set project-specific configurations.
2. Undo the Last Commit (without losing changes)
If you made a mistake in the last commit, you can undo it.
git reset --soft HEAD~1
This leaves your changes staged, so you can amend the commit or fix the issue.
3. Amend the Last Commit
Forgot to include a change or want to update the commit message?
git add .
git commit --amend -m "Updated commit message"
This updates the previous commit without creating a new one.
4. Stash Uncommitted Changes
Need to quickly switch branches without committing?
git stash
💡 Retrieve the stash later with:
git stash pop
5. View Commit History Graphically
Visualizing the commit history makes it easier to understand the project's state.
git log --graph --oneline --all
6. Change the Commit Author
Change the author of the last commit.
git commit --amend --author="New Author <newauthor@example.com>"
7. Check Differences in Staged Changes
Use git diff to compare files at different stages.
git diff --staged
This shows the changes that are staged but not yet committed.
8. Find a Bug with Bisect
Use git bisect to find the commit that introduced a bug.
git bisect start
git bisect bad # Current commit is bad
git bisect good <commit-hash> # A known good commit
Git will walk through the commit history to identify the problematic commit.
9. Rebase for a Clean Commit History
Rebasing rewrites your commit history for clarity.
git rebase -i HEAD~3
This lets you edit, squash, or reorder your last 3 commits.
10. Cherry-Pick Specific Commits
Want to bring a specific commit from another branch?
git cherry-pick <commit-hash>
11. List All Branches (Local and Remote)
See which branches are available.
git branch -a
12. Clean Untracked Files and Directories
Quickly remove unwanted files that are not tracked by Git.
git clean -fd
💡 Use -n for a dry run to preview what will be removed.
13. Track an Upstream Branch
Keep your local branch in sync with a remote branch.
git branch --set-upstream-to=origin/main
14. Squash Commits with Interactive Rebase
Combine multiple commits into one.
git rebase -i HEAD~n # Replace 'n' with the number of commits
15. View the File at a Specific Commit
Check a file's state at a particular commit.
git show <commit-hash>:path/to/file
16. Edit the .gitignore After Committing
If you forgot to ignore certain files, update .gitignore.
echo "node_modules/" >> .gitignore
git rm -r --cached node_modules/
git commit -m "Update .gitignore"
17. Revert a Pushed Commit
Undo changes from a specific commit without changing history.
git revert <commit-hash>
18. Fetch Only Metadata
Want to avoid fetching the whole repository?
git fetch --dry-run
This lets you see what would be fetched without actually downloading data.
19. Blame a Line of Code
Find out who wrote a specific line in a file.
git blame path/to/file
20. Reset a File to the Last Commit
Discard local changes to a specific file.
git checkout -- path/to/file
These 20 Git command-line tricks can make your development process smoother, whether you are working alone or with a team. While GUI tools offer convenience, mastering the Git command line provides more control over your workflows. Try out these commands and elevate your Git skills!
Happy coding! 🚀
Follow me on github:
Jagroop2001 (Jagroop) · GitHub
👨💻 Full Stack Developer | 🤖 Machine Learning Developer | 🤝 Dev Relations Pro – 💼 Available for Hire - Jagroop2001
github.com
Top comments (66)
Thanks for sharing these useful tips!
Some additional useful ones:
git reset --hard [git hash]is helpful if you want to get rid of unwanted changes.git config http.postBuffer 524288000is useful if you want to upload larger files. By default the buffer size is 1MB.I would suggest that if you're committing files larger than 1MB, you should probably be using git lfs, or not using git at all.
One option, if you've got large files that you need, is to upload these files to something like S3, add the file to
.gitignore, and add a script to download these files when needed (possibly to aMakefileor something similar).Wow !! Interesting.Thanks @goodevilgenius for sharing your expereince.
Yeah great point! In my case, the file was 1.2MB large so it was pretty convenient to just commit that file to the repo. You're right, if the file is much bigger then we should use git lfs or S3.
@qianl15 , You're welcome! Those are great tips too!
Thanks for putting together such a great list!
One thing you could add is a message to stash:
git stash -m 'library updates'. Unnecessary if you are able to quickly return to your stashed work, but useful for lingering partial work.Thanks @oculus42 ,
Using
git stash -m 'library updates'is a great addition, especially when you have partial work that might sit for a while. Adding a message makes it easier to keep track of what's been stashed. Definitely a good practice!Interesting commands. I really love the
git cherry-pick <commit-hash>. I have used it a lot as a lead engineer to ensure that I picked some changes left and right for merging before tagging and deploying.Thus, I would like to add this one too:
git tag your_tagis useful for referencing specific points in Git history, often marking releases or important checkpoints in a project.@koladev , Your addition of
git tag <your_tag>is spot on!A number of these are flawed:
2) Can be shorter: For some time now, --soft is the default
3) Can be shorter: git add . is unnecessary
5) Add --decorate to see branches and tags in the case that log.decorate config is "no".
6) I can't think of a reason you'd reasonably need to change the commit author
9) This should have HEAD~n as in #14
14) This command doesn't do anything except start an interactive rebase. You need to then replace "pick" in the todo with "squash" to actually accomplish a squash. A more direct answer would be to "git reset HEAD~(n-1)" followed by "git add *" followed by "git commit --amend"
You should also just replace all ref shortcuts with "commit-ish" as in #10
Lastly, you missed my personal favorite: "git commit --fixup <commit-ish>" followed by "git rebase -i --autosquash <commit-ish>~1"
@christopher_eberle_691d0e ,
Thanks for the detailed feedback!
2) You're incorrect,
--mixedis the default, so it can definitely be shortened.3) Good point!
git add .is often unnecessary.5) Adding
--decorateis a useful tip for seeing branches and tags when log.decorate isn't enabled.6) I can't agree with this because In some situations, like when I am working for someone else and need to commit under their name (as part of an agreement), changing the commit author can be necessary. It helps present the work as theirs, even though I'm the one doing the actual coding (and I am being paid for it).
Additionally, if I am juggling multiple projects where my own commits are required, having the ability to switch commit authors really comes in handy. So, while it might not be common, it definitely has its use cases!
9) Correct, using
HEAD~nwould be more consistent with #14.14) You’re absolutely right—simply starting an interactive rebase isn’t enough. Your suggestion of
git reset HEAD~(n-1), followed bygit add *, thengit commit --amend, is a more direct and effective solution.Replacing all ref shortcuts with
commit-ishis a great idea as well.And thanks for sharing your favorite:
git commit --fixup <commit-ish>followed bygit rebase -i --autosquash <commit-ish>~1. That's definitely a handy one!2) --soft is not default. The default is "--mixed" when using
git reset HEADYes correct @dhavalgojiya !!
git add .is in most cases harmful, not unnecessary. How many times I saw committed garbage, like OS or IDE specific files in git repos.Be explicit and state what do you add to git!
@pihentagy ,
You're right—using
git add .can lead to committing unwanted files like OS or IDE-specific ones. It's best to be explicit and add only what you need, using commands likegit add <specific-files>and leveraging a.gitignorefile to exclude unnecessary files.For 6: when you accidentally commited with your wrong email (private addreas for work or the other way around)
I'm really surprised this was left out, this is an absolute lifesaver (learned the hard way of course)!
@eroth , what does it mean ?
@yonatan_galili_391cc0f95a ,
Yes, that's correct!
git reflogis great for tracking changes and recovering lost commits, even those not in the commit history.Amazing article. I will add to this
git stash list: This will list all the stash and then it can be popped by the number assigned to themgit pull --ff-only: This is fast-forward mode, when items will be pulled it won't create another pull commit. It works only if there are no local changes.Thanks @handsome_lancer for sharing these.
How you handle the situation, if you are working on a cloned repo and updating the content or files and in between someone commits in the remote repo and while making your local changes you missed pulling the latest changes before making local commits and after making local commits you realize that you should take a pull but that time pull doesn't work. How to resolve that conflict and pull the changes ?
@ro6it ,
Here are two methods that have consistently worked for handling conflicts when pulling changes from the remote:
1. For Small Changes:
2. For Large Changes:
This approach allows for flexibility based on the size of your changes and helps manage conflicts efficiently.
** Note :** It may possible some other shortcuts are available for that but these are my personal preferred methods.
I feel you couldn't understand the issue properly, the changes in local has been committed there are no uncommitted changes that can be stashed and at the same time someone has made a commit on remote repo and now both local and remote branches has a new commit and when we try to pull the remote changes it conflicts with the local commit.
Thank @ro6it for the clarification! Since the changes are already committed both locally and on the remote, stashing isn’t necessary here. In this situation I would use one of below methods :
1. Merge Approach
I can resolve this using a merge:
git fetchto get the latest changes from the remote without applying them.git merge origin/<branch-name>. This will attempt to merge the remote changes with your local commit.git add <file-name>), then finalize the merge with a commit (git commit).2. Rebase Approach (Cleaner history but requires careful conflict resolution)
I found this bit difficult but still sometimes it helps a lot:
git pull --rebase origin <branch-name>. This will attempt to reapply your local commits on top of the remote changes.git rebase --continue.This post on "20 Git Command Line Tricks Every Developer Should Know" provides a solid collection of useful Git commands that can really enhance the workflow of developers. I especially appreciate how each command is clearly explained with examples, which makes it easier to follow even for beginners. One suggestion to add to the list could be exploring advanced branching strategies to help manage larger projects more efficiently. Speaking of great tools, if you're looking to improve your brand identity with a standout logo, you might want to check out professional logo design Dubai services. Investing in a well-designed logo can create a lasting impression and strengthen your brand’s presence in the market!
Thanks, @jacob_john ! I’m also working on creating a list of Git commands with advanced versions. Looking forward to sharing it soon!
Thanks. I'll be waiting
You can use:
git fetch --all && git reset --hard @{u}... to reset your current branch to whatever is on the remote repo without having to re-type the branch name (
@{u}is a shorthand for@{upstream}). Useful if you work on multiple devices, rebase a lot and just don't care about the local state anymore.Another favorite of mine (I like to call it the "nuclear option") is:
git clean -xdf... which deletes all untracked files from the local repository, no questions asked. If you do a hard reset followed by this, your local state will be identical to the remote state. Useful to get rid of weird project build failures sometimes when incremental compilation gets tripped up.
@martinhaeusler ,
That’s a solid approach! Using
git fetch --all && git reset --hard @{u}is great for syncing your branch with the remote, especially when you want a clean slate. Andgit clean -xdfis indeed the "nuclear option" for removing untracked files. Together, they ensure your local repo mirrors the remote state perfectly—ideal for resolving pesky build issues!Hi Great Post! 👍
Also check this out ✅️
Essential git command that I use every day as a Software developer.
Thanks @yashrajxdev , that's great article too.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.