June 12, 2017 at 16:44Cooking git reset correctly
- Tutorial
- Recovery mode
A very short note from the series "Mistress on a note."
For poorly organized developers, such as me, it often happens that you accumulate everything, and then it turns out that something is not right, but git remembers everything and all this rampant anarchy remains in history.
It always seemed to me that this could be fixed, but how many times I didn’t start looking for an answer to this question - how to remove gales in git - so many times I failed.
And all because my searches led me to rebase, but I had to look for reset.
For my taste, the question is not sufficiently covered, and my note is designed to close this gap.
If there is a more correct way, then please voice in the comments.
PS
In fact, kamits from the repository are not deleted, the connection of these kamits with the change tree is deleted, so these kamits disappear from the branch, but git remembers everything.
PS2
There was no more correct way (variations with rebase are nothing more than variations).
But among comrades who believe that everything always happens the same way in life, and therefore you always need to act in the only right way, the roof was torn from such a volatile use of the repository.
Comrades!
For each task, its own tools and its own methods, sometimes git reset is a suitable method, especially when you are a single developer on a project and you want to roll back kamits for the last two hours of work in your feature branch.
Foreword
For poorly organized developers, such as me, it often happens that you accumulate everything, and then it turns out that something is not right, but git remembers everything and all this rampant anarchy remains in history.
It always seemed to me that this could be fixed, but how many times I didn’t start looking for an answer to this question - how to remove gales in git - so many times I failed.
And all because my searches led me to rebase, but I had to look for reset.
For my taste, the question is not sufficiently covered, and my note is designed to close this gap.
Algorithm
- git status // check that we have the current version
- git log // look for the kamit to which we want to roll back
- sudo git reset --hard 7bcdf46b14b2dacc286b0ad469d5f9022d797f68 // specify the kamit starting from which we need to forget our changes, while from the local branch all kamit from the specified will be forgotten - deleted
- git push --force origin feature / draft // fill the local branch into the original (server branch) - all "extra" kamits will be removed from the original branch
- Victory !
If there is a more correct way, then please voice in the comments.
PS
In fact, kamits from the repository are not deleted, the connection of these kamits with the change tree is deleted, so these kamits disappear from the branch, but git remembers everything.
PS2
There was no more correct way (variations with rebase are nothing more than variations).
But among comrades who believe that everything always happens the same way in life, and therefore you always need to act in the only right way, the roof was torn from such a volatile use of the repository.
Comrades!
For each task, its own tools and its own methods, sometimes git reset is a suitable method, especially when you are a single developer on a project and you want to roll back kamits for the last two hours of work in your feature branch.