1

I had a set of changes in the master branch, then I had to roll it back to a previous tag from production and do a hotfix since I didn't want the set of changes to go into production yet. So what I did was, I branched out backup branch from the master to keep the set of changes in backup branch and then rolled back into the previous tag. Used the following set of commands :

git checkout 1.0.1
git diff master > ~/diff.patch
git checkout master
cat ~/diff.patch | git apply
git commit -am 'Rolled back to version 1.0.1'
git push origin master

But now when I want to merge backup back to master since I intend to push the changes into Production. But im getting Already upto date message when I try to merge.

I do have the commit shas, but since theres a lot of commits to be done I want to avoid cherry picking them. Whats the best and safest way to merge the changes back to master?

JsbDev
  • 23
  • 6
  • "*I didn't loose the commit history by going the `revert`.*" You don't loose the commit history by doing the `revert`. You loose the commit history by doing the `reset`. What you did with `cat ~/diff.patch | git apply` is exactly `revert` just manually. – phd May 09 '23 at 10:31
  • @phd right - im interested on a workaround hopefully avoiding cherry pick. – JsbDev May 09 '23 at 10:34
  • What's wrong with `cherry-pick`? – phd May 09 '23 at 10:35
  • @phd theres a lot and getting merge conflicts – JsbDev May 09 '23 at 10:46
  • 1
    If `git apply patch` doesn't produce merge conflicts `git revert` or `git cherry-pick` most probably will not either. If `git cherry-pick` produces merge conflicts `git apply patch` most probably will do either. Doing `revert/cherry-pick` manually don't help to avoid merge conflicts IMO. – phd May 09 '23 at 10:53
  • right - i just wanted to avoid since it looked bit tedious, but if its the only option I can give it a try. Is there any sequence of commits I should follow when doing the `cherry-pick` ? – JsbDev May 09 '23 at 11:03
  • You did `git diff 1.0.1 master` and it's hard to say without knowing your commit graphs and branches if that diff could be replaced with `cherry-pick` or `revert` — they do diff with the previous commit. If `1.0.1` is behind `master` then `git checkout master && git cherry-pick 1.0.1..master` should do it. – phd May 09 '23 at 11:09

1 Answers1

2

To recap, currently:

  1. There is a single commit on master which rolled back all of the changes since version 1.0.1. Let's call that commit X.
  2. You have a branch backup pointing to the commit just before X.
  3. There are probably some hotfix commits on master after X.

An example graph might look like this:

G    Merge Hotfix into master (master)
|\
| F  Hotfix Part 2
| |
| E  Hotfix Part 1
|/
X    Rollback to version 1.0.1
|
D    Fixup for Feature B (backup)
|
C    Merge Feature B into master
|\
| B  Feature B
| |
A |  Version 1.0.1 (Tag: 1.0.1)
...

Regarding:

But now when I want to merge backup back to master... I'm getting "Already up to date" message.

Note that the way you did your rollback, (which was a fine way to do it), you added a single commit (X) which reversed all of the changes in the commits in git log A..D. Therefore, all commits present in the backup branch are already in master, so there are no new commit IDs to merge in.

The easiest way to accomplish your goal is to revert the rollback commit.

For example:

# Create a new branch from master
git switch -c revert-rollback master
git revert X # When prompted make your commit message
# add any other commits you need, if applicable
# Now you can merge revert-rollback into master

Tip: When reverting a commit, and especially when reverting a revert (which is kind of what you're doing in this case, since your patched rollback was like a set of reverts), I recommend adding details to the commit message explaining why you're doing it. So your commit message for the revert of the rollback might look something like this:

Revert "Rollback to version 1.0.1"

This reverts commit xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.

We originally rolled back to make room for a hotfix, and now we're ready to release the new code since v1.0.1.

TTT
  • 22,611
  • 8
  • 63
  • 69