--- Context:
Conflicting merges must be solved by developers.
All developers are part of the same company on several sites.
A merge leads to a lot of conflicts involving several developers (for ex. During N -> N+1 synchronization while N and N+1 project versions are running in the same repository)
--- Here is my solution:
• All the conflicts are managed in a clone, merging_clone
• This clone is shared at OS level
• Developers of remote sites can connect to a local LAN Git machine to access merging_clone
1. The merge is started
2. Merges are detected and the integration team advises developers in charge of these pieces of code
3. The integration team gives tokens to avoid access conflicts on merging_clone
4. Each developer starts git mergetool, solves his conflicts, and frees his token.
In my case developers don’t control their merge: the merge is started by integrators between 2 integration branches.
For ex. During vN -> vN+1 synchronization.
We could go deeper into details into branching model:
Case1: vN and vN+1 projects are running in the same repository.
Case2: vN and vN+1 projects are running in the different repositories, then vN pushes (trivial merge) into incoming branch in vN+1, then merge to vN+1 integration branch.
In all cases, I have to face a bunch of merge conflicts involving several developers.
CMCrossroads is a TechWell community.
Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.
