0

I need to make a pull request between two branches, let's say develop and release, in order to bring the new code to the release environment. I know there will be conflicts at this merge, so first I will need to address these. The current policy that the company has is not to bring release to develop so I am going to use an intermediary branch for this, let's call it merge-branch.

Now there are two possible approaches:

  1. Create the merge-branch from develop then bring the release to it, solve conflicts and then get back to release with a pull request.

    develop -> merge-branch (creating merge-branch from develop)
release -> merge-branch (pull from release to merge-branch in order to solve conflicts)
merge-branch -> release (opening the pull request)

  2. Create the merge-branch from release then bring the develop to it, solve conflicts and then get back to release with a pull request.

     release -> merge-branch (creating merge-branch from release)
 develop -> merge-branch (pull from develop to merge-branch in order to solve conflicts)
 merge-branch -> release (opening the pull request)

My question is:

Are there any differences in the final result between those two approaches?

meJustAndrew
  • 6,011
  • 8
  • 50
  • 76
  • Though both should yield the same result, if the conflict resolution is done correctly, I would still favor the first option. Makes it *slightly* more clear where changes are coming from. Difference is minor though. You might also try to question that company-policy. It seems all it does is hide the conflict resolution in an intermediate branch? Or is there another reason not directly merge to release? – FloWil Mar 16 '21 at 09:15
  • 1
    There is no difference in *content* but there is a difference in first-parent-history. For the content part, see [my answer](https://stackoverflow.com/a/42104116/1256452) to [this question](https://stackoverflow.com/q/42099431/1256452). – torek Mar 16 '21 at 17:08

1 Answers1

1

As long as you do the conflict resolution correctly, there should be no difference between either approach in the final release branch.

There is also another option, which is to rebase develop on top of release. This would require you to solve your conflicts. Then you can easily merge develop into release without a temporary branch in the middle.

mnestorov
  • 4,116
  • 2
  • 14
  • 24
  • I can not rebase develop on top of release, as I have to create a pull request. But for the first part, I agree with you, I think there should be no difference. – meJustAndrew Mar 16 '21 at 13:25
  • You can still create a pull request afterwards. Once you rebase and fix-up the conflicts, nothing is stopping you from making a PR towards `release` from `develop`. – mnestorov Mar 16 '21 at 13:56
  • yes, but this way the code from release will go to develop, and this is something that I have to avoid. So it's one of the two approaches presented in the question. Do you have any reference for which it's safe to say that they are equivalent? – meJustAndrew Mar 16 '21 at 14:16
  • I don't have a reference, but we can follow the logic that since the intermediate `merge-branch` would have both `develop` and `release` changes, it won't make a practical difference once it's merged into `release`. The only thing that might be of consideration is who is the parent of this temporary branch. As stated in the comments, one might argue that basing yourself off of `develop` into `temp` then into `release` would convey your intentions clearer. – mnestorov Mar 16 '21 at 14:23
  • As a reference, I would say that the git documentation on merging and branching would give you the best "proof" that you would be fine in both cases :) – mnestorov Mar 16 '21 at 14:25