Merge Strategies

Pattern 1: Direct Integration

All implementers commit to the same branch; integration happens naturally.

When to use: Small teams (2-3), strict file ownership (no conflicts expected).

Pattern 2: Sub-Branch Integration

Each implementer works on a sub-branch; lead merges them sequentially.

Merge order: follow dependency graph (foundation → dependent → integration).

When to use: Larger teams (4+), overlapping concerns, need for review gates.

Pattern 3: Trunk-Based with Feature Flags

All implementers commit to the main branch behind a feature flag.

When to use: CI/CD environments, short-lived features, continuous deployment.

Integration Verification Checklist

After all implementers complete:

1. Build check: Does the code compile/bundle without errors?
2. Type check: Do TypeScript/type annotations pass?
3. Lint check: Does the code pass linting rules?
4. Unit tests: Do all unit tests pass?
5. Integration tests: Do cross-component tests pass?
6. Interface verification: Do all interface contracts match their implementations?

Conflict Resolution

Prevention (Best)

• Strict file ownership eliminates most conflicts
• Interface contracts define boundaries before implementation
• Shared type files are owned by the lead and modified sequentially

Detection

• Git merge will report conflicts if they occur
• TypeScript/lint errors indicate interface mismatches
• Test failures indicate behavioral conflicts

Resolution Strategies

1. Contract wins: If code doesn’t match the interface contract, the code is wrong
2. Lead arbitrates: The team lead decides which implementation to keep
3. Tests decide: The implementation that passes tests is correct
4. Merge manually: For complex conflicts, the lead merges by hand