DEV Community

Cover image for 20 Git Command-Line Tricks Every Developer Should Know
Jagroop Singh
Jagroop Singh

Posted on

20 Git Command-Line Tricks Every Developer Should Know

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"
Enter fullscreen mode Exit fullscreen mode

💡 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
Enter fullscreen mode Exit fullscreen mode

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"
Enter fullscreen mode Exit fullscreen mode

This updates the previous commit without creating a new one.


4. Stash Uncommitted Changes

Need to quickly switch branches without committing?

git stash
Enter fullscreen mode Exit fullscreen mode

💡 Retrieve the stash later with:

git stash pop
Enter fullscreen mode Exit fullscreen mode

5. View Commit History Graphically

Visualizing the commit history makes it easier to understand the project's state.

git log --graph --oneline --all
Enter fullscreen mode Exit fullscreen mode

6. Change the Commit Author

Change the author of the last commit.

git commit --amend --author="New Author <newauthor@example.com>"
Enter fullscreen mode Exit fullscreen mode

7. Check Differences in Staged Changes

Use git diff to compare files at different stages.

git diff --staged
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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>
Enter fullscreen mode Exit fullscreen mode

11. List All Branches (Local and Remote)

See which branches are available.

git branch -a
Enter fullscreen mode Exit fullscreen mode

12. Clean Untracked Files and Directories

Quickly remove unwanted files that are not tracked by Git.

git clean -fd
Enter fullscreen mode Exit fullscreen mode

💡 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
Enter fullscreen mode Exit fullscreen mode

14. Squash Commits with Interactive Rebase

Combine multiple commits into one.

git rebase -i HEAD~n  # Replace 'n' with the number of commits
Enter fullscreen mode Exit fullscreen mode

15. View the File at a Specific Commit

Check a file's state at a particular commit.

git show <commit-hash>:path/to/file
Enter fullscreen mode Exit fullscreen mode

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"
Enter fullscreen mode Exit fullscreen mode

17. Revert a Pushed Commit

Undo changes from a specific commit without changing history.

git revert <commit-hash>
Enter fullscreen mode Exit fullscreen mode

18. Fetch Only Metadata

Want to avoid fetching the whole repository?

git fetch --dry-run
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

20. Reset a File to the Last Commit

Discard local changes to a specific file.

git checkout -- path/to/file
Enter fullscreen mode Exit fullscreen mode

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

favicon github.com

Top comments (65)

Collapse
 
qianl15 profile image
Qian Li • Edited

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 524288000 is useful if you want to upload larger files. By default the buffer size is 1MB.
Collapse
 
goodevilgenius profile image
Dan Jones

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 a Makefile or something similar).

Collapse
 
jagroop2001 profile image
Jagroop Singh

Wow !! Interesting.Thanks @goodevilgenius for sharing your expereince.

Collapse
 
qianl15 profile image
Qian Li

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.

Collapse
 
jagroop2001 profile image
Jagroop Singh

@qianl15 , You're welcome! Those are great tips too!

Collapse
 
oculus42 profile image
Samuel Rouse

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.

Collapse
 
jagroop2001 profile image
Jagroop Singh

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!

Collapse
 
koladev profile image
Mangabo Kolawole

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_tag is useful for referencing specific points in Git history, often marking releases or important checkpoints in a project.
Collapse
 
jagroop2001 profile image
Jagroop Singh

@koladev , Your addition of git tag <your_tag> is spot on!

Collapse
 
christopher_eberle_691d0e profile image
Christopher Eberle • Edited

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"

Collapse
 
jagroop2001 profile image
Jagroop Singh • Edited

@christopher_eberle_691d0e ,
Thanks for the detailed feedback!

2) You're incorrect, --mixed is the default, so it can definitely be shortened.
3) Good point! git add . is often unnecessary.
5) Adding --decorate is 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~n would 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 by git add *, then git commit --amend, is a more direct and effective solution.

Replacing all ref shortcuts with commit-ish is a great idea as well.

