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.

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!

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!