How could it be possible that the bitbucket merge pull request action removes code which was committed/merged from another branch?

Viewed 816

How could it be possible that the bitbucket merge pull request action removes code which was committed/merged from another branch? We're working with a bitbucket repository, sourcetree, and also the bitbucket web interface in this case.

Structure:

Develop
|
|- Branch A (main feature branch)
|  |
|  |- Branch B (1st sub feature branch, under branch A)
|  |
|  |- Branch C (2nd sub feature branch, under branch A)
|  |

Our problem was that when a developer merged his pull request from Branch C (which was made with Branch A as target) that code from branch B (which was merged earlier in branch A) was removed in the process. The removal of the files was visible in the merge commit. The pull request merge was done with the Bitbucket web interface.

Before merging a sub feature branch in the main feature we always merge the main feature branch in the sub feature so the conflicts are to be solved in the same way.

Hence the flow was as follows:

  • Merge Branch A into Branch B (to bring B up-to-date with its parent A) (with sourcetree)
  • Merge Branch B into Branch A (to finish the B branch)
  • Merge Branch A into Branch C (to bring C up-to-date with its parent A) (with sourcetree)
  • Merge Branch C into Branch A (to finish the C branch) (with bitbucket web interface, merging the pull request)

Normally we do nog merge pull requests with the web interface of bitbucket (if they're not against the develop branch, that is), we normally do those merges manually in sourcetree.

It seems like somehow the merge pull request action on the bitbucket site reverted some of the other, earlier merged code. (It also did not look like a full revert commit, but only about 95% of the code of the other branch was reverted/removed.)

Any ideas or tips as to how this may happen?

2 Answers

Before merging a sub feature branch in the main feature we always merge the main feature branch in the sub feature so the conflicts are to be solved in the same way.

A better practice would be to rebase your feature branch on top of the target branch.

That way:

  • the PR is resolved with a trivial merge
  • previous merges are not removed

I believe the problem could have happened between these two steps: Merge Branch B into Branch A (to finish the B branch) Merge Branch A into Branch C (to bring C up-to-date with its parent A) (with sourcetree)

the Branch A used in the second step might not have been latest that was updated with Branch B merge in the step above it. A local pull must have been missed which would have caused this kind of a behaviour.

Related