And thanks for sharing your favorite: git commit --fixup <commit-ish> followed by git rebase -i --autosquash <commit-ish>~1. That's definitely a handy one!

Collapse
 
dhavalgojiya profile image
Dhaval Gojiya

2) --soft is not default. The default is "--mixed" when using git reset HEAD

Thread Thread
 
jagroop2001 profile image
Jagroop Singh

Yes correct @dhavalgojiya !!

Collapse
 
pihentagy profile image
pihentagy

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!

Collapse
 
jagroop2001 profile image
Jagroop Singh

@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 like git add <specific-files> and leveraging a .gitignore file to exclude unnecessary files.

Collapse
 
pihentagy profile image
pihentagy

For 6: when you accidentally commited with your wrong email (private addreas for work or the other way around)

Collapse
 
yonatan_galili_391cc0f95a profile image
Yonatan Galili • Edited
git reflog
Enter fullscreen mode Exit fullscreen mode
  • tracks changes to the tip of branches and records every action you perform in Git, even those not in the commit history. It helps recover lost commits or undo changes by showing a log of references.
Collapse
 
eroth profile image
Evan Roth

I'm really surprised this was left out, this is an absolute lifesaver (learned the hard way of course)!

Collapse
 
jagroop2001 profile image
Jagroop Singh

@eroth , what does it mean ?

Collapse
 
jagroop2001 profile image
Jagroop Singh

@yonatan_galili_391cc0f95a ,
Yes, that's correct! git reflog is great for tracking changes and recovering lost commits, even those not in the commit history.

Collapse
 
jacob_john profile image
Jacob John

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!

Collapse
 
jagroop2001 profile image
Jagroop Singh

Thanks, @jacob_john ! I’m also working on creating a list of Git commands with advanced versions. Looking forward to sharing it soon!

Collapse
 
jacob_john profile image
Jacob John

Thanks. I'll be waiting

Collapse
 
ro6it profile image
Rohit TIwari

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 ?

Collapse
 
jagroop2001 profile image
Jagroop Singh

@ro6it ,
Here are two methods that have consistently worked for handling conflicts when pulling changes from the remote:

1. For Small Changes:

  • Stash the changes, pull the latest changes from the branch, and then pop the stashed changes.
  • Finally, resolve any conflicts that arise.

2. For Large Changes:

  • Create a new branch from your current branch with the local changes.
  • Push the changes to the new branch.
  • Afterward, pull the latest changes from the origin branch.

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.

Collapse
 
ro6it profile image
Rohit TIwari

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.

Thread Thread
 
jagroop2001 profile image
Jagroop Singh

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:

  • First, run git fetch to get the latest changes from the remote without applying them.
  • Then run git merge origin/<branch-name>. This will attempt to merge the remote changes with your local commit.
  • If there are conflicts, Git will indicate the files with conflicts. You'll need to manually resolve them by choosing between the local or remote changes (or both).
  • After resolving the conflicts, stage the resolved files (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:

  • First, pull the latest changes using rebase: git pull --rebase origin <branch-name>. This will attempt to reapply your local commits on top of the remote changes.
  • Resolve any conflicts as they arise, then continue the rebase using git rebase --continue.
  • Once done, your local commits will be on top of the remote changes, and your history will look cleaner.
Collapse
 
handsome_lancer profile image
Handsome Lancer

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 them
  • git 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.
Collapse
 
jagroop2001 profile image
Jagroop Singh

Thanks @handsome_lancer for sharing these.

Collapse
 
martinhaeusler profile image
Martin Häusler

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.

Collapse
 
jagroop2001 profile image
Jagroop Singh

@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. And git clean -xdf is 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!

Collapse
 
syxaxis profile image
George Johnson

Lessons I can only assume have been learned the hard way! ha ha!

So my of these quick command lines are almost mandatory to learn, a superb article that's going to be on a lot of people's bookmarks for sure.

Collapse
 
jagroop2001 profile image
Jagroop Singh

@syxaxis ,
Definitely! These essential command lines are game-changers and a must-have for everyone's toolkit!

Some comments may only be visible to logged-in visitors. Sign in to view all comments.