Git Branching, Rebase, and Merge Conflicts

Pathrule2 Rules • 2 Memories

Git conflicts are semantic integration decisions disguised as text edits. Rebasing or merging without understanding both sides can produce code that compiles while deleting a migration, duplicating a registration, or restoring behavior one branch intentionally removed. This pattern constrains history rewriting and conflict resolution while recording branch lifetime and integration-strategy decisions. It complements conventional commits by focusing on how divergent work is combined and recovered, not on commit-message syntax or automated release metadata.

Suggested path map

Pathrule places each piece on the matching path, so your assistant only sees it where it belongs. This is the scoping you get on import; you can adjust it in your workspace.

/ workspace root

Rewrite only history you own

Branch lifetime determines integration strategy

src/

Resolve conflicts from both changes' intent

migrations/

Ordered artifacts require domain-aware conflict policy

Rules

Rewrite only history you own/roothighstrictRebase and force-update private branches with a reviewed remote base; merge shared history unless owners coordinate a rewrite.

1	Rebase creates new commit identities. Rewriting a branch used by other people or automation disconnects their history and makes a normal push look like data loss.
2
3	- Fetch the remote and inspect branch divergence before rebase, merge, reset, or force update.
4	- Use rebase for local or explicitly private commits and communicate before rewriting a branch another person or deployment consumes.
5	- When a rewritten branch must update remote, use a lease tied to the observed remote state rather than an unconditional force push.
6	- Create or retain a recovery reference before complex history surgery and know how to find prior tips through reflog or the hosting platform.
7
8	See /src for the adjacent decision or procedure that completes this constraint.

Resolve conflicts from both changes' intent/srchighstrictRead base, ours, theirs, surrounding code, tests, and related files before composing the integrated result.

1	Conflict markers show overlapping text, not the complete semantic conflict. One side may depend on a schema, registration, API, or invariant changed elsewhere without a textual overlap.
2
3	- Identify what each branch intended and which assumptions changed since the common base.
4	- Resolve by composing behavior and deleting obsolete paths, not by mechanically choosing all of one side or concatenating both.
5	- Search for related symbols, registrations, configuration, tests, and documentation that must agree with the resolution.
6	- Run focused tests and inspect the staged diff without conflict markers, accidental debug code, duplicate imports, or unrelated formatting churn.
7
8	See /migrations for the adjacent decision or procedure that completes this constraint.

Memories

Ordered artifacts require domain-aware conflict policy/migrationsMigrations, lockfiles, snapshots, and generated indexes are resolved through their source and ordering model, not as ordinary prose.

1	Some files encode a sequence or are derived from another source. A textual merge can look valid while creating duplicate migration order, inconsistent dependencies, or output that the generator immediately rewrites.
2
3	- Preserve every independently shipped migration and create a new reconciliation migration when both branches changed the same schema assumption.
4	- Regenerate lockfiles, code, snapshots, catalogs, and manifests from the merged authoritative sources using the pinned toolchain.
5	- Do not renumber or edit an already applied migration merely to remove a filename conflict.
6	- Review generated diffs for unexpected dependency, ordering, schema, or content loss instead of assuming regeneration is automatically correct.
7
8	See /src for the rule or workflow that puts this decision into practice.

Branch lifetime determines integration strategy/rootKeep short-lived changes near the target branch and give long-running work explicit synchronization, ownership, and release boundaries.

1	A branch that diverges for weeks accumulates conflicts in code and product assumptions. No Git command can make that integration cheap after the fact.
2
3	- Split work into independently reviewable changes that can merge behind compatibility layers or feature controls.
4	- Update from the target branch regularly while the branch is private and resolve conflicts near the change that introduced them.
5	- Use merge commits where preserving a shared integration event matters and rebase where a private linear series improves review.
6	- Delete merged branches after verifying the intended commit reached the target; branch names are collaboration handles, not durable release records.
7
8	See /src for the rule or workflow that puts this decision into practice.

Why this pattern

AI agents often choose one conflict side mechanically, force-push over new remote work, rebase a shared branch, or resolve generated output without updating its source.

Built for Engineering teams integrating concurrent code, migrations, generated artifacts, releases, and long-running feature work.

Keeps your assistant from:

Overwriting a teammate's remote commit during force push
Dropping intent by accepting ours or theirs wholesale
Rewriting history other people have based work on
Committing a generated conflict fix that no source can reproduce

View as markdown

License: Apache-2.0
Version: 1.0.0
Updated: 2026-08-25