Foundry Branching is highly opinionated about the development style that organizations should implement. It features a monorepo hierarchy and enforces trunk-based development ↗ for fast, stable development.
Branches are intended to be short-lived and relatively small. This is because large branches are difficult to review and maintain, as resources become more prone to conflicts the longer they remain open.
The following section includes details on how Foundry Branching works in different applications.
Foundry Branching for pipelines builds upon the existing data pipelines branching implementation.
Foundry Branching for Ontologies builds upon the existing Ontology proposals implementation.
Foundry Branching for Workshop enables you to modify Workshop modules and test changes on a branch. Unlike Pipeline Builder and Ontology Manager, Workshop does not have a branching mechanism other than Foundry Branching.
With Foundry Branching, data that has been modified on a branch in Pipeline Builder can be previewed in Workshop on that same branch. Similarly, Actions can be run and changes to the Ontology can be tested in Workshop modules. To learn more about running Actions on branches, refer to the supported functionality documentation.
Main branch are currently unavailable for object types that are modified on the branch.In some cases, the Workshop version on a branch can become out of date with the Main branch. This occurs when changes were made and merged to production after the creation of your Foundry branch. To resolve this, a rebasing feature will highlight where conflicts are occurring. Refer to Workshop rebasing and conflict resolution for more information.
Workshop integration with the Approvals application is still in development. This means that Workshop changes do not currently require a review process to merge your branch; changes made by users with Editor rights on the module are automatically approved.