Resolve Conflicts

# Conflict Resolution Patterns

This document provides detailed patterns for resolving specific types of conflicts.

**Important**: For each conflict you resolve, provide a one-line explanation of your resolution strategy. When the correct resolution isn't clear from the diff, present numbered options to the user.

## Import Conflicts

When both branches modify import statements, merge both sets of imports:

### Pattern: Combine and Deduplicate

```
<<<<<<< HEAD
import { foo, bar } from './module';
import { baz } from './other';
=======
import { foo, qux } from './module';
import { newThing } from './another';
>>>>>>> branch
```

**Resolution:** Merge all unique imports, group by module:

```
import { foo, bar, qux } from './module';
import { baz } from './other';
import { newThing } from './another';
```

### Rust Imports

```
<<<<<<< HEAD
use std::collections::HashMap;
use crate::domain::User;
=======
use std::collections::HashSet;
use crate::domain::Account;
>>>>>>> branch
```

**Resolution:**

```
use std::collections::{HashMap, HashSet};
use crate::domain::{Account, User};
```

**Key principles:**
- Combine all unique imports
- Remove duplicates
- Follow language-specific style (group by module, alphabetize)
- Preserve any re-exports or aliases from both sides

**One-line explanation example**: "Merging imports by combining unique imports from both branches and grouping by module."

## Test Conflicts

Tests should almost always include both changes, as tests are additive.

### Pattern: Merge Test Cases

```
<<<<<<< HEAD
#[test]
fn test_user_creation() { ... }

#[test]
fn test_user_validation() { ... }
=======
#[test]
fn test_user_creation() { ... }

#[test]
fn test_user_deletion() { ... }
>>>>>>> branch
```

**Resolution:** Include all tests (assuming test_user_creation is identical):

```
#[test]
fn test_user_creation() { ... }

#[test]
fn test_user_validation() { ... }

#[test]
fn test_user_deletion() { ... }
```

### Test Setup/Fixtures Conflicts

When both branches modify test fixtures, merge the changes:

```
<<<<<<< HEAD
fn setup() -> TestContext {
    TestContext {
        user: create_test_user(),
        admin: create_admin(),
    }
}
=======
fn setup() -> TestContext {
    TestContext {
        user: create_test_user(),
        database: init_test_db(),
    }
}
>>>>>>> branch
```

**Resolution:**

```
fn setup() -> TestContext {
    TestContext {
        user: create_test_user(),
        admin: create_admin(),
        database: init_test_db(),
    }
}
```

**Key principles:**
- Keep all test cases unless they test the exact same thing
- Merge test fixtures and setup functions
- If test names conflict but test different things, rename one
- Preserve all assertions from both sides

**One-line explanation example**: "Including all test cases from both branches and merging test fixtures."

## Lock File Conflicts

Lock files (Cargo.lock, package-lock.json, yarn.lock, etc.) should be regenerated rather than manually resolved.

### Pattern: Regenerate Lock File

```bash
# For Cargo.lock
git checkout --theirs Cargo.lock  # or --ours, either works
cargo update  # or cargo build

# For package-lock.json
git checkout --theirs package-lock.json
npm install

# For yarn.lock
git checkout --theirs yarn.lock
yarn install

# For Gemfile.lock
git checkout --theirs Gemfile.lock
bundle install

# For poetry.lock
git checkout --theirs poetry.lock
poetry lock --no-update
```

**Key principles:**
- Always regenerate, never manually merge
- Choose either version (--ours or --theirs), doesn't matter
- Run the package manager's update/install command
- The result will include dependencies from both branches

**One-line explanation example**: "Regenerating lock file with package manager to include dependencies from both branches."

## Configuration File Conflicts

Configuration files often need careful merging of both changes.

### Pattern: Merge Configuration Values

```yaml
<<<<<<< HEAD
server:
  port: 8080
  timeout: 30
  max_connectio