How do I best revert to a tag, make further changes, then reinstate all the subsequent changes, in Git?

Question

Looking at all the ways to revert or reset in Git when dealing with branches, tags, etc...I thought I had a good handle on it but it's getting confusing.

So what is the simplest sequence of commands I need to do the following?

1. Revert master branch to an earlier state via a pull request. Presumably, I'd create a feature branch, revert it, and merge it via a pull request. (This revert includes reverting earlier merges.)
2. Make further changes in a feature branch. Not sure if it matters for later steps whether I merge to master before and after, or only after.
3. Push and then merge to master (via a Pull Request to get it into master, outside of Git)
4. Then reinstate the later changes that I rolled back in step 1, resolving any conflicts, and also keeping the changes from steps 2-3.

I started down the road of git --no-commit revert commit-after-the-tag..HEAD but now I am worried that there will be no easy way to reinstate the changes, since my revert commit will be newer than the changes I want to reinstate. (Also, I'm having trouble reverting as the code to revert includes merges.)

So I think I want to revert to a tag, make further changes, then reinstate all the subsequent reverted changes. How do I do that?

Answer 1

Here's a way--assuming your origin Git repo is in a system that supports pull requests, such as GitHub or Azure DevOps, and thus you want to review changes and avoid modifying history. If you don't have or don't want pull requests, you can instead use a simpler git reset --HARD approach.

Now I didn't like the behavior of trying git-revert, as it made me resolve conflicts one-by-one, even if earlier changes made the conflicts redundant. So the following is a better approach.

1. Use git patch and git apply to rollback the changes in a new branch, noting the resulting commit hash
2. Merge the rollback plus fixes (into master) using one or more pull requests (ordinary development workflow). Do the desired build, deploy, and iteration.
3. When ready, revert the hash noted earlier to reinstate the changes and merge into master

This approach retains all history and does not require changes to the master pull request policies. git reset --hard is a bit simpler but requires a force-push, which we don't want.

Below are exactly the commands needed for this. If any command fails or gives warnings, DO NOT continue on; pay attention to them and resolve them.

Rollback

; ensure you are in a good state without other changes to confuse you
git checkout master && git pull

; create the patch that can roll back the code
git diff master [known-good-tag] > /some/path/tempfile.patch

; create the hotfix branch and push it to origin
git checkout -b [HOTFIX-BRANCH-NAME] && git push --set-upstream origin [HOTFIX-BRANCH-NAME]

; apply the patch in the new branch
git apply  /some/path/tempfile.patch

; commit the changes locally
git add -A   && git commit -m "rolling back newest changes"
; Note the resulting commit hash: later you'll have to revert this rollback commit ONLY.  If you forget it, you can find it in the git log history by the commit comment. 

; push the commit to origin
git push

; Make further changes.  Iterate as desired with ordinary workflow.
git add -A   && git commit -m "Fix to xyz because of abc"
git push

Merge rollback+fixes with a pull request. Multiple merges are okay too.

Revert the rollback, retaining newest fixes and reinstating recent development:

; ensure you are in a good state without other changes to confuse you   
git checkout master && git pull

; After deployment Create a new branch for reverting the rollback
git checkout -b [REINSTATE-BRANCH-NAME]  && git push --set-upstream origin [REINSTATE-BRANCH-NAME]

; revert the rollback commit noted earlier.  Note that `git revert` creates a commit.
git revert --no-edit [hash]


; Resolve conflicts if necessary. I like to use VS Code because it has easy conflict resolution tools.
code <FILE_WITH_CONFLICT>
git add <FILE_WITH_CONFLICT>

; finish the revert with the resolved conflicts. Iterate if needed.
git revert --continue

; push the completed revert and request another pull request to merge to master.  Then you are back to ordinary workflow.
git push

By the way, consider if you really need to do the above. There are many easier solutions in many cases, such as:

• Do you just need to build and/or deploy an earlier version without changes? Most build systems let you build an earlier commit, or deploy an artifact that is already built.
• Can you just fix the current state of master and deploy, including all recent changes? Use feature toggles or other disabling features as desired.

Answer 2

I assume you have the following history (time flows left-to-right):

--o--o--T--a--b--c--d    <- feature-branch
             /
 ...--x--x--x            <- commits merged into feature-branch

_{Notice that the fact that this is a "feature" branch is irrelevant.}

T is the tagged commit that you want to go back to and build additional changes on, so that you arrive at the following history:

--o--o--T--E--F--G--a'--b'--c'--d'
                       /
           ...--x--x--x

You can do this with the following sequence of commands. Begin with a new temporary branch at the tagged commit:

git checkout -b tmp T

This rewinds your work (but not your branch) back to the tagged commit. Now you make the commits:

# edit
git commit   # E
# edit
git commit   # F
# edit
git commit   # G

You have now this history:

          E--F--G        <- tmp
         /
--o--o--T--a--b--c--d    <- feature-branch
             /
 ...--x--x--x

Finally, you use the "rebase-merges" mode of git rebase to arrive at the final history:

git checkout feature-branch
git rebase -i -r tmp

You no longer need the temporary branch and you can remove it:

git branch -d tmp

---

EDIT: Following the discussion in the comments, I suggest you do this:

Rename the branch tmp:

git branch -m tmp fixups

Do whatever is needed to get hold of the current master that you have to revert to an older state. Call that branch master-reverted. Then:

git rm -r .
git checkout T -- .
git commit -m "reverted back to tag T"

(The git rm . just ensures that no files are left over that have been added since T; you can skip the step if no files were added.)

Now merge the fixups into the branch:

git merge fixups

Now make a pull request to pull your branch master-reverted and deploy it.

Then revert the revert, but do that on a new branch:

git checkout -b master-new
git revert HEAD~

Now make a pull request to get master-new out. This is the final history:

 ...--x--x--x          
             \
--o--o--T--a--b--c--d          <- feature-branch
         \           \   
          E   ...--m--m       R' <- master-new
           \           \     /
            \            R--M  <- master-reverted
             \             /
              F-----------G   <- fixups (was tmp)

The --m--m is the upstream master branch. R is the revert of master, the R' is the reverted revert of master.