Rebase Merge
Use a Rebase merge to “catch-up” a child view with changes that have occurred in the parent view since the child view was created, or since the last Rebase.
Rules for Rebase
When performing a Rebase merge operation, follow these general rules:
- The target view must be a branching (variant), immediate child of the source view.
- The target view items should have branch on change set, and have been created using a pinned (not floating) configuration.
- The Rebase operation can use any configuration of the source view (tip, label, timestamp, or promotion state), called the Rebase point.
- The Rebase operation uses the tip (updatable) configuration of the target view.
- Items newly-shared to or re-pinned in the target view use the Rebase/Replicate point. That point is the configuration time of the item in the source view.
Rebase Example Scenario
This example shows a typical scenario where an activity (child, branch-all variant) view is created from a specific label, promotion state, or timestamp to support a specific bug fix or enhancement. After changes are made in parallel in the parent and the child, a Rebase is performed to propagate parent changes to the child view. This process is repeated until the child view is no longer needed.
/>
- An activity (child, branch-all variant) view is created from a specific label, promotion state, or timestamp to support a specific bug fix or enhancement.
- Changes are made for the activity: modified files branch, new files are added, files are moved or renamed, and so on.
- Changes are made in parallel in the parent view.
- A Rebase is performed to propagate changes in the parent to the child view.
- More changes occur in both views in parallel.
- Another Rebase is performed to propagate new changes.
In this scenario, an activity view is rebased twice to update it with changes that occurred in the parent.