Resbaser flow
is git flow that uses rebase
over remote branches as well.
Rebaser flow track project history from production perspective splitting project history tracking into traceable and replaceable tracking. Therefore it leverages conflict resolution pollution with rebasing public branches while the code is not in production yet (in replaceable phase), but still in public branches that can be overwritten by higher priority branches. Conflicts are automatically transferred to lower priority branches using a fail fast approach. Concepts of rebase limitation and following branches are implemented via scripting so far.
Instead of having history like:
gitGraph
branch dev
commit
branch qa
branch prod
checkout dev
commit id: "A"
commit id: "B"
commit id: "C"
checkout qa
merge dev
checkout prod
merge qa
checkout dev
commit id: "D"
checkout qa
commit id: "B-fix"
checkout dev
merge qa tag: "fix merge"
checkout prod
commit id: "A-hotfix"
checkout qa
merge prod tag: "hotfix merge1"
checkout dev
merge prod tag: "hotfix merge2"
commit id:" "
checkout qa
merge dev
checkout prod
merge qa
It produces history like:
gitGraph
branch dev
commit
branch qa
branch prod
checkout dev
commit id: "A"
commit id: "B"
commit id: "C"
checkout qa
merge dev
checkout prod
merge qa
checkout prod
commit id: "A-hotfix"
checkout qa
merge prod tag:"hotfix rebased"
commit id: "B-fix"
checkout dev
merge qa tag: "fix rebased"
commit id: "D"
checkout qa
merge dev tag: "upq promoted"
checkout prod
merge qa tag: "upprod promoted"
It removes conflict resolution commits from history, and instead of having sequence D, B-fix, fix-merge, A-hotfix, hotfix merge1, hotfix merge2, the one that exists form developer perspective, it produces A-hotfix, B-fix, D which exist from deployment perspective.
History comparison
A,B,C,B-fix,B-merge,A-hotfix, hotfix-merge1, hotfix-merge2 | A,A-hotfix,B,B-fix,C |
---|---|
Dev chronological | Deployment chronological |
Functionally logical | |
hard to read | easy to read |
Till new git commands are introduced this is a workaround:
- apply gitscript.sh
- set rebase as default pull strategy
- Pull replacement (always rebase with all upper branches)
git pld
- pull latest development version (check + fetch + rebase qa + rebase prod
)git plq
- pull latest qa version (check + fetch + rebase prod
)git plprod
- pull latest production version (check + pull
)
- Push (not changed)
- Promote branches (when branches are ready to be promoted to upper(more important) branch, it is only fast forwarded)
git upq
- Apply all changes from dev to qa (rebase --ff-only
)git upprod
- Apply all changes from qa to production (rebase --ff-only
)
- Conflict
- if you are on dev branch use
git divd
- confirmation that dev branch divergence is resolved and is ready to be forcibly pushed on remote dev branch branch (create backup branch + force push from local dev branch
) - if you are on qa branch use
git divq
- confirmation that qa branch divergence is resolved and is ready to be forcibly pushed on remote qa branch (create backup branch + force push from local qa branch
)- corresponding backup_branch could be kept for a while till you are sure that backup branch is not needed anymore
- delete
backup_DATE
branch (if you are sure that all conflict are resolved
)
- if you are on dev branch use
If you are using rebases and like its benefits over merge, perhaps you should consider using it on remote branches as well, although it was highly recommended not to till now. Let's , so let's see how it could be used on remote branches (until rebaser it was highly recommended not to use in public branches) .
Therefore it leverages:
- cleaner history over all project branches instead of the remote one you are working on.
- moving conflict impact from most important brach to least important brach (by utilizing approach
most important
branch , instead ofmost used
branch). - use
fail fast
approach to conflict resolution with impact on least important branch. - use
history is written by winner
approach, instead of The Golden Rule of Rebasing reads: “Never rebase while you're on a public branch.” - make QA and Code freeze phase duration flexible instead of fixed (TBD).
Feel free to reach us, if you like this idea, don't understand the idea, don't like the idea. We are forming a working group for this kind of flow and would be pleased to help you to challange it together, explain it or use it with your team or incorporate new ideas. If you reach us, please type a role you are having: developer, senior developer, team lead, project manager.
- update all text from docs
- improve diagram double rebase flow
- figure out how to show rebase in diagrams
- give explanations from TLDR
force push
limitation with backup branchesgarbage branch collector
- timing concept and branch delays
- dev history and deployment history
- define final name (double rebase flow VS rebaser flow VS mi flow VS buble flow)