Salesforce Trunk-based Development

To reduce merge conflicts in metadata XML files:

Instead of building a massive feature for 2 weeks, developers break work into small chunks. salesforce trunk-based development

| Strategy | When to Use on Salesforce | |----------|----------------------------| | (commit directly to main ) | Small teams (<5 devs), high trust, simple metadata (no profiles). | | Short-lived branches + PRs | Most Salesforce teams. 24-hour max lifetime. | | Release branches (only as needed) | Regulated industries. Create release/v1.2 from main , patch separately. | To reduce merge conflicts in metadata XML files:

| Pitfall | Why it happens | Solution | | :--- | :--- | :--- | | | Developers are afraid to merge incomplete code. | Use Feature Toggles . Merge incomplete code hidden behind a custom setting or static resource switch, so it doesn't activate in production until ready. | | Broken Trunk | Merging bad code breaks the build for everyone. | Enforce strict CI. If the trunk breaks, fixing it becomes the team's #1 priority. Stop all other merges until main is green. | | Sandbox Sprawl | Teams using Dev Sandboxes forget to refresh them. | Use Scratch Orgs defined in project-scratch-def.json to ensure every branch starts with a fresh, clean state. | | Flaky Tests | Apex tests fail randomly, blocking merges. | Isolate and disable flaky tests immediately. They destroy confidence in the Trunk. Fix them in isolation. | 24-hour max lifetime

force-app/main/default/profiles/ .xml -diff -merge force-app/main/default/objects/ /*.xml -diff -merge

name: Validate PR to main