# Pathrule Pattern: Git Branching, Rebase, and Merge Conflicts (1.0.0)
# ::pathrule:package:git-branching-rebase

### [RULE] Rewrite only history you own  (path: /)
<!-- scope: project | priority: high | strict -->

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.

- Fetch the remote and inspect branch divergence before rebase, merge, reset, or force update.
- Use rebase for local or explicitly private commits and communicate before rewriting a branch another person or deployment consumes.
- When a rewritten branch must update remote, use a lease tied to the observed remote state rather than an unconditional force push.
- Create or retain a recovery reference before complex history surgery and know how to find prior tips through reflog or the hosting platform.

See /src for the adjacent decision or procedure that completes this constraint.

---

### [RULE] Resolve conflicts from both changes' intent  (path: /src)
<!-- scope: folder | priority: high | strict -->

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.

- Identify what each branch intended and which assumptions changed since the common base.
- Resolve by composing behavior and deleting obsolete paths, not by mechanically choosing all of one side or concatenating both.
- Search for related symbols, registrations, configuration, tests, and documentation that must agree with the resolution.
- Run focused tests and inspect the staged diff without conflict markers, accidental debug code, duplicate imports, or unrelated formatting churn.

See /migrations for the adjacent decision or procedure that completes this constraint.

---

### [MEMORY] Ordered artifacts require domain-aware conflict policy  (path: /migrations)

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.

- Preserve every independently shipped migration and create a new reconciliation migration when both branches changed the same schema assumption.
- Regenerate lockfiles, code, snapshots, catalogs, and manifests from the merged authoritative sources using the pinned toolchain.
- Do not renumber or edit an already applied migration merely to remove a filename conflict.
- Review generated diffs for unexpected dependency, ordering, schema, or content loss instead of assuming regeneration is automatically correct.

See /src for the rule or workflow that puts this decision into practice.

---

### [MEMORY] Branch lifetime determines integration strategy  (path: /)

A branch that diverges for weeks accumulates conflicts in code and product assumptions. No Git command can make that integration cheap after the fact.

- Split work into independently reviewable changes that can merge behind compatibility layers or feature controls.
- Update from the target branch regularly while the branch is private and resolve conflicts near the change that introduced them.
- Use merge commits where preserving a shared integration event matters and rebase where a private linear series improves review.
- Delete merged branches after verifying the intended commit reached the target; branch names are collaboration handles, not durable release records.

See /src for the rule or workflow that puts this decision into practice.