Preparing git reset correctly
A very short note from the series “Hostess on a note”.
A poorly organized developer, like me, it often happens that everyone, and then it turns out that the wrong thing is not there, but git remembers everything and this whole raging 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 Kamites from git - so many times I did not succeed.
And all because my searches led me to a rebase, but I had to look for a reset.
For my taste, the question is not sufficiently illuminated and my note is intended to close this gap.
If there is a more correct way, then please voice in comments.
PS
In fact, Kamites are not removed from the repository, the connection of these Kamites with the tree of changes is removed, so these Kamites disappear from the branch, but git remembers everything.
')
PS2
There was no more correct way (variations with rebase are no more than variations).
But comrades who believe that everything in life always takes place in the same way, and therefore it is always necessary to act in the only correct way, the roof was torn off from such a volgo handling of the repository.
Comrades!
For each task, its tools and its methods, sometimes git reset is a suitable method, especially when you are on the project as a developer and you want to roll back the Camites in the last two hours of work in your feature branch.
Foreword
A poorly organized developer, like me, it often happens that everyone, and then it turns out that the wrong thing is not there, but git remembers everything and this whole raging 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 Kamites from git - so many times I did not succeed.
And all because my searches led me to a rebase, but I had to look for a reset.
For my taste, the question is not sufficiently illuminated and my note is intended 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 beginning with which we need to forget our changes, while from the local branch all of the Kamites from the specified will be forgotten - deleted
- git push --force origin feature / draft // fill in the local branch to the original (server branch) - from the original branch all “extra” CAMITs will be deleted
- Victory !
If there is a more correct way, then please voice in comments.
PS
In fact, Kamites are not removed from the repository, the connection of these Kamites with the tree of changes is removed, so these Kamites disappear from the branch, but git remembers everything.
')
PS2
There was no more correct way (variations with rebase are no more than variations).
But comrades who believe that everything in life always takes place in the same way, and therefore it is always necessary to act in the only correct way, the roof was torn off from such a volgo handling of the repository.
Comrades!
For each task, its tools and its methods, sometimes git reset is a suitable method, especially when you are on the project as a developer and you want to roll back the Camites in the last two hours of work in your feature branch.
Source: https://habr.com/ru/post/330722/
All Articles