nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Why merge from destination branch to source branch and not vice versa?

SaSa_2wcbt1

This question is in reference to Atlassian Documentation: Resolve merge conflicts

I don't understand why the destination branch is merged into the source branch.

In my example I have a repo "testproject" and forked it to "testfork". No "fork sync" (because I don't want to have every change in my fork).

After a change in "testproject/develop" I made a pull request "testproject/develop" -> "testfork/develop" in order to get this change to my fork. As a file was changed in both repos there were merge conflicts and Stash reported me to resolve the conflicts.

The instruction from stash said to fetch changes from destination, to checkout source and merge the changes from destination into source (with resolving conflicts), commit and push. This means that "testfork/develop" is merged into "testproject/develop" but I want it vice versa. So the instruction was false to me.

Accepted answers

Tim Crall1

The idea is that you would merge the destination branch into the source branch, resolve the conflicts in the source branch, and then re-issue the Pull Request which can now work because there are no longer conflicts. A lot of people would use rebase for this instead of merge because it produces a cleaner graph, but you can only do that if you're merging a private branch that no one else is working on.

If you merged the source into the destination locally and resolved the conflicts then there would no longer be a need for a Pull Request because you would have already done what it would do. You could just fix the conflicts and push back to the destination. Which is fine, too, but loses the advantage of using the Pull Request in the first place.

All comments

Rich Duncan

A pull request typically goes in the opposite direction. Since the repo you are forking is considered the official repo (testproject), Your fork (testfork) is where you would make (say feature) changes. When those are ready, you would create a pull request - requesting the owners of the official repo to pull in your changes after they are reviewed and approved. Changes in the other direction would presumably be under your control already and can be done simply buy pulling them from testproject and merging them to testfork.

Have a look at the excellent Atlassian documentation on Git/Bitbucket workflows: https://www.atlassian.com/git/tutorials/

SaSa_2wcbt1

Normally we have a workflow similar to git flow. But in a project we have client specific versions:

We have the official repo (testproject) and forks for different clients, e.g. different css-files, different databases in the backend, sometimes different features.

Example:

In the official repo I update several libs, make some commits and I want to have this changes in all forks.I thought it would be easier to do this with a pull request in the fork repo to have a summary of all the commits and to have merged it automatically when there are no conflicts.

How would you do that? Setting official repo as upstream?

Another Example:

I have developed a new feature in fork 'A'. I'd like to have it in fork 'B' too, but not in fork 'C'. How would you do that?

Tim Crall1

Rich Duncan

In reading your original post plus the follow-up, the first issue was the documentation fit the more traditional usage, which I was hoping to point out. Using forks for different clients seems like a reasonable idea - certainly you can pull changes from the 'common' repo into any of the client-specific forks. Doing pull requests from common to client should work.

You could even investigate using a feature branch workflow where features are delivered to the common repo and then selectively to the forks.

SaSa_2wcbt1

I'd like to have added your comment to the documentation (before the git instructions) to make it clearer:

"The idea is that you would merge the destination branch into the source branch, resolve the conflicts in the source branch, and then re-issue the Pull Request which can now work because there are no longer conflicts."

Brameshmadhav S1

Here is my doubt on this, though. Every feature branch created at time x, becomes the single source of truth about that feature. By merging the development branch into the feature branch, am I not polluting that feature branch to have other features ? That way I am not maintaining a place where that feature is working individually. Any common bug introduced and not detected in my development branch is now on the feature branch as well.

Tim Crall1

If you're concerned about that, an alternative is to create a conflict_resolution branch off of develop, merge into that, resolve conflicts there, and then PR it into develop.

I don't really see the issue, though. Your feature branch will always contain code from other features that were complete before you began working on it. Merging (or rebasing) develop into it before merging just means it will also contain code for features that were completed while you were working on it. They should only be complete, tested features.

Also in GitFlow we typically delete feature branches after merging, anyway.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

bitbucket-server

merge-conflict