Stash gives these directions to solve a PR merge conflict
Step 1: Fetch the changes (saving the target branch as FETCH_HEAD).
Step 2: Checkout the source branch and merge in the changes from the target branch. Resolve conflicts.
This is where I'm confused. Is this not affecting the contents of my source branch?. I don't want to merge my target into my source, this can create all kind of problems for me. What am I missing?
In current versions of Stash there are some scenarios (such as when creating a pull request from an older release branches to a newer one) where the instructions can be incorrect, because following them would result in a reverse merge. This is being fixed in Stash 3.6.0 (https://jira.atlassian.com/browse/STASH-5443). So if that's the scenario that you're referring to then, yes, caution is required. In this case you would probably need to manually do the pull request merge locally (ie. merge source into target), fix the conflicts on the target, and push the changes up. Stash would detect this pull request as merged.
However in the general case, say your source branch is "my-fix" and the target branch is "master", and your source branch is branched from your target branch, then a reasonable approach to avoiding merge conflicts when merging "my-fix" into "master" is to pre-empt them by merging the latest changes on "master" into "my-fix" first, and fixing the conflicts there. Then "my-fix" should merge cleanly into "master". This is effectively what Stash's instructions have you do.
Bitbucket Pipelines helps me manage and automate a number of serverless deployments to AWS Lambda and this is how I do it. I'm building Node.js Lambda functions using node-lambda ...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
We're bringing product updates and pro tips on teamwork to ten cities around the world.Save your spot