0

I have two branches:
Branch 'dev'
Branch 'prod'

'dev' is where all features are consolidated, 'prod' is the production branch. Before new releases, 'dev' is merged to 'prod' and a release build is made from it.

The 'prod' branch has certain things like ads which I do not want in the 'dev' branch.

Today while merging 'dev' to 'prod', I got a merge conflict. Resolving the merge changed both my source branch 'dev' and target branch 'prod'. As such I am having many parts of code from target to source which I do not want.

What is the best way to keep the changes in 'prod' but undo them in 'dev'? Thanks.

SayantanRC
  • 799
  • 7
  • 23
  • Resolving conflicts does not change *any* branch. *Nothing* changes any *existing commit* as this is not possible. Adding a *new* commit *to* the current branch does exactly that: it adds a new commit to the current branch. – torek Mar 02 '20 at 18:09
  • I suspect you're tripping over the difference between the files that you see and edit in your work-tree, and the files that are in each commit. Remember that branch names simply hold the hash IDs of existing commits, and the process of adding a new commit consists of (1) making the new commit such that its parent(s) are existing commit(s) and then (2) writing the new commit's hash ID into the current branch name, so that the new commit is now contained in the branch. *Merging* builds a new commit (with a snapshot as usual) with two parents, so that both commit chains become reachable. – torek Mar 02 '20 at 18:10
  • For a practical method of applying a change to a historical commit, then merging that change into *both* branches, see [Gem Taylor's answer](https://stackoverflow.com/a/60493758/1256452) but consider [Raymond Chen's multipart essay](https://devblogs.microsoft.com/oldnewthing/20180323-01/?p=98325) instead. – torek Mar 02 '20 at 18:13

1 Answers1

0

When you work out what you actually want to do, the best thing to do first is unwind and try again, but you can only do that if you have not pushed the changes yet, or nobody has subsequently pushed changes (and you have enough admin rights). If you ask nicely, people maybe can push their changes again after you have cleaned up.

What I would do to resolve the conflict is to consider the change on prod that is giving you grief vs the dev feature change you are trying to implement, and work out the change on each branch that gets them close to agreeing what the solution will be.

Basically first refactor both code bases so that they are compatible with the actual feature change, get that submitted, then get the feature change submitted.

Probably this involves having up to 4 branches:

  • One off dev for the refactor
  • One off prod for the refactor where you will fix up the refactor against the adverts
  • A second off the refactored dev that contains the feature
  • A second off the refactored release that will receive the feature and you don't expect issues when merging to it.

Hopefully you can keep the changes clean enough that you can then merge each of these branches back in turn and push them.

Do that all locally, and expect some iterations of the first phase, but if you don't push it, then it is easy to back out.

Gem Taylor
  • 5,381
  • 1
  • 9
  • 27