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.
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.
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."
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.
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.
Assuming you are attempting to keep your target branch (develop or master) deliverable-ish in the continuous delivery sense. The feature branch is the 'single source of truth' as you say. All of teh changes on this branch are based off of the current state of the target branch at the time the work was started. Since they other features (and bug fixes and hot fixes) may have been 'delivered' to the target branch. Now, your feature is essentially out-of-date with the work that has been delivered to date. Hence you need to merge in the changes on the target, (or rebase but that's another topic) an make the necessary changes to ensure that your feature works correctly given the current state of what has been delivered.
I second the doubt about merging destination into source for resolving a merge conflict and before merging back into develop:
For feature branches this may be fine, but for merging the release-branches into develop this is no-go!
We are starting to adopt GitFlow. I just wanted to merge back changes from our release-branch into the develop-branch. This is suggested in GitFlow in order to merge back bugfixes that were added to the release-branch (https://nvie.com/posts/a-successful-git-branching-model/).
In this case it is completetly unacceptable to merge from destination (develop) into source (the release-branch) for fixing merge-conflicts.
So in this case I will always have to use a conflict_resolution branch as suggested by Tim Crall?! There is no other way, correct?
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/
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.
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?
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?
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.
Announced in this blog, this holiday season we’re celebrating all things CI/CD and between now and the end of 2019 we’ll be showcasing content, use cases, feature announcements and more. One featur...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events