Skip to content
Classic documentation
  • There are no suggestions because the search field is empty.

Branching reference

General information and an overview of different scenarios involving the branching feature offered in My Betty Blocks

Building an application, especially with others, requires a grip on the changes you make and timing so you don't get in the way of your end-users. Sandboxes offer great solutions, so you can split the environment used by your end-users from the environment where you develop. Then, when changes are done, merge the sandbox and the new additions are available in the production environment.

This is considered a one-way street, where changes need to be applied from the bottom-up (Development, Testing, Acceptance, and finally Production). It's inconvenient to take this route when small changes need to be applied on short notice. By using the Branching option, you can easily apply quick fixes while maintaining the development-street integrity.

Below, you'll find more information about this feature, how and when to use it, and what to look out for.

Name already taken

I.E. Branch A and B both have the same name and try to merge this to the parent.

  • Variable Name (in same context, i.e. -> page, action, global)

  • Webservice.name

  • Webservice > endpoint.name

  • (Custom)Model.name (Only on create)

  • (Custom)Model > property.name

  • (Custom)Model > relation.name

  • PublicFile.name

  • AuthProfile.name

  • Config.name

  • Endpoint.cachedFullPath

 

Already modified

I.E. Branch A updates an action description and Branch B also updates the same description, even if changed to the same value.

  • Page.property

  • UI Component (Position)

  • Component option.property

  • (Custom)Model.property

  • (Custom)Model > Property.property

  • (Custom)Model > Relation.property

  • Action.property

  • Action > Event.property

  • Back office view.property

  • Back office grid.property

  • Template

  • Variable.property

  • AuthProfile.property

Deleted item used

I.E., Branch A deletes an action and Branch B updates a property on this action.

Modified item deleted

I.E., Branch A modified a property on the action and Branch B deletes this action.

Resolving conflicts

Name already taken:

Example scenario:

  1. Create 2 branches (Branch A, Branch B).

  2. Open Branch A.

    1. Create a model named Customer.

    2. Create a page named 500.

  3. Merge Branch A.

  4. Open Branch B.

    1. Create a model named Customer.

    2. Create a page named 500.

  5. Open Branch A merge plan

  6. Descendant changed conflict should show up 

nameAlreadyTaken

How to resolve

This can only be resolved manually by renaming or removing them within Branch B.

Already modified:

Example scenario:

  1. Open Sandbox IDE.

    1. Create a 500-page template

  2. Create 2 branches (Branch A, Branch B).

  3. Open Branch A IDE and edit the title and description, then merge.

  4. Open Branch B IDE and edit the title and description.

  5. Open Branch B merge plan.

  6. Already modified conflict should show up. 

alreadyModifiedConflict
 

 

How to resolve

Recommended: Resolve this by updating the branch with changes from acceptance.

  1. Check for updates for Branch B by navigating via the banner.

  2. Open the resolve conflicts modal via the view conflicts or resolve conflicts button.

  3. Then select the values you want to keep from either the sandbox or Branch B.

  4. Merge changes.

  5. Be sure to validate the changes in Branch B and make manual changes where needed.

validateChanges
 

Optional: Resolve this by overwriting all conflicts with the values from Branch B.

  1. Open the merge plan of Branch B.

  2. Toggle all the “item already modified” checkboxes.

  3. Merge changes.

  4. Be sure to validate the changes in the sandbox.

 

Deleted item used:

Example scenario:

  1. Open Sandbox IDE.

    1. Create a 500-page template

  2. Create 2 branches (Branch A, Branch B).

  3. Open Branch A IDE and delete the box holding the title and description.

  4. Open Branch B IDE and edit the title and description.

  5. Open Branch B merge plan.

  6. Deleted item used conflict should show up.

alreadyModifiedConflict
 

How to resolve

It is currently not possible to resolve 'deleted items' conflicts via the UI in My Betty Blocks.

Recommended: Resolve this by updating the branch with changes from acceptance.

  1. Check for updates for Branch B by navigating via the banner.

  2. Merge changes.

  3. This will remove the deleted items in your branch, resolving the conflict.

Optional: Copy the deleted component to preserve these changes in the branch.

  1. Open Branch B.

  2. Copy the box component.

  3. Remove the box component that was removed in the acceptance sandbox.

    1. This can also be done by performing an update from acceptance.

  4. Open the merge plan of Branch B, and the conflicts will be resolved.

 

Ancestor moved

Example scenario:

  1. Open Sandbox IDE.

    1. Create an action.

    2. Create a condition (label: root_condition, paths: [Path 1, else]).

    3. Create another condition [label: child_condition] under root_condition → Path 1.

  2. Create 2 Branches (Branch A, Branch B).

  3. Open Branch A IDE and move child_condition from Path 1 to else.

  4. Open Branch B IDE and add an action step under any path on child_condition.

  5. Merge Branch A.

  6. Open Branch B merge plan.

  7. Ancestor moved conflict should show up.

Ancestor moved

How to resolve

It is currently not possible to resolve Ancestor conflicts by choosing the values from the sandbox.

Recommended: Resolve this by updating the branch with changes from acceptance.

  1. Check for updates for Branch A by navigating via the banner.

  2. Open the resolve conflicts modal via the view conflicts or resolve conflicts button.

  3. Then resolve by selecting the values from Branch A.

  4. Update Branch A, this will result in both changes ending up in Branch A.

  5. Make manual changes where needed in Branch A to combine all changes as required.

  6. Open Branch A merge plan, the conflicts should be resolved or can be resolved with all Branch A changes that now contain also the changes coming from acceptance.

  7. Merge Branch A.

  8. Be sure to validate the changes in the sandbox.

 

Descendant changed

Example scenario:

  1. Open Sandbox IDE.

    1. Create an action.

    2. Create a condition (label: root_condition, paths: [Path 1, else]).

    3. Create another condition [label: child_condition] under root_condition → Path 1.

  2. Create 2 branches (Branch A, Branch B).

  3. Open Branch A IDE and move child_condition from Path 1 to else.

  4. Open Branch B IDE and add an action step under any path on child_condition.

  5. Merge Branch B.

  6. Open Branch A merge plan.

  7. Descendant changed conflict should show up.

descendantChanged

How to resolve

It is currently not possible to resolve descendant conflicts by choosing the values from the sandbox.

Recommended: Resolve this by updating the branch with changes from acceptance.

  1. Check for updates for Branch A by navigating via the banner.

  2. Open the resolve conflicts modal via the view conflicts or resolve conflicts button.

  3. Then resolve by selecting the values from Branch A.

  4. Update Branch A, this will result in both changes ending up in Branch A.

  5. Make manual changes where needed in Branch A to combine all changes as required.

  6. Open Branch A merge plan, the conflicts should be resolved or can be resolved with all Branch A changes that now contain also the changes coming from acceptance.

  7. Merge Branch A.

  8. Be sure to validate the changes in the sandbox.

 

Action step ordering

Example scenario:

  1. Open Sandbox IDE.

    1. Create an action.

    2. Add an action_step (label: action_step_1).

  2. Create 2 branches (Branch A, Branch B).

  3. Open Branch A IDE and add an action_step above action_step_1 (label: branch_1_action_step).

  4. Open Branch B IDE and add an action step at the same position as branch_1_action_step.

  5. Merge Branch A.

  6. Open Branch B merge plan.

  7. Action step ordering conflict should show up.

ActionstepOrdering

How to resolve

It is currently not possible to resolve descendant conflicts by choosing the values from the sandbox.

Recommended: Resolve this by updating the branch with changes from acceptance.

  1. Check for updates for Branch B by navigating via the banner.

  2. Open the resolve conflicts modal via the view conflicts or resolve conflicts button.

  3. Then resolve by selecting the values from Branch B.

  4. Update Branch B, this will result in both changes ending up in Branch B.

  5. Make manual changes where needed in Branch B to combine all changes as required.

  6. Open Branch B merge plan, the conflicts should be resolved or can be resolved with all Branch B changes that now contain also the changes coming from acceptance.

  7. Merge Branch B.

  8. Be sure to validate the changes in the sandbox.

 

Component ordering

Example scenario:

  1. Open the Sandbox IDE.

    1. Create a page.

    2. Add a 3-column component to the page.

  2. Create 2 Branches (Branch A, Branch B).

  3. Open Branch A IDE and add a 1-column component above the 3-column component.

  4. Open Branch B IDE and add a 2-column component above the 3-column component.

  5. Merge Branch A.

  6. Open Branch B merge plan.

  7. Component ordering conflict should show up.

Component Ordering

How to resolve

It is currently not possible to resolve descendant conflicts by choosing the values from the sandbox.

Recommended: Resolve this by updating the branch with changes from acceptance.

  1. Check for updates for Branch B by navigating via the banner.

  2. Open the resolve conflicts modal via the view conflicts or resolve conflicts button.

  3. Then resolve by selecting the values from Branch B.

  4. Update Branch B, this will result in both changes ending up in Branch B.

  5. Make manual changes where needed in Branch B to combine all changes as required.

  6. Open Branch B merge plan, the conflicts should be resolved or can be resolved with all Branch B changes that now contain also the changes coming from acceptance.

  7. Merge Branch B.

  8. Be sure to validate the changes in the sandbox.

 

Edited the same item:

 

Situation 1A:

  • C1: Base Sandbox

  • C2: Create Branch A from Sandbox

  • C3: Create Branch B from Sandbox

  • C4: In Branch A, Change the value from template to Hello World!

  • C5: Merge Branch A in the Sandbox
    ​    Changed value from template to Hello World!

  • C6: In Branch B, change the value from template to Product overview

  • C7: Merge Branch B in the Sandbox Conflict "edited same item"
    Resolve conflict via UI, changed value from template to Product overview

  • C8: Update Branch A with new changes in Sandbox NO CONFLICT
    ​    Changed value from template to Product overview

 

Situation 1B:

  • C1: Base Sandbox

  • C2: Create Branch A from Sandbox

  • C3: Create Branch B from Sandbox

  • C4: In Branch A, Change the value from template to Hello World!

  • C5: Merge Branch A in the Sandbox
    ​    Changed value from template to Hello World!

  • C6: In Branch B, Change the value from template to Product overview

  • C7: Merge Branch B in the Sandbox Conflict "edited same item"
    Resolve conflict via UI, changed value from template to Product overview

  • C8: In Branch A, Change the value from template to Bye World!
    ​    Open the merge overview now shows a conflict.

  • C9: Update Branch A with new changes in Sandbox CONFLICT "edited same item"
    Resolve conflict via UI, changed value from template to Product overview

 

deleted_item_used:

 

Situation 2: Resolve conflict "deleted item used" when merging.

  • 1C: Base Sandbox, containing a Global Variable with the value: 'Demo'.

  • 2C: Create Branch A from Sandbox.

  • 3C: Create Branch B from Sandbox.

  • 4C: Delete { Globale Variabele: 'Demo" } in Branch A.

  • 5C: Merge Branch A in Sandbox, Delete { Global Variable: 'Demo" }.

  • 6C: Create a new Actie in Branch B with a Conditional event and use the Global variable in it:
    { Action: 'New action', { Event: 'Conditional', { GlobalVariable: 'Demo' } }.

  • 7C: Merge Branch B to Sandbox gives: Conflict "Deleted item used"
    This is because within the Sandbox the global variable no longer exists.

Possible solutions:
​- Update from Sandbox to Branch B removing the global variable or removing the Global variable in Branch B. You can choose to create a new global variable and use this within the action event.

  • 8C: Merge Branch B in Sandbox with the resolved conflict en possible other work.

 

Situation 3: Resolve conflict "deleted item used" when updating.

  • 1C: Base Sandbox, containing a Global Variable with the value: 'Demo'.

  • 2C: Create Branch A from Sandbox.

  • 3C: Create Branch B from Sandbox.

  • 4C: Create a new Action in Branch B with a Conditional event and use the Global variable in it:

  • { Action: 'New action', { Event: 'Conditional', { GlobalVariable: 'Demo' } }.

  • 5C: Merge Branch A in Sandbox, create: { Action: 'New action', { Event: 'Conditional', { GlobalVariable: 'Demo' } }

  • 6C: Update Sandbox to Branch B gives: Conflict: "Deleted item used"
    This is because within Branch B the global variable no longer exists.

  • 7C: Create a new Branch C from Sandbox.

  • 8C: Delete the { GlobalVariable: 'Demo' } OR delete the { GlobalVariable: 'Demo' } used within the conditional event in Branch C. You can choose to create a new global variable and use this within the action event.

  • 9C: Merge Branch C in Sandbox

  • 10C: Update Branch B from Sandbox

Hope these situations give you a better insight into Branching from your sandboxes to give you more freedom in application development.


​