Use a promote merge to “deliver” changes in a child view to its parent. You could promote once at the end of the child view’s lifecycle as a prelude to discontinuing work in the child view. However, you can also promote multiple times to periodically deliver changes from the child view to the parent. In either case, it is typically a good idea to rebase the child view just prior to promoting it to ensure it has “accepted” (been merged with) all recent changes from the parent view.
When performing a Promote merge type, follow these general rules:
This example shows a typical scenario where the a child view is created to enable a new branch of development that is simultaneous with continued development on the main branch. During development, the child view is modified, rebased, compiled, tested, then ready for release. At various stages, changes from the child view are promoted to the parent view to release changes, perhaps at key delivery milestones. At the end of the branch's life, a Rebase is performed with the parent view. After the changes in the child from the parent view are compiled, the child view is promoted to the parent again.
In this scenario, the child view is promoted twice and retired (no longer used) after the second promote. Typically, you’d want to delete a retired view after a period of time.