Git Commands Made easy
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.
Amend a typo by changing the message
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.
use -amend command to fix the typo
Perfect! Now, your co-workers will not see that your “commit” was originally spelled “committ”.
Commit files by sections
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!
Tip: git commit -p combines git add -p and git commit in one command.
You made a commit but now you regret it? Maybe you committed secrets by accident or maybe you want to add more tests to your code.
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 nice 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~
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.
Choose only part of a commit.
Suppose you are working on a 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.
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? Just Checkout
Want to pick a specific file from a branch and bring it into the current branch?
So, use git checkout mostly for switching from one branch to another 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.
Parking your changes
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.
Save uncommitted changes and stash them for later. This is useful for when you want to commit and push, but aren’t ready to commit the changes since the last commit.
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!