Repository Layout

Patchforge does not require a central patch repository. Patches can live directly inside application repositories.

Recommended Layout

repo/
  src/
  docs/
  db/
    patches/
      20260914_103512_add_users.sql
      20260914_104102_add_index.sql
    

The patch directory inside the repository is configurable using:

PATCHES_SUBDIR=db/patches
    

Branching Model

The Git branch represents the deployed version of the service.

• main or master for continuous deployment
• release branches for versioned environments
• hotfix branches for emergency changes

Patchforge applies patches based on what exists in the checked-out branch.

Multiple Microservices, Same Database

When multiple services share a database:

• Manage patches per database, not per service
• Designate a single repository as the schema authority
• Other services must not ship database patches

Multiple writers to the same schema is an operational risk.

Multiple Databases

Each database must have its own Patchforge instance or its own configuration.

Do not mix patches for different databases in the same patch directory.

Legacy Databases

Patchforge is safe to introduce into existing databases.

• No schema inspection is performed
• No assumptions are made
• Existing tables and data are untouched

The first patch applied becomes the baseline.

Patchforge records only what it applies, not what already exists.

Immutability Rules

• Applied patches must never be modified
• Applied patches must never be reused with new content
• Deleting a patch from Git does not remove it from the database

Patchforge treats the database as the source of truth for patch history.

Developer Workflow

Developers can create name for patches using a timestamp-based naming tool.

https://patchforge.manaslusystems.com.generator.html
    

Patchforge does not enforce naming rules. Operational discipline is required.