Take a step back and ask why are you testing, whatâs your testing mission?
Who is your testing of value to, who wants your good testing feedback?
Often its developers so then just ask them if its of value to them.
In cases where I have done branch testing it served a few purposes.
I could catch things before they go into the main shared build as 5 developers were all creating branches often multiple branches a day and the chat with the developer for rapid turn arounds of fixes sometimes a fix could be made to a branch in a couple in mins.
When I did find something it was highly likely due to a single specific change as only one developer had worked on it and changes tended to be on specific stories, route cause analysis was faster and no ping pong between multiple developers changes.
All of our branches were deployed so I could simple change the url /655 or url/656 and main so I could just tab between differences and compare real time to main, this also helped narrow things down quickly.
The testing tended to be focused on the actual changes made usually around a story so normally one or two short test sessions so normally same day and no bottle necks.
Developers would often ask me to have an early look knowing a feature was not finished yet, for example I might get asked to have an early look on specific mobile devices or versions to give the developer insight before they go down a wrong path on a change or a route that turned out to be incompatible. This empowered the developers to be more experimental, small experiments I could provide rapid feedback on which they valued.
If there were multiple branches available to test, the team could prioritise and Iâd look at one the want to push out earlier than perhaps other branches that were already available.
Importantly this was complimented with developer owned regression coverage including UI layer tests that needed to pass on every branch, new test were usually added by the developer on every change. System monitoring also in place for regressions. This work highly efficient in my view as it allowed me to focus on new and changed things.
Before or after code review, most times I was before as highly competent developers and controlled changes but it was still a discussion with devs as it carries rework risk.
So in my context there were lots of advantages to branch based exploratory test sessions for the whole team. Hope it gives you a few ideas to discuss if they may also be advantage to your team but fundamentally get whole team buy in, in some context it could be seen as an extra layer.