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.
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.
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)
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.Wait, what's the problem with exposing an email? Other than people trying OSINT on you?
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.
Great post. I think another important command is
git cherry-pick <commit 1> <commit 2> ...should be included in the list.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!
Yes, maybe in a separate post.
Thank you !
Thanks for so helpful article