Suppose I have two branches, master and release/2.0, and I want to merge the release branch into master.
I do a pull request to merge release/2.0 to master, but, after the pull request has been done, I discover that there is a conflict (for example, application's version within the main POM).
How can I solve the conflict? Is the previous one (direct pull request in BitBucket) the right approach, or I have to perform the merge in my local environment and then make the pull request? In this case, which are the steps to perform?
Thanks in advance.
You have two options to resolve the conflict:
1) Resolve them without a pull request.
To do this, you would checkout the master branch, and then pull in the release branch. This is effectively the solution that Bitbucket Server give you when you ask for more information on how to solve the conflict.
git checkout master git pull origin release/2 <resolve merge conflicts> git push
2) Resolve them with a pull request
To do this, you would create a branch off the tip of
master, pull in the release branch and create a pull request from that branch to master. This is the best option if you don't have permission to push directly to master.
git checkout master git checkout -b resolve-conflicts-branch git pull origin release/2 <resolve merge conflicts> git push -u origin resolve-conflicts-branch <create pull request>
Note: Once you have resolve the conflicts through either of these methods, your old pull request from
master will be closed automatically since there will no longer be any diff.
perform the merge in reverse locally, merging master into release/2
git checkout release/2 git merge master
then manually resolve any conflicts, commit and push
git commit git push
Your pull request should automatically update itself to the new commit and there are no longer any conflicts (because you just resolved them all)
You could also use a rebase instead of a merge. This gives a cleaner look to your history, at the cost of a little bit of historical accuracy. Many people think that's a good deal.
git checkout release/2 git rebase master <resolve conflicts manually> git push
As before, your Pull Request should now be mergeable
True. I was kind of assuming you'd be deleting the release branch after merging it into master.
In GitFlow branching strategy, a release branch should usually be deleted (or at least abandoned) after the release was finalized, which is when you would merge it back into master.
We've developed a plugin, Power Editor for Bitbucket, that allows you to resolve conflicts on a pull request in the UI. You won't need to go through any of the git commands anymore (even though we highly recommend you learn them, they can be quite useful). You can check out out here.
It also supports:
If you run git rebase origin/master what is actually happening is that commits that were added to JohnMaster are rewritten (in your case two commits) and put after those from master. E.g. since JohnMaster branch was created B and C have been added to master and B' and C' have been added to JohnMaster. After rebasing you get A --> B --> C --> B'' --> C''. Before the rebase you had A --> B' --> C' on your feature branch and you still have it on the remote branch before pushing. At this point Git tells you that you don't have locally B' and C' because they have been rewritten to B'' and C'', therefore different commits.
Badges are a great way to show off community activity, whether you’re a newbie or a Champion.Learn more
Hi Community, I'm Julia and I'm on the Jira Software Cloud marketing team! We're looking for companies or teams using Bitbucket Cloud and Jira Software Cloud. If your team fits the t...
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
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs