You are trying to revert a merge commit, and git doesn't know which parent to revert to. The -m allows us to choose which parent to choose. See the merge commit and note down which parent you want to go to. The parent information can be seen in git log, for example:
commit d02ee0f2179def10277f30c71c5d6f59ded3c595
Merge: dd3a24c 2462a52
and run:
git revert <hash> -m 1
where 1 indicates parent number 1 (dd3a24c).
If you are trying to revert to that commit, do:
git reset --hard <hash>
Understand the difference between git revert and git reset from the docs and decide which one you want. git revert is the safer option, but doesn't really do what you want. It just reverts the changes of a (set of) commit. git reset makes you move to a particular commit in history, and will rewrite your history.
You are trying to revert a merge commit, and git doesn't know which parent to revert to. The -m allows us to choose which parent to choose. See the merge commit and note down which parent you want to go to. The parent information can be seen in git log, for example:
commit d02ee0f2179def10277f30c71c5d6f59ded3c595
Merge: dd3a24c 2462a52
and run:
git revert <hash> -m 1
where 1 indicates parent number 1 (dd3a24c).
If you are trying to revert to that commit, do:
git reset --hard <hash>
Understand the difference between git revert and git reset from the docs and decide which one you want. git revert is the safer option, but doesn't really do what you want. It just reverts the changes of a (set of) commit. git reset makes you move to a particular commit in history, and will rewrite your history.
I want to revert back to ...
Then you don't want git revert, at least not like this. git revert is for reverting the specific changes made in that commit. What you're looking for is to revert or undo all the changes made after that commit.
git reset is the command to use here.
git reset --hard c14609d74eec3ccebafc73fa875ec58445471765 completely resets your branch, index and work tree to that specific commit.
Note that the usual precautions apply: if anyone else has fetched later commits already, removing them from the history like this complicates matters for them. If you instead want to create a new commit, which simply restores the state to that of commit c14609d74eec3ccebafc73fa875ec58445471765, you can use git rm and git checkout:
git rm -r .
git checkout c14609d74eec3ccebafc73fa875ec58445471765 .
(The rm is needed to make sure newly added files also get removed.)
This lets you then create a new commit, on top of your local history, which undoes every change since c14609d74eec3ccebafc73fa875ec58445471765.
github - Why does git revert complain about a missing -m option? - Stack Overflow
Cannot revert merge commit
github - Git Revert a Revert for a Merge - Stack Overflow
Need help undoing or fixing Merge commit and Revert merge commit that were both pushed to remote and merged into a parent branch
By default git revert refuses to revert a merge commit as what that actually means is ambiguous. I presume that your HEAD is in fact a merge commit.
If you want to revert the merge commit, you have to specify which parent of the merge you want to consider to be the main trunk, i.e. what you want to revert to.
Often this will be parent number one, for example if you were on master and did git merge unwanted and then decided to revert the merge of unwanted. The first parent would be your pre-merge master branch and the second parent would be the tip of unwanted.
In this case you could do:
git revert -m 1 HEAD
git cat-file -p [MERGE_COMMIT_ID] will show the parent branches in order. The first one listed would be -m 1, the second -m 2.
Say the other guy created bar on top of foo, but you created baz in the meantime and then merged, giving a history of
$ git lola * 2582152 (HEAD, master) Merge branch 'otherguy' |\ | * c7256de (otherguy) bar * | b7e7176 baz |/ * 9968f79 foo
Note: git lola is a non-standard but useful alias.
No dice with git revert:
$ git revert HEAD fatal: Commit 2582152... is a merge but no -m option was given.
Charles Bailey gave an excellent answer as usual. Using git revert as in
$ git revert --no-edit -m 1 HEAD [master e900aad] Revert "Merge branch 'otherguy'" 0 files changed, 0 insertions(+), 0 deletions(-) delete mode 100644 bar
effectively deletes bar and produces a history of
$ git lola * e900aad (HEAD, master) Revert "Merge branch 'otherguy'" * 2582152 Merge branch 'otherguy' |\ | * c7256de (otherguy) bar * | b7e7176 baz |/ * 9968f79 foo
But I suspect you want to throw away the merge commit:
$ git reset --hard HEAD^ HEAD is now at b7e7176 baz $ git lola * b7e7176 (HEAD, master) baz | * c7256de (otherguy) bar |/ * 9968f79 foo
As documented in the git rev-parse manual
<rev>^, e.g. HEAD^,v1.5.1^0
A suffix^to a revision parameter means the first parent of that commit object.^<n>means the n-th parent (i.e.<rev>^is equivalent to<rev>^1). As a special rule,<rev>^0means the commit itself and is used when<rev>is the object name of a tag object that refers to a commit object.
so before invoking git reset, HEAD^ (or HEAD^1) was b7e7176 and HEAD^2 was c7256de, i.e., respectively the first and second parents of the merge commit.
Be careful with git reset --hard because it can destroy work.
The error which you see is artificial check of github, which I personally find unneeded. You can revert the revert locally then:
git fetch origin master
git checkout origin/master (or reset)
git revert <REVERT HASH>
git push origin master
This should succeed, modulo conflicts with changes done since the revert.
PS: actually, the error could be because of the conflicts.
What you can try is:
- reset (
git reset --hard old_commit) that PR branch to the commit you want to revert to (the one that was reverted) - force push (
git push --force) that branch: that will update the PR
That way, the PR is done again with the old commit.
This is a merge commit. The PR is already closed and merged.
In that case, if you have fetch that old PR branch, you can do:
- a
git logon it (git log origin/old_pr_branch) a new branch from the old SHA1 commit representing the content you now want
git checkout -b new_pr_branch old_sha1a push to origin
git push -u origin new_pr_branch
You can then make a new PR from that new branch, with the right content.
Hi all, I am working off of 2 main branches: develop and prototype. Develop is our main stable branch where we create release branches from. Prototype is the main branch for our new epic we are developing.
EDIT: prototype is branched off of develop
I created a feature branch off of prototype called "submit-feature" and implemented some functionality.
I realized that submit-feature was behind develop and prototype by multiple commits. Locally, I decided to merge develop into prototype, and then merge prototype into submit-feature. I pushed this commit to remote.
When I created a pull request, I noticed that the changes from develop were being introduced into prototype from the submit-feature branch. There were too many files that were mixed with my changes, so I wanted to separate the merge from develop into prototype and isolate those changes and merge conflicts.
I reverted the merge commit, pushed that to remote, and updated my PR from submit-feature into prototype. Now, the PR only contains the file changes I made for the feature.
I merged develop into prototype separately and committed it. Prototype is now up-to-date, but I forgot to merge prototype into submit-feature. I merged my PR for submit-feature into prototype, but I didn't realize that there were deleted/changed files as a result of my previous merge commit. Develop is still clean since we won't merge prototype into it until we have completely tested everything.
Now prototype is broken and other devs have merged this branch with their feature branches. How can I undo this revert merge commit (and maybe the first merge commit) from my submit-feature and prototype branches?
Can I revert the "revert merge commit"? Should I pull develop and prototype again into submit-feature, and create another PR so it won't erase/mess with the commit history for the other devs?
What merging practices and steps should I follow in the future to avoid this situation? Any advice/suggestions would be appreciated, thanks!
I have a repo that I would like to fix the history of. In the process of trying to rebase my branches I accidentally created a merge commit with duplicated commits and then kept committing on top of this without realizing. How can I go back and rewrite my history to remove this accidental merge? Below is the current structure of my branch. I am trying to remove D' and E' since they are already existing in the 'proper' history as well as F because it is just a merge commit.
<many more commits to HEAD> G F | \ | E' | D' | | E | D | C | B / A
and Id like to change it to:
<many more commits to HEAD> G E D C B A
Branches are named after an organizational ticket. So lets say we have branches (from oldest to newest) First, Second, OG, Fourth, Fifth
These were all branched from, and then merged back into the Working branch.
At some point recently, the range from newest to oldest of the above commits was targeted for git revert.
In doing so, my merge (OG) was also reverted.
How do I put that one commit back while leaving the others out?
Hi,
So Ive been working with git (on azure, dont judge). I have a "release candidate" branch. I also have branches for each additional feature that I am adding.
So the process I currently do is to do whatever changes etc to the feature branch, check it builds then make a pull request to the RC branch, which is then merged in. If there happens to be something missing or broken then great, more changes to feature branch, then PR into RC branch, same process.
HOWEVER!
How do I handle it if at some point we decide that ok, we need to release the RC, but $feature is not ready yet - lets remove/revert all of the Pull request merges that came from that branch? (and I will then refactor and put them into the next release's RC branch)
So please let me know:
-
am I doing something incredibly stupid.... :D
-
what is the "sane" way to handle this?
(please be nice if Ive understood something incorrectly)