Somnath Singh

Posted on Dec 2, 2021 • Originally published at javascript.plainenglish.io

Git Commands That Will Save Your Job

#productivity #webdev #beginners #devops

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”.

“Hunks” are the _chunks_ of code that we’ll decide what to do with.

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!

We ran the command git reset — soft HEAD~2 — it moved the HEAD to the previous two commits.

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 76d12we can get that entire commit into another branch.

`cherry-pick b`_ring an entire commit from one branch into another._

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.

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!

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!