DEV Community

20 Git Command-Line Tricks Every Developer Should Know

Jagroop Singh on October 18, 2024

20 Git Command-Line Tricks Every Developer Should Know Git is an essential version control tool for developers. Although GUI tools can simplify som...

Read full post

Qian Li • Oct 18 • 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.

Dan Jones • Oct 19

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).

Jagroop Singh • Oct 20

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

Qian Li • Oct 20

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.

Jagroop Singh • Oct 19

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

Samuel Rouse • Oct 18

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.

Jagroop Singh • Oct 19

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!

Mangabo Kolawole • Oct 22

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.

Jagroop Singh • Oct 22

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

Christopher Eberle • Oct 18 • 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"

Jagroop Singh • Oct 19 • 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!

Dhaval Gojiya • Oct 19

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

Jagroop Singh • Oct 19

Yes correct @dhavalgojiya !!

pihentagy • Oct 24

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!

Jagroop Singh • Oct 24

@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.

pihentagy • Oct 24

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

Yonatan Galili • Oct 23 • Edited

git reflog

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.

Evan Roth • Oct 24

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

Jagroop Singh • Oct 24

@eroth , what does it mean ?

Jagroop Singh • Oct 23

@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.

Handsome Lancer • Oct 26

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.

Jagroop Singh • Oct 26

Thanks @handsome_lancer for sharing these.

Rohit TIwari • Oct 22

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 ?

Jagroop Singh • Oct 22

@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.

Rohit TIwari • Oct 23

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.

Jagroop Singh • Oct 23

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.

Jacob John • Oct 24

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!

Jagroop Singh • Oct 24

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

Jacob John • Oct 24

Thanks. I'll be waiting

Martin Häusler • Oct 23

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.

Jagroop Singh • Oct 24

@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!

Yashraj • Oct 23

Hi Great Post! 👍

Also check this out ✅️

Essential git command that I use every day as a Software developer.

Jagroop Singh • Oct 24

Thanks @yashrajxdev , that's great article too.

George Johnson • Oct 20

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.

Jagroop Singh • Oct 21

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

Monroe Mann • Oct 27

Great stuff. Thanks for sharing.

If anyone wants to volunteer with our not for profit, come to breakdiving.io
Web backend: Ruby on Rails
Web frontend: Bootstrap, jQuery, Hotwire, Stimulus, HTML/CSS
Android Mobile App: Flutter
iPhone Mobile App: Flutter

Vanshaj Sharma • Nov 12

Sure for Web Front end

Bilal Mughal • Oct 21

Thanks for the great list! One suggestion:
you could add a message for stashing with git stash -m 'library updates'. It's not always needed if you're coming back quickly, but useful for lingering partial work. For more details, click more.

the hengker • Oct 18

must-save thread. bookmark added. thank you

Jagroop Singh • Oct 18

You're Welcome @uciharis !
I saved these commands in my documents for both personal and official use. Then, I got the idea to share them as a blog.

Corki • Oct 25

Damn thanks this is pretty useful!

Jagroop Singh • Oct 25

Your welcome @cactus77

Syed Muhammad Ali Raza • Oct 23

thanks for sharing

Jagroop Singh • Oct 23

Your welcome @syedmuhammadaliraza !!

FxFeed • Oct 23

Helpful

Jagroop Singh • Oct 23

Thanks @fxfeedio

I am Programmer • Oct 23

Helpful

Jagroop Singh • Oct 23

Thanks @iamprogrammerlk

David Miller • Oct 23

Thanks for the wealth of knowledge to improve our work flow

Jagroop Singh • Oct 23

Thanks @dmiller72 !!

Teerapat Wassavanich • Oct 21

Great! It's very helpful. Thank you.

Jagroop Singh • Oct 21

Thanks @bearydev

Abdulrahman Othman • Oct 20

Thanks , this is pure gold!

Jagroop Singh • Oct 20

Thanks @ab_oo_cd363909a7e04a830b3 !!

Diana • Oct 20

Thanks for sharing that!

Jagroop Singh • Oct 20

You're welcome @dianalanciano

David James Saldua • Oct 19

Thank you for sharing this!

One question regarding the bisect command, could you explain it more because this command seems interesting and very helpful.

Keep inspiring others! Good work

Jagroop Singh • Oct 20

@davidsaldua ,
Thank you! The git bisect command is indeed powerful.
It helps me to find the commit that introduced a bug by performing a binary search between a known good and bad commit.
You mark a commit as "good" and another as "bad," then Git bisects the history to pinpoint the exact commit where the issue was introduced. It's a huge time-saver for debugging!

Keep up the great work, and glad you found it interesting!