Cette page n'est disponible qu'en anglais.

Git Branching, Rebase, and Merge Conflicts

Pathrule2 règles • 2 mémoires

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.

Carte des chemins suggérée

Pathrule place chaque élément sur le chemin correspondant, pour que votre assistant ne le voie que là où il a sa place. C'est la portée appliquée à l'import ; vous pouvez l'ajuster dans votre espace de travail.

/ racine de l'espace de travail

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

Règles

Rewrite only history you own/roothautestricteRebase 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/srchautestricteRead 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.

Mémoires

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.

Pourquoi ce 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.

Public visé : Engineering teams integrating concurrent code, migrations, generated artifacts, releases, and long-running feature work.

Ce que votre assistant évite :

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

Voir en Markdown

Licence: Apache-2.0
Version: 1.0.0
Mis à jour: 2026-08-25