We are trying to use CodeCommit and CodeBuild to implement a process by which when a developer creates a pull request to merge changes from his/her branch, rather than merging into master, he/she requests the changes be merged into an integration branch. Before the merge, the integration and master branches reference the same commit id. After the merge of the developer's changes into the integration branch, integration is now ahead of master and the corresponding CodeBuild job builds the integration branch. Once all the unit and integration tests have been verified, the integration branch is then merged into master branch and integration and master will once again reference the same commit id.
What I have observed is that when I execute a merge-pull-request-by-three-way (cli) specifying the pull request that was created to merge from the developer branch into integration, the end result is that the code is merged into both the integration and master branches. Unlike merge-branches-by-three-way, merge-pull-request-by-three-way does not give you an option to specify the target branch, but it shouldn't since the pull request already specifies the target branch into which changes are to be merged. It is unclear to me if this is happening because the commit id's are the same and the merge is doing it based on that, or if CodeCommit thinks master is the "current" branch (referring to the git-merge behavior), but regardless, the result was not what I was expecting.
Is this behavior of ignoring the pull requests target branch when merging using merge-branches-by-three-way, a bug or is this expected behavior/"feature" of merge-pull-request-by-three-way (and possibly the other merge-pull-request-* commands) and I should instead use merge-branches-by-three-way.
AWS OFFICIALUpdated a year ago
