Scenario, working with Azure DevOps Git as the remote:

1. Pulled latest main from the remote.
2. Created feature from main and checked it out.
3. Did development work in feature.
4. Committed it (commit A) and pushed feature to the remote.
5. Created a pull request to merge feature into main on the remote.
6. The pull request was completed, adding commit A and new merge commit B.
7. Completion of the pull request trigged a build and deployment--which failed (whether because I'd forgotten to try building it locally before the push or for some other reason).

Now I want to restore the condition of the remote main to remove the impediment, so that others can continue to use it, while I work locally to resolve my problem. But I can't figure out the path to accomplishing that without losing the work I've already done.

First, how do I do a revert on the remote branch? Revert, as I understand it, reverses the changes of one commit. But I've got commits A and B. (Strangely, when I look at them individually on the remote, all the changes made in A are also shown as changes made in B. I'd expected that B, a technicality, would include no changes.) I thought of doing a reset, but Azure DevOps doesn't offer that. I took a guess and reverted A. So now there's a commit C.

Second, I can't just continue working on my local feature branch and expect that I'll later be able to push it and have it merged into the remote master. I'd expect the remote to complain that feature isn't up to date because it lacks commits B and C.

Anticipating this, I pulled the remote master into my local, so that my local master now had commits A, B, and C. Then I merged local master into my local feature branch. The result was that my feature work was removed. The head of the feature branch is now as though I hadn't done the work in the first place.

How do I get the feature work back so I can pick up where I left off, and how should I have handled the rollback in the first place?

CodePudding user response：

Your choices are:

• To reset the main branch to before the merge commit, which erases the merge commit (but nothing else, you will still have your A commit) and rewrites history (which is bad).

• Or, to revert the merge commit on the main branch (probably by means of another PR, as eftshift0 suggests), which is quite safe, but then, although you will still have your A commit, you won't be able to merge it in the future — you will have to rebase your feature branch onto the new main.

CodePudding user response：

Do not overthink it. Create a new feature branch for the reversal from main. Then revert commitA explaining that you are reverting because of blahblahblah and push that as a new PR so that it can be merged and get the branch corrected.[1]

Then you need to make sure that your branch is again mergeable into main so that you can correct whatever messed it up. So, checkout your feature branch and recommit and rebase, that way to git it's stuff that has never been merged and won't complain:

git checkout my-branch
git commit --amend --no-edit # it's a single commit, right?
git rebase main

Now you can continue working as if nothing happened.

[1] You could also revert the merge commit instead, but then you have to pass down another parameter to tell git from what branch you want to see the merge to be able to revert the changes from the other branch... easy, right? Well, it makes sense after a while... but if you are under stress, it's better to take it easy and revert the real commit, not the merge one, even if results will be the same.