My colleague/friend wrote an insightful piece on overcoming git disasters, or as we refer to them, gitsasters. I thought to give a high-level summary and invite you to check out real-life instances where the git reset tool comes in handy.
What is a gitsaster?
Understanding the concept of git can actually help you know when things go wrong. For example, when you do something you didn't mean to do and just want to go back in time- this is precisely what a gitsaster is.
Things go wrong in git all the time. There are people like myself who understand what's happening underneath the hood and thus remain calm.
But, what about those who don't have as deep an understanding? They tend to look at git like a magical black box.
Recording changes in git
I don't think a few sentences can give this topic justice. This article provides a thorough overview on recording changes in git.
But to sum it up: git doesn't commit changes directly from the working tree into the repository. Changes first get registers in the index/"staging area". You can think of the index as a way of “confirming” your changes before doing a commit.
The command git reset, together with its three modes:
- --soft, that moves whatever HEAD is pointing to
- --mixed, that goes on to update the index to what HEAD is pointing to after the soft step
- --hard, which updates the working dir to match the state of the index
Top comments (0)