Example: Cascading Change Requests
Create a chain of dependent change requests and merge them in the correct order.
Goal
- CR #1 introduces a new API endpoint.
- CR #2 adds frontend code that calls the new endpoint (depends on #1).
- CR #3 adds documentation for the feature (depends on #2).
- All three should merge in order: #1 → #2 → #3.
Step 1: Create the Change Requests
Create three change requests from their respective feature branches targeting master.
Step 2: Add Dependencies
On CR #2, add a dependency on CR #1. On CR #3, add a dependency on CR #2. This creates a chain:
#1 (API) <-- #2 (Frontend) <-- #3 (Docs) Step 3: Review and Approve
Get each CR reviewed and approved independently. The dependency chain ensures they cannot merge out of order.
Step 4: Merge in Order
When CR #1 is approved and ready, merge it. Merging processes the dependency chain in order, so the rest of the stack is handled automatically:
- Merge CR #1 into
master. - After #1 succeeds, update CR #2 and merge it.
- After #2 succeeds, update CR #3 and merge it.
Squash with Dependency
When adding a dependency on CR #3, you can enable squash-with-dependency on that dependency. The dependent CR is then squashed together with the CR it depends on during the merge, combining their changes into a single commit. This is useful when commits form a logical unit.
Result
- All three CRs merge in the correct order.
- The dependency graph ensures no CR merges before its prerequisite.
- Rebasing, syncing, and conflict detection are handled automatically during the merge.