git merge PR of previously reverted commits (but not all the reverted commits)

Question

I have reviewed multiple similar questions and responses that haven't worked for my situation.

Most recently, "Github does not recognize…" in 2017

I have the situation that

• branch A -> B
• B (adds 100 commits)
• B -> C (adds 1 commit)
• B (adds another 100 commits)
• accident: B merges to A via PR (w/ 200 commits)
• remedy: revert that PR (w/ 1 commit)
• desire: merge C to A

thoughts/attempts

• PR (C -> A) does not see changes
• sidebar: PR (A -> C) will try to revert the relevant changes from C - this defines the desired effort, but in reverse
• Creating C', rebasing C from A, PR does not see changes (because the merge/revert didn't involve C)
• Can't revert the revert (option 1 from above link), this would include unwanted B content
• Do I have to cherry-pick? (the reverted PR won't list all the commits, only shows 99, then fails on the "show all")

Is this a solution/workaround:

• rename A -> D; D would likely be unused after that
• rename C -> A
• if so, where does that leave B, whose work needs to move into A eventually?

extra points question, followup on above workaround

• If you have Azure git branch policies, do they belong to a branch or a branch name?

---

For those who need the concrete:

• A - master
• B - develop
• C - 1.3 release branch
• D - 1.2 release (which doesn't exist as a branch currently, just tags 1.2.0,…, and likely wouldn't be used)

---

Note: In our environment, corporate had branch A locked down such that I could not push -f to it directly, nor could I git reset --hard on the server.

If these had been options, I would have done so immediately.

Having run aground on this, I will know next time (hopefully which never comes) that I will contact the DevOps team immediately to get temporary access to the branch that is needed and use the tools the way they want to be used. The revert of a commit was very undesirable.

Answer 1

Let's draw out your repository so we're all on the same page.

• branch A -> B
• B (adds 100 commits)
• B -> C (adds 1 commit)
• B (adds another 100 commits)

I'm not going to write out 100 commits, 2 is fine.

1 - 2 - 3 [A]
         \
          4 - 100 - 5 - 200 [B]
                \
                 7 [C]

• accident: B merges to A via PR (w/ 200 commits)

1 - 2 - 3 ------------------ M [A]
         \                 /
          4 - 100 - 5 - 200 [B]
                \
                 7 [C]

• remedy: revert that PR (w/ 1 commit)

1 - 2 - 3 ------------------ M - R [A]
         \                 /
          4 - 100 - 5 - 200 [B]
                \
                 7 [C]

The problem is now your history of A is polluted with all this junk from B, then a huge reversion. That's going to cause all sorts of headaches.

I would recommend cleaning up your history by resetting A to before the merge and reversion and force pushing that.

• git checkout A
• git reset --hard A~2
• git push --force-with-index.

A~2 is the second commit before A, following only its first parents. That would be commit 3 in the diagram above.

With that done you're back to before the goof.

1 - 2 - 3 [A]
         \
          4 - 100 - 5 - 200 [B]
                \
                 7 [C]

• desire: merge C to A

Depends on what that means.

Does C depend on its portion of B? Do you want to merge 4 and 100? Then merge C. After C is merged, rebase B onto A.

$ PR(C->A)
$ git checkout A
$ git pull
$ git checkout B
$ git rebase A

1 - 2 - 3 -----------[A]
         \           / \
          4 - 100 - 7   5 - 200 [B]

Does that one commit in C stand alone? Cherry pick it onto A and merge.

$ git rebase --onto A C~ C
$ git checkout A
$ git merge --no-ff C
          7' [C]
         / \
1 - 2 - 3 -- [A]
         \
          4 - 100 - 5 - 200 [B]

---

Final piece of advice, if you're really putting 200 commits in a branch your branches are too large. Cut your work down into smaller chunks. Consider adopting the Feature Branch or Gitflow workflows.