Git Separate Tangled Changes Into PRs

Separating Tangled Changes into Clean PRs

Problem

A working tree accumulates uncommitted changes from multiple features over time. When you need to create focused PRs, the changes are tangled together — some files have changes from multiple features, generated files (like .mocks.dart) reflect all features combined, and pre-commit hooks fail on unrelated WIP code.

Context / Trigger Conditions

• Working tree has 50+ modified/untracked files spanning multiple features
• git diff --name-only shows files from clearly different features
• You need to create a PR for Feature A but Feature B's files cause analysis errors
• Pre-commit hooks run dart analyze / eslint / etc. on ALL files (not just staged), so untracked WIP files block commits
• Some files have changes from BOTH features (mixed-change files)

Solution

Step 1: Stash Everything Safely

git stash -u -m "descriptive-name-for-safety"

The -u flag includes untracked files. This is your safety net.

Step 2: Create Clean Feature Branch

git checkout main  # or the appropriate base
git pull
git checkout -b feature/clean-branch

Step 3: Pop Stash and Handle Conflicts

git stash pop

Common issue: "already exists, no checkout" — happens when untracked files from the stash already exist in the working tree. The tracked file changes still apply, but the stash is preserved (not dropped). This is safe; the files you need are already there.

Merge conflicts: Resolve each one. For files belonging to OTHER features, take the base version:

git checkout --theirs path/to/other-feature-file.dart

For files belonging to THIS feature, take the stash version or resolve manually.

Step 4: Handle Mixed-Change Files

Some files have changes from BOTH features. For these:

1. Restore to the base version: git checkout main -- path/to/file.dart
2. Re-apply ONLY your feature's changes manually (usually just import changes or a few lines)

Step 5: Deal with Pre-Commit Hooks That Check All Files

If your pre-commit hook analyzes ALL files (not just staged), untracked WIP files from other features will block your commit.

Workaround: Temporarily move problematic untracked files:

mkdir -p /tmp/other-features-backup
mv lib/unrelated_feature/ /tmp/other-features-backup/
mv test/unrelated_feature/ /tmp/other-features-backup/

Commit, then restore:

cp -r /tmp/other-features-backup/* .

Step 6: Regenerate Generated Files

If the project uses code generation (Mockito, Riverpod, Freezed, etc.), restore generated files to base and regenerate:

git checkout main -- **/*.mocks.dart **/*.g.dart
dart run build_runner build --delete-conflicting-outputs

This ensures generated files only reflect YOUR feature's changes.

Step 7: Fix Interface Break Cascades

When Feature A changes an interface (renames a method, changes parameter types), consumer files that weren't modified by Feature A will break. The analyzer catches these. Fix them before committing.

Common pattern:

• Provider state changed CompleteParameters? to Map<String, dynamic>
• Canvas widget still calls .colorFilters on what's now a Map
• Fix: Update the consumer to use the new interface

Step 8: Do NOT Stack PRs — Combine Dependent Features Into One PR

Never create a PR that targets another PR's branch instead of main. Stacked PRs cause real problems in this project: rebases cascade, reviewer context fragments, merge order becomes load-bearing, CI runs against the wrong base, and "fix on parent" forces a re-review of the child.

If Feature B depends on Feature A, ship them as ONE combined PR.

# Both features live on a single branch, targeting main
git checkout main && git pull
git checkout -b feature-a-and-b
# ... commit Feature A changes ...
# ... commit Feature B changes (separate commits are fine) ...
gh pr create --base main  # one PR, both features

Write the PR description so the two features are clearly delineated — separate sections, separate test plans. Reviewers can read it as a single unit, and the merge story is one click. This is the default when changes are interdependent.

The only time to split is when the features are truly independent — in which case they each get their own PR targeting main, in any order. If you find yourself wanting "B based on A," that's the signal to combine them, not to stack.