If you can work in the same branch, consider making unreasonable merging of all changes into one branch and abandoning another branch. If you have other changes in your branch that should remain separate, then CAREFULLY consider the selection of cherries only those changes that should be unreasonable, merged into one branch, and then return these changes to the source branches.
Structure (for reference):
The process will look something like this:
- FI (Forward Integrate) Trunk communication for both children. (Merge the connecting line to branch A , then the connecting line to branch B ).
- Non-free merger from B to A.
- Abandon B (at least a lock to prevent accidental use of a retired branch).
- FI Backbone to A again (re-merge and resolve merge conflicts before further changes are made.
- Both you and other developers continue to develop in branch A to stable.
- FI Trunk to A (select recent changes from other developers or other transactions)
- Quickly create and run smoke tests in (FI confirmation is successful and A is still stable)
- If additional changes to the trunk occur during the smoke test, then repeat 6 and 7, or possibly block the trunk until steps 6-8 are completed.
- RI (inverse integral) A to the outside line
IDEA: If possible, you will not have to share unstable changes between child branches in the future. Useless mergers and changes in cherries are operations with a higher risk than standard mergers of parents and children. One of them is to use a common development branch, and then a branch to a function only when necessary. All developers use the common dev branch for changes. When breaking changes, it is necessary that several developers build stabilization and create a function branch. After stabilization, integrate back into the Dev branch and remove the function branch.