This is an experimental feature and is not available on all enrollments.
Workshop rebasing enables multiple builders to edit a single module at the same time without needing to worry about overriding each other's changes.
Prior to merging workshop changes on a branch into Main
, rebasing will be required if a change occurred on Main
after the module was saved on a branch.
The rebasing user interface uses the Changelog panel to depict the changes made in the module.
If rebasing is required prior to merging, the Changelog panel will display a visual notification dot. Selecting the panel will show an option that allows the application builder to begin rebasing.
Rebasing will attempt to apply changes made on the branch to the latest Main
version of the module. Changes that trigger merge conflicts will need to be resolved manually to proceed.
A change will be marked as a merge conflict if it was changed both on the Main
version and the branch. Some common examples of merge conflicts:
Main
and your branch.Main
and edited on the branch.A
to B
on Main
and from A
to C
on your branch.When resolving a merge conflict, you can switch between three states within the module. Switching between these modifies the module in real time, allowing you to test how the different options affect the module.
Main
.Main
and your branch.Once you are happy with how your module looks and have resolved any merge conflicts, you can save the module to finish rebasing.
Once this is complete, you can safely merge your workshop changes from your branch into Main
.
In the example below, we encounter a merge conflict with the object table widget when we try to rebase. On Main
, a new column "Departure airport code" was added. However, on our current working branch, we added a column "Action required".
Main:
Branch:
In this case, to keep both columns, first select Main
and manually add the Action required
column. From here, the conflict can be resolved.