Git Commands That I Love
Git commands that I use often at work. Helpful for people who are working in teams and want to avoid merge conflict.
Disclaimer: This guide is targeted to new engineers who don’t have much experience working in teams. In the meantime, I’d like to welcome experienced engineers to chime in this conversation, as I continue to accumulate more experience through my journey.
Intro
Do you learn better with hands-on experience? Or do you learn better by reading? Or are you both? Let me be honest with you all, I learn better with hands-on experience. I have read dozens and dozens of Git-related articles, but I couldn’t grasp the concept well until I actually had to use these commands MYSELF. So I suggest you to open up your terminal or your VS code and get ready to these commands TO WORK! I would also attach a small guide on how to use these commands, so it’s easier for you to grasp the concept after reading each section. Alright, let’s cut to the chase!
Git Commands I Love
git commit -am "message here"
Are you familiar with git add . and git commit -m "message here" these two separate commands? I am here to tell you there is a shortcut to do this, which is git commit -am "message here" . This is only applicable to existing files. But before doing that, a good rule of thumb is to run git status first, which we will be discussing in the next point.
How you can practice NOW:
Make changes in one of your existing files and type the command in your terminal. Don’t forget to push the file so you can see the changes on whichever Git-based source code repo hosting service you are using (ex: GitHub, GitLab, CodeCommit).
2. git status (before git add )
git status is very useful before you decide to commit anything, since there are a few scenarios you may encounter:
- You simply want to know which files you have made changes on.
- You don’t want to commit all the changes you’ve made, especially working in teams. You may want to save some for only local use, and/or to avoid merge conflict later in projects, or;
- There are newly created files that requires tracking remotely you might not be aware of.
Also, it’s very useful to use this command to copy and paste the file name when you are using git add in the next step.
How you can practice NOW:
- Create a new file and try the command and see what it displays.
- Make some changes in one of your existing files and compare the difference.
3. Follow these steps: git status 👉 git add 👉 git commit 👉 git pull 👉 git push
I understand each engineer has their own way of working things around, but I personally use these steps before pushing anything to a team repo. Let me explain why real quick.
I start with git status with the reasons I have mentioned above. Then I either do git add + git commit or git commit -am , depends on the situation (and sometimes mood — when I am feeling a bit ✨extra✨). And the reason I git pull first is because in the past for multiple times, I have gotten errors that someone in the team have made changes in the repo. Now I remember I need to git pull . Last but not least, git push the changes to the repo.
A little bit cliché to say so, but following these steps will help you avoid merge conflicts.
How you can practice NOW:
This might be more effective if you are working on a repo that has more than 2 people working on. But if you are on a 1-person project, try to make some changes (say the README.md) online, then push the changes. Then go back to your text editor, follow the steps and you should be able to see the changes when you do git pull .
4. git log (and git reset)
This command is very useful when you want to check all the recent commits (safe to say at least 10?) and/or if you want to rest the HEAD to one of the recent commits by using git reset --soft [<commit>] , which you can copy the commit reference number from git log .
Disclaimer: git reset --soft is only one of the git reset flags. There are a lot of combination for git reset , so it depends on your circumstances which flags will be more suitable.
I found git log useful especially when I am curious what changes have been made in the past and by whom.
How you can practice NOW:
This is quite straight forward that you can try it on the terminal to see all the commits you (and your teammates) have made in the past.
5. git commit --amend
git commit --amend is quite straight forward. It will display the most recent commit messages. (And to exit, type :qa if you’re using Vim in the terminal.)
This is one of my favorite Git commands. A lot of engineers I have met have great sense of humor with the most hilarious commit messages (One of the examples I found on Reddit). However, in professional settings, a commit message implies what changes have been made so that other engineers can quickly pick up and work on the projects. Or even for your own references too. Your future you will thank your present you. Therefore, you may need to change some commit messages you’ve written in the past, and that’s how git commit --amend is so handy.
How you can practice NOW:
Type this command in your terminal. Change the commit messages. Then check your repo online to see if you can see the changes.
.
.
.
Super cool, right? 😃
6. git stash
This is my personal favorite, because this reminds me of array (and there are a lot of reasons I love array). git stash stashes the changes you’ve made locally before you commit anything. A good rule of thumb when working in a project, especially if it’s big and have multiple people working on, is to do a git pull before you do any development. Sometimes you have made some changes locally, for instance, there are some configuration you’ve added that works on your machine, but it may break other people’s code, in this case, you’d git stash so you can git pull your teammates’ code to avoid any conflict. After you get the most updated version, you can pop the local changes back to your code (i.e. git stash pop).
Long story short, Git is usually presented in tree form. I am not the best person to explain how tree/tries works in data structure. pop and push exists in tries, so it might be easier to understand if you understand this type of data structure. But I always imagine that there’s an imaginary array, or stack, somewhere in the cloud and by doing git stash , I am stashing the local changes on top temporarily and I’ll pop the local changes back when I command it. I don’t know if this makes sense (it may if you are a visualizer).
How you can practice NOW:
If you are in a 1-person project, make changes in your repo online (not your text editor) and push the changes. Now go back to your text editor then try git stash , then do git pull which you’ll see the changes you’ve made online. Last but not least git stash pop to see changes you made both locally and online should show up simultaneously with no conflict.
If you are in project with teammate(s), ask them to make and push the changes. Then try on your local machine with the steps above.
Special Mentions
I originally posted the shorter version of this on my LinkedIn.
Got feedbacks from various experienced professionals to try out these commands that I didn’t mention above:
git rebasevsgit pull --rebasegit add -pbrew install tiggit ignoregit diffgit rebase — ontogit gui
Once I am more familiar with the commands above, I will write a Part 2 of this article (…maybe)😃
Most Recommended Resource by my LinkedIn fam
Epilogue
Hope you enjoy this article! A few Git commands might be already a lot to take in, but practice whenever you remember or when you have a chance. I have hit the wall multiple times and had a lot of errors yelling at me until I remembered. Git can be annoying to some people, but honestly, please have some patience with it and read the errors. You will get a hang of it eventually!
Happy coding!
