How to resolve conflicts in bitbucket when multiple developers r wrking to merge changes to mainline

[Ripunjay Godhani]

How to resolve conflicts in bitbucket git when multiple developers are working to merge changes to mainline

I have a situation where in i have below scenario

there is a mainline branch in bitbucket , every developer creates a branch out of this mainline and works on it , once developer finishes his code development in dev branch he syncs code from mainline and again run CI process to test if all is fine after taking latest code from mainline once build passes including the sanity then code from dev branch is merged to mainline

problem statement:
step 1 : Developer X creates development branch called (X_DEV) from mainline (ML)
step 2: Once developer X completes his development , he takes latest code from mainline ML and sync it to X_DEV branch and
step 3: now Developer X runs build and sanity and after sanity he merges code to mainline ML

But when developer X was running sanity of code in step 3 , then another developer named 'Y' created new development branch called ( Y_DEV ) from mainline
After creating new development branch Y_DEV , developer writes his code and test it and after testing in dev branch then he copies new latest code from mainline ( at this time changes of developer X were not yet present in ML mainline)

after developer Y copies new latest code from mainline he again runs build and sanity , after sanity his code fails to get merged with mainline becuase new code was copied to ML by developer X and that code was not present in branch Y_DEV of developer Y

so how to handle these issues without adding wait/sleep or waiting for X_Dev code to get synced to ML or having each functionality to have its own SDLC

[Mike Friedrich]

This has nothing to do with Bitbucket, but more with how you define the workflow. 

With parallel development you will get conflicts from time to time and the one who merges first will cause others to merge and build again, unless you accept to risk broken branches. You cannot avoid this. 

The only advise I can give is, you should design your project in a way that minimizes potential conflicts. 

[Julius Davies _bit-booster_com_]

I agree with Mike Friedrich:  if your developers are constantly stepping on each other's toes, something is wrong with the way new work is being distributed among your team.

If you were a blueberry farmer with 20 workers, you would not have them all pick blueberries in the same row.

Nonetheless, eliminating Step 2 from the process should reduce contention.  Setup a CI server like Jenkins to always build master in the background after the merge, instead of having a developer do that before they merge.   If their feature branch already built successfully once, that's typically good enough.  And if Jenkins or Bamboo fails to build after the merge, those CI servers are good at automatically emailing the guilty developer.