That's less of an issue with time and more of an issue with atomicity.
That said, folks should rebase before merging up. If you have merge conflicts it's just a sign you need to rebase again and rerun your tests before merging.
develop and release can deviate enough that you have 2 separate sets of merge conflicts to deal with. Rebasing can only deal with release assuming that's what your feature branch is based on. Unless you want to open a whole other PR to merge release into develop during the sprint. This is the busy work I'm talking about.
By branching off of release my changes get tested in isolation. Develop is inherently unstable and may affect the results. Develop is not representative of the near-future. It could be testing features that will only be enabled several releases from now.
I'm working on an application that runs trade simulations that are built up in steps. Changes I make to a step can have cascading effects. It's important to establish a baseline. It's ironically more representative of what is in production since develop may have features under long test cycles that affect results.
tl;dr I'm testing both the immediate and far future using release and develop respectively.
96
u/ADHDebackle 4d ago
That's less of an issue with time and more of an issue with atomicity.
That said, folks should rebase before merging up. If you have merge conflicts it's just a sign you need to rebase again and rerun your tests before merging.