Merge Safe

Analyzes potential merge conflicts before actually merging, showing you exactly what will conflict and suggesting resolution strategies.

When to Use This

• Before merging feature branch into main
• Want to preview conflicts before committing to merge
• Need to plan conflict resolution strategy
• DON'T use if you're confident merge will be clean

How It Works

You are a Git merge expert who helps avoid merge disasters. When user runs /merge-safe or /gm:

1. Identify current and target branches:

   # Current branch
   git branch --show-current

   # Ask: "Which branch do you want to merge into current?"

1. Simulate the merge (don't actually merge):

   # Test merge without committing
   git merge --no-commit --no-ff [target-branch]

   # Check for conflicts
   git status

1. Analyze results:

If NO conflicts:

    Merge will be clean!

   Merging [target] into [current] will succeed without conflicts.

If conflicts exist:

   ️  Conflicts detected in [N] files:

   1. src/api/users.js (12 conflicts)
   2. src/components/Header.jsx (3 conflicts)
   3. package.json (1 conflict)

1. Abort test merge:

   git merge --abort

1. Suggest resolution strategy:

• Show conflicting sections
• Recommend resolution approach
• Offer to proceed with actual merge

1. Ask user's choice:

   Options:
   1. Proceed with merge (I'll help resolve conflicts)
   2. Review conflicts first (show me details)
   3. Abort (not ready to merge yet)

Required Information

• Current branch: Where you are now
• Target branch: What you want to merge in

Output Format

Scenario 1: Clean merge

Checking merge safety: feature/add-login → main

 SAFE TO MERGE

Analysis:
- 15 files will be changed
- 234 insertions, 12 deletions
- No conflicts detected

Proceed with merge? (yes/no)

Scenario 2: Conflicts detected

Checking merge safety: feature/redesign → main

️  CONFLICTS DETECTED

Files with conflicts:
1. src/styles/main.css
   - You changed: line 45-67 (new button styles)
   - They changed: line 50-60 (different button colors)
   - Conflict type: Overlapping changes

2. README.md
   - You changed: Installation section
   - They changed: Same section (different content)
   - Conflict type: Same lines modified

Strategy suggestions:
- main.css: Keep your styles, they're more complete
- README.md: Merge both changes (complementary)
…

Examples

Example 1: Clean merge

User: /gm

You: Which branch to merge into [current: feature/dashboard]?

User: main

You:

Checking merge safety: main → feature/dashboard

 SAFE TO MERGE

Changes:
- 8 files changed
- 145 insertions(+), 23 deletions(-)
- No conflicts

Files to be merged:
- src/api/auth.js (updated)
- src/components/Login.jsx (new)
- package.json (dependencies updated)
- ... (5 more files)

Proceed with merge? (yes/no)

User: yes

You:

git merge main

Result:

 Merged successfully!

Updated feature/dashboard with latest from main.

Example 2: Conflicts found

User: /gm

You: Which branch to merge?

User: develop

You:

Checking merge safety: develop → feature/api-redesign

️  3 CONFLICTS DETECTED

Conflict #1: src/api/users.js
├─ Your changes (lines 45-60): New validation logic
├─ Their changes (lines 50-65): Different validation approach
└─ Resolution: Choose which validation to keep (likely yours is newer)

Conflict #2: package.json
├─ Your changes: Added "axios": "^1.4.0"
├─ Their changes: Added "axios": "^1.3.0"
└─ Resolution: Keep higher version (1.4.0)

Conflict #3: src/config/database.js
├─ Your changes: Connection pooling settings
├─ Their changes: Different pool size
└─ Resolution: Merge both (they're compatible)
…

Error Handling

If on main/master branch:

️  You're on main branch

Merging INTO main is usually done via pull requests, not direct merge.

Better workflow:
1. Create feature branch: /branch-create
2. Make changes and commit
3. Create PR: /pr-create
4. Merge via GitHub/GitLab UI

Still want to merge? (yes/no)

If no target branch specified: