Jagroop Singh

Posted on Oct 18

20 Git Command-Line Tricks Every Developer Should Know

#webdev #git #github #learning

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 (65)

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!

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!

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!

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.

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!

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!