Hi, During SDK training, I recall a discussion mentioning having a third branch can be beneficial, e.g. `deploy`, so that as developers' feature branches wrap up, they can be merged into the `deploy` branch instead of `master`. This allows a way for `master` to remain pre-production work, truly staging work. However, since a `deploy` branch is not tied to an environment, there would not be a way to test code there. In this case, `deploy` would basically be a repository branch, while `master` needs to be where features are tested. It seems then, without a testing branch tied to an environment, when waiting on a merge request from `master` to `production` or if `master` is being used for UAT on extension, `master` has to remain 'frozen' from in-progress features being tested. Like I said, I thought I heard a recommended pattern around using `master` for the dual purposes of both testing and pre‑production staging?

Hi, During SDK training, I recall a discussion mentioning having a third branch can be beneficial, e.g. `deploy`, so that as developers' feature branches wrap up, they can be merged into the `deploy` branch instead of `master`. This allows a way for `master` to remain pre-production work, truly staging work. However, since a `deploy` branch is not tied to an environment, there would not be a way to test code there. In this case, `deploy` would basically be a repository branch, while `master` needs to be where features are tested. It seems then, without a testing branch tied to an environment, when waiting on a merge request `master` has to remain 'frozen' from in-progress features being tested. Like I said, I thought I heard a recommended pattern around using `master` for the dual purposes of both testing and pre‑production staging?