How to re-merge all of my changes from a previous branch

Question

So I realize that many of you are going to cringe when reading some of this... but I have a develop fork and a prod fork of my project, mostly to keep prod passwords, appsettings, etc from being seen by my devs. I ended up merging in some changes from my dev branch into my prod branch to push things that were ready, and rejected the other changes. This has gone on over several commits and merges. The problem is now that I am ready to accept some of those changes that I previously rejected, trying to do a merge fails, I get a Already up to date message. Again, I realize that I should not have been doing this, but instead using feature branches, etc. but now it's too late, how do I force git to recheck the differences between the branches and allow me to integrate them into my prod branch?

Answer 1

What you want is not a merge—or perhaps it would be better to say, not a git merge. What git merge does is a three-way merge. A three-way merge has three inputs: a merge base, and two other commits, usually branch tip commits.

You wrote in a comment:

When I do a git diff --stat dev..prod I can see differences between the 2 branches ...

What git diff does is compare two commits (not three).

Let's consider the case of just one file, which can exist in two commits with a third commit that is the merge base. Let's draw this as well, as a tiny little commit graph fragment:

...--B--X   <-- main (HEAD)
      \
       Y   <-- branch

Suppose the file in question is hello.txt. In commit B it reads:

Hello!
I am a file.
Don't panic!

In commit X, it reads:

Hello!
I am a changed file.
Don't panic!

In commit Y, it reads:

Hello!
I am a file.
Don't panic!
But do remember where your towel is.

Now, if we wanted to merge these two changes, we would note that:

• In B, the second line says "I am a file", but in exactly one of the two tip commits, it now says "I am a changed file."
• In B, there are only three lines, but in exactly one of the two tip commits, there's a new fourth line about towels.

To make the merged result, then, we'd change the second line, and add the new fourth line.

But if we compare the file in X with the file in Y, we see this:

Hello!
-I am a changed file.
+I am a file.
Don't panic!
+But do remember where your towel is.

All we know is that the second line is different and the fourth line is added.

I want the differences in dev to be brought into prod

That's a problem, because literally, this just means "make prod exactly the same as dev". You can do this (easily) in Git, but it's probably not what you want to do.

The result of taking these changes in would be:

Hello!
I am a file.
Don't panic!
But do remember where your towel is.

That is, we lose the change to line 2. For considerably more on this, see Why is a 3-way merge advantageous over a 2-way merge?

If you do want to do a two-way interactive merge in Git, i.e., to take a diff and interactively decide which parts to apply and which to ignore, there is not that much built in. Git does have git add -p: you can extract a file from branch dev, use git add -p on it, and interactively choose whether to apply a hunk, or skip it. (Once you're satisfied with the result, you can git checkout-index <file> to overwrite the work-tree version with the one interactively-patched into the index, just to view it.)

Otherwise, you are left with the issue of finding a suitable merge base version of the file. If you do find a merge base, you can perform a file-at-a-time merge using git merge-file:

git show basecommit:path > path.base
git show dev:path > path.dev
git merge-file path path.base path.dev

What git merge does is automatically find a suitable merge base, using the commit history, and then automatically extract these files and run git merge-file on each one. But if you've done merges, then overridden the result of those merges, the recorded-in-history merge base says that you already decided (and recorded for all future reference) not to take those changes. So now git merge won't take them.