It gets much more in-depth than this article does, but here’s the tl dr on what you actually need to do from lower down the page: "If the faulty side branch was fixed by adding corrections on top, then doing a revert of the previous revert would be the right thing to do." "If the faulty side branch whose effects were discarded by an earlier revert of a merge was rebuilt from scratch (i.e.
Remove commit from master git full#
You can read the full documentation on handling faulty merges here. Yes, it undoes the data, but no, it doesn't undo history." So if you think of `revert` as `undo`, then you're going to always miss this part of reverts. So the merge will still exist, and it will still be seen as joining the two branches together, and future merges will see that merge as the last shared state - and the revert that reverted the merge brought in will not affect that at all." "A `revert` undoes the data changes, but it's very much _not_ an `undo` in the sense that it doesn't undo the effects of a commit on the repository history. But reverting a merge commit also undoes the _data_ that the commit changed, but it does absolutely nothing to the effects on _history_ that the merge had. Linus Torvalds, the creator of Git, explains why this happens (emphasis mine): "Reverting a regular commit just effectively undoes what that commit did, and is fairly straightforward. The commits in the branch that was merged are permanently reverted, so if you attempt to re-merge a reverted branch without rebuilding those commits, those changes won’t be applied the second time. If you try, you’ll find that the commits from the first merge of the branch that you already reverted won’t be reapplied after the second merge. Unfortunately, you can’t directly do that. The docs for `revert` explain how that works here.Ī common workflow need after you revert a faulty merge is to continue working on the branch and re-merge it later. That’s where the -m flag comes in - passing in a 1 points it to the branch that you had checked out when you began the merge (passing in a 2 would point to the branch that was merged in, which isn’t useful in our case). However, because a merge commit by nature has two parent commits (one from each branch you are merging together), you need to specify which parent is the “mainline” - the base branch you merged into. Normally, you can feed git revert the hash of the commit you want to undo, and Git will then look at that commit’s pointer to its parent commit to determine which changes to revert.
This means that both the original commit and the new inverse commit will both be stored in history, preserving all of the data about what happened but leaving your branch in the state it was before you made the first commit.ĭue to the way merges work, you have to do a little extra work, though.
Remove commit from master git series#
Git revert generates a series of changes that, when applied, produce the exact inverse of whatever commit you give to it, then creates a new commit with those changes. We can use this information to run the git revert command to restore your branch to the state that it was in previously.
How does reverting a merge work?Īs it does with regular commits, Git creates merge commits with a commit hash representing the point in history where the other branch was merged in. happened on GitHub) you can push this commit like any other and you’ll be set to go. Once you have that, you can pass it to the git revert command to undo the merge:Īnd Bob’s your uncle! The git revert command will have generated a commit that restores your branch’s state to where it was before the faulty merge. In this case, `52bc98d` is our merge’s hash. The commit hash is the seven character string in the beginning of each line.
0 kommentar(er)
