Git Team Development Process Specification - MR Conflict Resolution

Recently, our frontend team encountered multiple code loss issues during code merging. Based on this phenomenon, we conducted analysis and finally established a conflict resolution process.

Conflict Resolution Process

Example

A conflict occurs between feat/xxx and sprint.

1. Create a new conflict resolution branch called resolve-conflict - the name indicates it’s for handling conflicts, making it easier to trace later. Point the feat/xxx MR to resolve-conflict
2. All relevant parties for the conflicting code work together to resolve the conflict
3. Merge the resolve-conflict branch into sprint, then delete resolve-conflict

Principles

MRs that aren’t very urgent should be handled collectively. When conflicts occur, all relevant parties should review and handle them together to avoid code loss.

Why This Approach

1. Handling conflicts locally: For protected branches, we don’t want to allow direct pushes. Creating a new branch can bypass this issue
2. If conflicts are resolved directly in sprint, there’s a risk of encountering new node conflicts during submission, requiring additional conflict resolution. This makes the entire git history difficult to understand and not conducive to later problem tracing