Rollback the already published commit and post a new one without causing merge in others

Question

Suppose I made a commit X and published it to a remote repository ( git push ). Everyone who has access to the repository has been updated.

Then I usually roll back the commit via git reset --hard HEAD~1 , make changes and push through the git push -f origin master , which completely deletes the last commit. However, if everything is triggered again, they will have a merged remote commit with a new one.

How to avoid it?

If someone has solved your problem with his answer, then do not be lazy to mark the answer with a tick (next to the arrows at the answers) so that it does not hang in the list of unanswered :)

Answer 1 · 2015-06-11T18:29:32

If a commit is in a common / stable branch (that is, the one that is used by at least someone else, usually master , develop and others), then it cannot be deleted. You can only create a “canceling” commit with git revert ( for more, see here, point 5 ).

Perhaps your commit contained some critical data, such as passwords or keys. In this case, it is useless to try to save them by removing the commit that contains them. The data has already been compromised, all passwords and keys will have to be changed.

 # отменяем последний коммит, доступный по указателю HEAD git revert HEAD # фиксируем отмену в новом коммите git commit -m'reverted the last commit'

If you are absolutely sure that you have launched an “extra” commit into your own branch, that no one has locked it into a stable branch and just didn’t start development from your last commit, you can roll back the local branch to the previous commit, and then rewrite the changes in the deleted one ( read more here, clause 4.2 )

Attention! Never do this with shared branches ( master , develop and others).
If it is absolutely necessary, be sure and immediately warn everyone who works with this repository. After rewriting the last commit in a stable branch, they will have to manually update this branch on their machine. If they have any new commits whose ancestor is the commit to be deleted, they will have to rebase to the commit.

 git reset HEAD^ git push -f

Here you have my favorite scheme illustrating different solutions.

Wow, thank you so much for the scheme, for a long time I wanted to hang something like that at work
Please give a link to the source of the flowchart to read and view on a normal scale
@Cerbo and there is a link in the upper left corner in small print.
There is nothing else, I found the picture in the same form.

Answer 2 · 2015-06-11T17:32:24

They are likely to have not just a merge with a remote commit, but there will be some problems. After all, they have commits with parent A in the repositories, and another commit is in the remote repository, but also with parent A I, frankly, do not know how git behaves, but the only correct solution in this situation is to roll back all local repositories in the same way as you rolled back: git reset --hard HEAD~1 , only then git pull

Generally speaking, a git push -f origin master , in a repository that is used by more than one person, is slapped in the face. This can be done only in EMERGENCY cases and only if the whole team is aware of what is happening and takes appropriate measures on its local copies.

I, frankly, do not know how git will behave - the only behavior I have encountered for the situation described: the git program tries to make a local and remote branches merge .
with all the ensuing consequences in the event of a conflict.
@alexanderbarakin Git will not push without the --forced key.
@NickVolynkin, I wrote about the behavior when git pull from a remote repository, in which the top of the story is copied (relative to the local repository).
Git will say that you have an irrelevant version and you first need to do pull , that is, fetch + merge .

Rollback the already published commit and post a new one without causing merge in others

2 answers 2

More articles: