Branching is an OrgVue feature designed to be a ‘holding ground’ for changes. It is a mechanism by which one can make changes to a branched dataset and save these changes without ever changing the dataset underneath.
But what happens if a node is changed in both the trunk and branch - which change persists in the branch?
A change made to a property of a node in a branch will resist a subsequent change to that property of that node in the trunk.
Changes to other properties of that same node in the trunk will be reflected in that property in the branch.
Another way to explain this is that all changes made to a node in the trunk will flow into the corresponding node in the branch, except when the corresponding property in the branch has been changed, in which case the value in the branch resists the change from the trunk.
One further nuance to consider is where modelling work results in nodes appearing in different branches. Say there is an HR branch where the branch has been created based upon the value 'HR' appearing in the nodes' Department property. If a node has the Department changed in the trunk, then it will not appear in the branch when it is re-loaded, UNLESS the node in the branch has been changed in any way (and not just the Department property).
The logic here is that even though the trunk version of this node now has the Department set to Finance instead of HR, and one would think therefore that it shouldn't appear in the HR branch, but there is an unsaved change to this node in the branch, and if it were removed from the view of the branch, then any changes to that node would be lost. The node will appear in the HR branch (and also in the Finance branch) until the changes in the HR branch have been pushed back, at which point it will be removed from the HR branch view.
Find out more about how to use branching to model organisational change scenarios.