Introduction
Git is an essential tool for software engineers, enabling efficient version control, collaboration, and project management. Whether you're working on a solo project or part of a large team, mastering Git commands is crucial for streamlining your development workflow. This guide covers the most common Git commands you'll need, providing a solid foundation for managing your codebase, tracking changes, and coordinating with other developers. By familiarizing yourself with these commands, you can enhance your productivity and ensure smooth project progress. Let's dive into the key Git commands every software engineer should know.
Configuration
1. git config
Purpose: Configure Git settings, such as user name and email.
Example: git config --global user.name "Your Name"
2. git init
Purpose: Initialize a new Git repository.
Example: git init
3. git clone
Purpose: Clone an existing repository.
Example: git clone https://github.com/user/repo.git
4. git status
Purpose: Show the working directory and staging area status.
Example: git status
5. git add
Purpose: Add file contents to the index (staging area).
Example: git add . (add all files)
6. git commit
Purpose: Record changes to the repository.
Example: git commit -m "Commit message"
7. git push
Purpose: Update remote refs along with associated objects.
Example: git push origin main
8. git pull
Purpose: Fetch from and integrate with another repository or local branch.
Example: git pull origin main
9. git branch
Purpose: List, create, or delete branches.
Example: git branch new-branch (create new branch)
10. git checkout
Purpose: Switch branches or restore working tree files.
Example: git checkout new-branch (switch to branch)
11. git switch
Purpose: Switch branches.
Example: git switch new-branch
12. git merge
Purpose: Join two or more development histories together.
Example: git merge new-branch (merge new-branch into current branch)
13. git rebase
Purpose: Reapply commits on top of another base tip.
Example: git rebase main
14. git log
Purpose: Show commit logs.
Example: git log --oneline
15. git diff
Purpose: Show changes between commits, commit and working tree, etc.
Example: git diff (show unstaged changes)
16. git show
Purpose: Show various types of objects.
Example: git show HEAD (show changes in the last commit)
17. git stash
Purpose: Stash the changes in a dirty working directory away.
Example: git stash
18. git stash pop
Purpose: Apply the changes recorded in the stash to the working directory.
Example: git stash pop
19. git clean
Purpose: Remove untracked files from the working directory.
Example: git clean -fd
20. git remote
Purpose: Manage set of tracked repositories.
Example: git remote add origin https://github.com/user/repo.git
21. git fetch
Purpose: Download objects and refs from another repository.
Example: git fetch origin
22. git remote -v
Purpose: Show the URLs that a remote name corresponds to.
Example: git remote -v
23. git tag
Purpose: Create, list, delete, or verify a tag object.
Example: git tag -a v1.0 -m "Version 1.0"
24. git push origin --tags
Purpose: Push all tags to the remote repository.
Example: git push origin --tags
25. git reset
Purpose: Reset current HEAD to the specified state.
Example: git reset --hard HEAD~1 (reset to previous commit)
26. git revert
Purpose: Create a new commit that undoes the changes from a previous commit.
Example: git revert HEAD
27. git checkout --
Purpose: Discard changes in the working directory.
Example: git checkout -- file.txt (discard changes in file.txt)
28. git cherry-pick
Purpose: Apply the changes introduced by some existing commits.
Example: git cherry-pick <commit-hash>
29. git branch -d
Purpose: Delete a branch.
Example: git branch -d branch-name
30. git branch -D
Purpose: Force delete a branch.
Example: git branch -D branch-name
31. git merge --no-ff
Purpose: Create a merge commit even when the merge resolves as a fast-forward.
Example: git merge --no-ff new-branch
32. git rebase -i
Purpose: Start an interactive rebase.
Example: git rebase -i HEAD~3
33. git diff --staged
Purpose: Show changes between the index and the last commit.
Example: git diff --staged
34. git blame
Purpose: Show what revision and author last modified each line of a file.
Example: git blame file.txt
35. git log --graph
Purpose: Show a graph of the commit history.
Example: git log --graph --oneline
36. git reflog
Purpose: Show a log of all references.
Example: git reflog
37. git stash list
Purpose: List all stashes.
Example: git stash list
38. git stash apply
Purpose: Apply a stash to the working directory.
Example: git stash apply stash@{1}
39. git stash drop
Purpose: Remove a single stash entry from the list of stashes.
Example: git stash drop stash@{1}
40. git remote show
Purpose: Show information about the remote repository.
Example: git remote show origin
41. git remote rm
Purpose: Remove a remote.
Example: git remote rm origin
42. git pull --rebase
Purpose: Fetch and rebase the current branch on top of the upstream branch.
Example: git pull --rebase origin main
43. git fetch --all
Purpose: Fetch all remotes.
Example: git fetch --all
44. git bisect
Purpose: Use binary search to find the commit that introduced a bug.
Example: git bisect start
45. git submodule
Purpose: Initialize, update, or inspect submodules.
Example: git submodule update --init
46. git archive
Purpose: Create an archive of files from a named tree.
Example: git archive --format=tar HEAD > archive.tar
47. git shortlog
Purpose: Summarize git log output.
Example: git shortlog -s -n
48. git describe
Purpose: Give an object a human-readable name based on an available ref.
Example: git describe --tags
49. git rev-parse
Purpose: Parse revision (or other objects) and retrieve its hash.
Example: git rev-parse HEAD
50. git tag -d
Purpose: Delete a tag from the local repository.
Example: git tag -d v1.0
51. git checkout -b
Purpose: Create and switch to a new branch.
Example: git checkout -b new-branch
52. git push origin --delete
Purpose: Delete a remote branch.
Example: git push origin --delete branch-name
53. git cherry
Purpose: Find commits not merged upstream.
Example: git cherry -v
54. git rm
Purpose: Remove files from the working tree and from the index.
Example: git rm file.txt
55. git mv
Purpose: Move or rename a file, directory, or symlink.
Example: git mv oldname.txt newname.txt
.56 git reset HEAD
Purpose: Unstage changes.
Example: git reset HEAD file.txt
57. git log -p
Purpose: Show changes over time for a specific file.
Example: git log -p file.txt
58. git diff --cached
Purpose: Show changes between the index and the last commit (same as --staged).
Example: git diff --cached
59. git apply
Purpose: Apply a patch to files and/or to the index.
Example: git apply patch.diff
60. git format-patch
Purpose: Prepare patches for e-mail submission.
Example: git format-patch -1 HEAD
61. git am
Purpose: Apply a series of patches from a mailbox.
Example: git am < patch.mbox
62. git cherry-pick --continue
Purpose: Resume cherry-picking after resolving conflicts.
Example: git cherry-pick --continue
63. git fsck
Purpose: Verify the connectivity and validity of objects in the database.
Example: git fsck
64. git gc
Purpose: Cleanup unnecessary files and optimize the local repository.
Example: git gc
65. git prune
Purpose: Remove unreachable objects from the object database.
Example: git prune
66. git notes
Purpose: Add or inspect object notes.
Example: git notes add -m "Note message"
67. git whatchanged
Purpose: Show what changed, similar to git log.
Example: git whatchanged
*68. git show-branch *
Purpose: Show branches and their commits.
Example: git show-branch
69. git verify-tag
Purpose: Check the GPG signature of tags.
Example: git verify-tag v1.0
70. git show-ref
Purpose: List references in a local repository.
Example: git show-ref
LinkedIn Account
: LinkedIn
Twitter Account
: Twitter
Credit: Graphics sourced from LinkedIn
Top comments (51)
I've been a developer for 2 decades. Why people learn git commands is just beyond me, when there are amazing things like Git Graph in VS Code that does it all graphically. Just me?
Haha, I hear you! Git Graph in VS Code is indeed a lifesaver for visual folks. But hey, some of us still enjoy the thrill of typing mysterious commands into a terminal. Keeps us feeling like coding wizards! 😉✨
I second you Odumosu!
I'm glad I'm not alone! Thanks for the backup😂
Right? It elevated my programming skills and also pleased the code gods?
Definitely! Mastering these tools can really take your programming skills to the next level. It's like earning the favor of the code gods and becoming a true maestro of development. Keep up the great work!
I can't tell if you're serious or sarcastic. I hope the latter because knowing these serves no such purpose. For this to be true, programming would have to be about who knows the most command lines.
Haha, fair point! It's definitely more about how effectively you use the tools you have rather than knowing the most command lines. But hey, a little command line knowledge never hurts—just adds a bit of flair to your toolkit!
I Am Supporting this guy
Btw, can Git Graph handle interactive rebase?
Disclaimer: I use GUI regularly, but knowing CLI is a nice addition to that.
You know the difference between
rebase
andrebase --interactive
, don't you? As I see, Git Graph can't do the latter. This is the issue 5 years from now and it is still open github.com/mhutchie/vscode-git-gra...Yes, you learn it and then enjoy the speed. Nobody rejects driving because of they would have to spend some time on obtaining a license.
I want GUI to help me in complex cases, not for
git commit
orgit merge
.So you're saying that because a particular rebase variant is not available, one must ditch the entire GUI tool? I guess No, right?
I'm sorry, but if chauffeurs were free, I bet a LOT more people would forget about getting a driver's license. The same here: Why undergo this effort if
<insert-GUI-tool-here>
does it for me for free?GUI's help you in complex cases. Find the right GUI. There is none? Consider creating one and sharing with the world.
I believe nobody in this thread is talking about ditching anything.
You literally asked
And you got the answers. Nobody said you must do anything, really. However, I see no problem in learning something new to become more productive.
Fair enough. I'll ammend: "Why people learn the entirety of git commands...". I'm not against learning a particular something that you need when your need isn't cover elsewhere. I just see learning all of them for the sake of learning them as a crazy thing to do, simply put.
Congratulations on having 20 years experience and bragging about your clear laziness.
People like you are awful to work with. The amount of "developers" who "know version control and git" and are just glorified button pressers is staggering. I've had countless developers in my jobs that ask me to hold their hand through every merge. Its tiring. Just learn how to pull, push, merge, branch, and you're golden? Its like 10 commands.
Or you can continue to use a GUI and cry when errors occur because you have no idea what's going on underneath the hood.
LOL! Someone's got some anger issues. Bro, everything all right at home? Need me to call someone?
Do not confuse my passion with anger.
There are many new developers who use this forum and are impressionable. Your comment could deter them from learning a very simple and incredibly valuable skill.
Skills that are transferrable. Skills that could lead to a higher salary and better life. But sure call someone if you like. I'm always happy to meet new people and experience new things.
I have never, not ONCE, been asked in a job interview: "Do you know GIT command lines? No, sorry, I can't hire you!" LOL
You are delusional if you think knowing GIT commands matter one bit when it comes to salary or better life.
Get some help because passion does not require INSULTING other people. Or maybe a dictionary?? Either is good for you.
Hey you've insulted me just as much as I have you. If it's too much perhaps don't share your opinion on developer forums?
I never said Git commands = more money. I said its easy to learn, and as its a CLI, the exposure to the command line will help when using other CLIs.
You know how as a developer we have to use CLIs quite frequently? You even have posts about Vite in your profile.
These things are easier to learn when you have previous experience. And as you learn these things you become a better developer and earn more money. Its not that difficult to understand. But sure keep changing the goal posts of the discussion to fit your narrative.
Don't confuse MY passion, bro! :-)
Now because my opinion hurts you I must refrain from posting? How about you, perhaps, not reading my posts?
You don't need to learn GIT commands to "practice" for other command lines. This is just a memory exercise, and you've been doing them since you were in school.
What's my narrative here, exactly?
Sorry I'm not going to continue this discussion when you clearly don't understand what a transferrable skill is. And I also think there is a slight language barrier which I can only respect you for, I couldn't discuss this in your language.
To any new developers reading this I implore you to learn the basics of git commands. Even if you then go onto use a GUI, that's fine. But getting to grips with what is going on behind the scenes is invaluable.
No problem. You clearly don't understand the lack of importance learning GIT commands has, so we're at an impasse anyway.
Tip for future instances: Keep your "passion" in check. :-)
Honestly ?
Also, it's usually good to know what a GUI does under the hood and yes - you don't need to use the cli - but it cannot hurt to do so :)
Nobody has come up with a solid reason so far. Come on, guys!
Because when you interact with git through the GUI, if for some reason an error message is returned, you are not sure which git command you are executing is faulty, which leads to wrong judgment. Moreover, if you use the git command, you can have complete control over the source code, and can execute advanced git commands that the GUI does not support.
Excellent theoretical reply. In practice, I have never once lost any amount of "control" over the source code by using a GUI, and the GUI has never precluded my ability to run a GIT command in the very, extremely rare case that I have ever needed something that the GUI doesn't provide.
So yes, your answer is very solid, but doesn't describe the reality of things. Reality is that 99.9% (or more), GUI tools work perfectly and have every feature that you need. I won't go through the painful exercise of learning all of these commands to cover the 0.1% of the cases. Practicality, my friend. 😄
For some reason, Rense Bakker is afraid of my responses and have blocked me. Anyway:
Rense, learning GIT !== learning GIT CLI. I know enough of GIT not to make fatal errors like rewriting histories, so I disagree with your comment: One can destroy a repository with the CLI just as easily by reading quick descriptions of the commands and then hastily deciding on one that you think solves your problem and boom!
One can learn GIT and that doesn't imply learning the CLI as well.
Because CLI is better always!
Explain how it is better in every instance.
one word... neovim.
Searched for it. Sounds like another instance of learning dozens of things. This time, keyboard shortcuts. Yes, that's not as bad, so cool. That's, however, one instance, not every instance.
Yeah you may have to learn keyboard shortcuts, if and only if you don't know how to configure something, all you need to do is read some docs and create your own custom keyboard shortcuts, and now rather then following the standard shortcuts, you can just type what ever shortcut you created and voila! Neovim can be configured all around, now I know VSCode can also be, but tell me, from what angle can you configure it to be fast? Try loading a monorepo in VSCode, that uses TS, Docker, terraform, AWS Lambda, and a whole lot of stuff, adding up, VSCode takes like literally 1 - 2 min to load, plus if you use something like a laptop then it's even more hectic, now with neovim, you can configure it to a huge extend, I tried and I can guarantee you that it took a crazy 1 sec to open a file.
This is because of neovim's nature, it can be configured like VSCode I agree, but because it's directly compiled to machine code it executes faster, VSCode is written in TS, so first it has to compile to JS and then to machine, neovim has minimalistic packages, which are written in lua and not TS or JS, which makes it even more faster, due to the fact that all VSCode extensions are written in TS(majority of them) and thus take more time to load.
Now of course you will need to learn some basic shortcuts, but does are usually easy and you can configure them to be something else, you don't really have to worry much about the learning curve, if you really don't want much, you can just ask GPT, which is the worst option to pick, to give you a neovim configure for what all shortcuts you may want.
I see. Thanks for the rundown. Sounds like a good experience, if you can get past the learning of the shortcuts. Maybe I'll check it out later. Cheers.
Yeah you should, not only will you get blazingly fast, you will soon realize that "An idiot admires complexity and a genius admires simplicity" Of course I did not say that. Terry Davis did.
I've seen a lot of fuckups with git GUIs because people don't realize the commands it's doing in the background...
As a neovim lover... VSCODE IS SLOW AND USES 50% OF YOUR CPU!
No offense it's just for the memes.
Some people are simply faster using the cli, and/or don't like VSC.
Fair point, but they are only faster because they decided to learn the commands in the first place. Furthermore, what job role do they have to have the need for speed up to the point of going through the pain of learning dozens of commands? I can only see this making sense for a dev ops.
At some point I realized I can do almost everything faster if I don't have to touch the mouse anymore. So, learning those things took me maybe a day, but saved me way more across all the years I'm doing that now. Not only 'git' though, but really almost everything I'm working on now... neovim, tmux, i3 and many other tools allow me to work almost at the speed of my thoughts.
That's just me using neovim, so yeah as a pro neovim user, I can assure you that jjjjkkkk is faster then using the mouse.
You mean 4j4k... :-D
yeah sure, that works too, but saying jjjjkkkk is far more beautiful
Agree Jose.. feels like a superfluous flex. Another great tool is GitEXT. It looks like it's straight out of windows 98, but it works a treat. Couple if with KDIFF3 and there's zero guesswork to do.
GitEXT and KDIFF3 are fantastic alternatives for those who prefer a more visual approach. It's all about finding the tools that make your workflow smoother and more efficient. Different strokes for different folks! 👍🛠️
Thanks for sharing !
You're most welcome !
I've been a Windows user and fan for pretty much all my adult life. I hate CLI's for things I do myself. Sure, I do CLI when I do, say, GH actions and of course they are the only way to script things. I just say that, personally, Windows exists so my brain can forego many of these.
thanks pro
You're most welcome !
Thanks
Some comments may only be visible to logged-in visitors. Sign in to view all comments.