We are using Code Repositories to create the following branch configuration.
■master → dev → member-A, member-B
Multiple developers create their own branches from the dev branch
and create pull requests to dev and merge as soon as development is finished.
Then, at regular intervals, pull requests are created from dev to master and merged.
There are no exceptions to this method, and merges are only performed from dev to master,
but when we create a pull request to master, for some reason a conflict occurs between the module that was merged last time and the module that is being merged this time
and we have to manually resolve the conflict every time.
I don’t know why differences are appearing, so does anyone know the cause of the issue or a solution?
Hey @CC-sekito
If a user’s (A) current branch contains changes to a section (S1) in file (F1) and that section (S1) has been updated in the master by another user (B) after user A created their branch, then when user A raises a pull request to master, it is bound to have conflicts with the changes in the master. This is because, user A is trying to update a section that has already been updated by user B and user A’s branch doesn’t know those changes. This wouldn’t be a problem if user B updated some other file F2 and user A is updating F1.
To resolve this, user A should always pull the latest changes from master into their branch so that their branch is always in sync with master. This can be done be selecting the Merge option while on your branch and selecting master in the dropdown.
Even in this case, user A would receive conflicts because the git is trying to decide between 2 changes in the same section and doesn’t know which one to keep and which one to discard. User A should then manually delete the changes they don’t need and commit the ones they need.
Hope this helps!
If the setup is exactly as you described (with no pull requests created against master except from the long-lived dev branch), I can only think of two situations where a merge conflict would be expected on a pull request between the long-lived dev branch and master.
- The merge conflicts are occurring in conda lock files as a consequence of those files being separately modified on master due to automatically generated and merged repository upgrade pull requests.
- The merge conflicts are occurring in the
transforms-shrinkwrap.ymlfile due to the presence of dynamic transform generation logic that references the current date or time. Depending on the timing of creation and merging of previous pull requests, this might introduce changes onmasterthat are out of sync with the state ofdevand lead to merge conflicts on subsequent pull requests (transforms-shrinkwrap.ymlis automatically updated as part of CI checks).
The second one of these is a marginal edge case and represents an implementation pattern that is not recommended, but I’m listing it here in the interest of completeness.
Note that both conda lock files and transforms-shrinkwrap.yml are “hidden” files that will only be shown if you toggle the “Show hidden files” setting in the repository file browser.
Does either of the above match what you are seeing? If not, it would be helpful if you could explain in which specific files the merge conflicts are occurring (user-written files? automatically generated files?) and what the nature of the conflicts is.
The problem appears because the merge commit created on the master branch doesn’t exist on the dev branch. To avoid this use exclusively “Merge with fast forward”, you can enforce that in the repository settings. That way no merge commit gets created and there is no conflict to resolve.
Thank you everyone for your replies.
I was able to confirm that Matija’s answer eliminated most of the differences.
I’ll keep an eye on it for a while, but as the problem is almost solved I’ll select Matija’s answer as the solution.