DEV Community

Cover image for 5 Git commands you should know πŸš€
Hssan Bouzlima
Hssan Bouzlima

Posted on

5 Git commands you should know πŸš€

In this article, I will discuss some useful git commands we may need in our day-to-day work. Git reset (soft and hard), revert, rebase, rebase -i and log.

To illustrate these different commands and for simplicity, I will use the same git project.

My example is very straightforward. I initialized a git project and added files from 1.txt to 10.txt, and each file is added in a separate git commit. 1.txt is in commit 1, 2.txt is in commit 2 and so on.

8d679fa (HEAD -> master) 10
e7535c7 9
916c4d5 8
eb15d0d 7
94669d1 6
8300f81 5
617590b 4
f0b1c87 3
a62c707 2
2ad16a7 1

Git reset.

Git reset is a powerful command when we have to remove something we did in a previous commit. There are two types of reset hard and soft.

soft:
We use a git soft when we want to remove a set of commits but unstage all the changes there. In other words, you still have these commit contents, but they are unstaged, so you have the choice to remove them or update them and stage them for a new commit.

Example:

git reset 8300f81 will unstage commits from 10 to 6, and the head is on the specified commit 8300f81

hard:
Reset hard does not offer the possibility to stage our reset changes; instead, it will remove the commits and all their content explicitly.

Example:

git reset 8300f81 --hard will remove commits from 10 to 6 and remove related content as well. The head is now on 8300f81.


git revert

Do not get confused by reset and revert, there are differences between them.
Imagine a situation where you make some changes, and then you figure out that these changes are worthless now, but you may need them in the future. What would you do?
You could revert them. Revert makes it possible to remove unwanted changes, but at the same time, it keeps the commit containing these changes. Revert creates automatically a revert commit that does not contain unwanted changes.

Example:

Given that you are not satisfied with commit 617590b and at the same time you want to keep it in history.
So you reverted that commit: git revert 617590b
It opens a terminal screen where you specify your revert message. Once done, the head will be on the new revert commit, and the old commit will remain in your git history.

e6371ff (HEAD -> master) Revert "4"
8d679fa 10
e7535c7 9
916c4d5 8
eb15d0d 7
94669d1 6
8300f81 5
617590b 4
f0b1c87 3
a62c707 2
2ad16a7 1


git rebase

Rebase is similar to merge, but it works differently. Instead of creating a merge commit, it "rewrites" history by changing the base of your branch from one commit to another. In this way, it maintains a flat history and eliminates ambiguity. The following is the most evident illustration that I have discovered illustrating the distinctions between Rebase and Merge.

Merge vs Rebase


Merge vs Rebase


git rebase -i

Interactive rebase is a magical command when it comes to making changes in git commit history, like editing commit messages, combining commits together, or removing a commit(Example below).
git rebase -i 8300f81 (commit 5). Will open your terminal with the commit list from commit 10 to commit 6. In front of each commit you can choose between multiple options like pick, reword, fixup, squash, drop. Once you are satisfied with your choice, the terminal will be closed automatically, and your changes will be applied.

Rebase-i


Interactive rebase screen example


git log

This command gives you all your git commit history, commit hash and message. Useful to keep track of your project or whenever you need to use a commit hash in one of your git commands.
Multiple flags could be used with log like --oneline (for each line print a single commit), --all (all branches)

git log --oneline --all


Conclusion

Throughout the article, I tried to simplify what these different commands do and what their benefits are. I hope the examples are clear and help you choose the git command you need.

I think, in addition to the usual git commands (status, add, commit, pull and merge)reset, revert, log and rebase are handy for everyday work and make you more confident with git.

Thanks for reading !

Top comments (7)

Collapse
 
logarithmicspirals profile image
logarithmicspirals

I think another super important one which is often overlooked is git config user.name user.email. You should be aware as to what identity you're using to make commits. This is especially important when you're contributing to open source projects. Beginners may not be aware their personal email could be exposed the first time they commit to a project on a platform like GitHub.

Collapse
 
framedoubt profile image
Brandon Wright

Wait, what's the problem with exposing an email? Other than people trying OSINT on you?

Collapse
 
logarithmicspirals profile image
logarithmicspirals • Edited

There's nothing inherently wrong with exposing an email, it's just something to be aware of. If someone is new to open source and they use their name and personal email for commits, that could be a problem if they don't practice good cybersecurity habits. That's completely possible for someone who's new to the field. The main concern would be OSINT, as you pointed out.

If someone was using one email for all accounts and got caught up in a data breach, then an attacker might be able to compromise their GitHub/GitLab/etc account based on their commit history.

Another thing I could think of would be a freelancer using a personal GitHub email and a client email. Maybe they want to keep those separate, but don't realize you can change the email at the project level. Is that a problem? Not necessarily, but it could be. Which is why you should be aware of it, so that you can use it correctly.

Collapse
 
tharakamts profile image
Tharaka Sandaruwan • Edited

Great post. I think another important command is git cherry-pick <commit 1> <commit 2> ... should be included in the list.

Collapse
 
thecodersden profile image
Rajdip Bhattacharya

Thanks man I really liked to read about rebase! I feel you can even go to the extent of writing a separate blog, totally dedicated to rebase vs merge, and give a detailed overview of the options they support. Not to mention, highlighting what linear and non linear histories are would be a cherry on the top!

Collapse
 
hssanbzlm profile image
Hssan Bouzlima

Yes, maybe in a separate post.
Thank you !

Collapse
 
ra1nbow1 profile image
Matvey Romanov

Thanks for so helpful article