In this article, we are going to learn some life-saving Git commands.
We will not only learn about them, but we will also construct a mental model by understanding how they work behind the scenes.
Some of these you may have used before, while others may be new to you, but they are all lifesavers.
The Real Fault Is to Have Faults And Not to AMEND Them
“You will be remembered in your typos and edit history”
— Anonymous
Typos happen all the time!
Git gives us the option to correct our mistakes.
When committing, sometimes we can hit “Enter” too quickly and have a typo somewhere in the commit message.
Perfect! Now, your co-workers will not see that your “commit” was originally spelled “committ”.
Well Crafted Thing Is a Thing to Behold
You might have used the command git add <file>
or git add .
many times but doing so doesn’t allow us to commit just a section of a file.
git add -p
allows you to stage parts of a changed file, instead of the entire file.
This allows you to make concise, well-crafted commits that make for an easier-to-read history.
Doing so can improve the quality of the commits.
It also makes it easy to remove parts of the changes in a file that was only there for debugging purposes — before the commit without having to go back to the editor.
Once this command runs, we’ll be asked about “hunks”.
You’ll see the question, “Stage this hunk [y, n, g, a, d, e, ?]?” at the bottom of the terminal.
When finished with all the “hunks”, we will be able to see that our commit is ready and we can continue to the push!
Bonus Tip:
git commit -p
combines git add -p
and git commit
in one command.
Your Mistakes Don’t Define You
You made a commit but now you regret it? Maybe you committed secrets by accident — not a good idea — or maybe you want to add more tests to your code changes.
These are all legit reasons to undo your last commit.
Git gives us a command to undo our last commit.
The command git reset
has a variety of things you can trail onto it, let’s talk about the "soft" trailing.
git reset —soft HEAD~
removes the commit from the current branch, but keep the changes!
The cool thing about this command is that the changes won’t disappear!
All the changes will stay in the working tree!
If you don’t want to keep the changes that were introduced by certain commits then use git reset —hard HEAD~
Bonus Tip:
The git pre-commit hook is a built-in feature that lets you define scripts that will run automatically before each commit. Use it to reduce the need to cancel commits.
Look for your choices, pick the best one, then go with it.
Suppose you are working with a team of developers on a medium to large-sized project.
Another team member proposed some changes, and you want to apply a few of them to your main project, not all.
Since managing the changes between several Git branches can become a complex task, and you don’t want to merge a whole branch into another branch.
You only need to pick one or two specific commits. To pick some changes into your main project branch from other branches is called cherry-picking.
In this command, we can pick a particular branch that has a commit and pull it into another. Let’s walk through this.
A commit is a snapshot of your git repository at one point in time and each commit cumulatively forms your repo history.
The cherry-pick
command takes changes from a target commit and places them onto the HEAD of your currently checked-out branch.
From here, you may either continue working with the changes in your working directory or you may commit the cherry-picked changes immediately.
This is helpful if you accidentally make a commit to the wrong branch.
With cherry-picking, you can get those changes onto the correct branch without redoing all that work again.
However, use cherry-pick
sparingly!
Overusing cherry-pick
can lead to duplicate commits, and sometimes a merge may be preferred to preserve commit history.
Real-Life Scenario:
Let’s say we have a branch 76d12
and we have committed all of our changes.
There’s another branch, we’ll just use master
but this can be any branch, and we want to pull in 76d12
’s commit.
By using the command, git cherry-pick 76d12
we can get that entire commit into another branch.
Don’t Want All Of It? No Problem — Just Checkout
Want to Pick a specific file from a branch and bring it into the current branch?
Som, I use git checkout
mostly for switching from one branch to another.
Yes, I know but we can also use it for checking out files and commits.
It’s like git cherry-pick
but rather than "cherry-picking" an entire commit, we are diving even deeper into a branch and picking just a particular file that we want to be merged.
While staying in master
the entire time, we can run the command git checkout Som-test index.js
to grab that particular committed file in that particular branch and bring it over to master to eventually push.
That’s pretty neat when a particular branch’s changes are many and we’re only looking for one file to test or push.
How does it work:
git checkout
tells Git which branch or commit to apply your new changes.
A branch is just a pointer to 1 specific commit, and a commit is a snapshot of your repository at a certain point in time.
The branch pointer moves along with each new commit you make.
If you want to make changes on a branch that you don’t currently have checked out, you first need to checkout the branch.
Checking out a branch will update your repo’s files to match the snapshot of whichever commit the branch points to.
From here, the branch pointer will follow each new commit that you make on the branch.
It’s also possible to directly checkout a commit, which will update your repo’s files to match the snapshot of whichever commit you’ve checked out.
Be aware that checking out a commit moves the HEAD pointer to a commit instead of a branch, putting your repo into what is called a “detached head state” where any changes will not be committed to a branch.
While git checkout is great for getting to work with branches, it’s also a useful tool for reviewing old commits since it switches the version of your repo to this older snapshot.
Someday…But Not Yet, Not Yet
Suppose we have a bunch of changes to a file but need to go back and test something out before we commit and push this or we’re just not ready to commit our changes.
That’s where git stash
comes into play.
When we run the command git stash
it takes those saved, uncommitted changes and "stashes" them for later.
We can then move around different branches, pull changes into master, etc.
Once we have finished testing or doing whatever we needed to do, we can go back into our branch, run the command git stash pop
and our changes will come back! It’s like we never even left!
It Is Time For You To Get Some Help.
There are a plethora of git commands to choose from. And it’s critical that we don’t run commands without knowing what they’ll do to our code.
If we were to run just git help <command>
then we would get an explanation of the command right there in our terminal.
Bonus Tip:
Running the command git help -w <command>
takes us directly to the website that we can read up on all the things with the command in question.
Conclusion
Git is an extremely useful tool. It may be a nightmare if handled incorrectly. I hope these hidden treasures make your Git experience a little more productive.
What is your go-to Git command? Please let me know in the comments!
Note of Gratitude
I wanted to take this last opportunity to say thank you.
Thank you for being here! I could not be able to do what I do without people like you who follow along and take that leap of faith to read my post.
I hope you’ll join me in my future blog post and stick around because we have something great here.
And I hope I will help you along in your career for many more years to come!
See you next time. Bye!
Top comments (10)
Awesome 👍. How did u create these animation ?
The best animations about Git I've seen so far, where are they coming from?
Awesome man
Thank you 😊
You all are a source of inspiration for me to write 🙏
Great post, thanks for sharing !! 👍😎
I am glad you liked it @csaltos 😊
very well done!
Thank you 😊
You all are a source of inspiration for me to write 🙏
Best article I have ever read on Git 🙌