Is there any way for QA to do the feature testing before each feature merged to sacred branches?

I'm a Laravel developer working on some Laravel projects. I want to know if there any best way to do development cycle. In this case, I store my project in version control system such as Gitlab. I have 3 sacred branches which are:

1. Master. The only thing to do in this branch is merging the Release branch after one week or one month that branch released and was stable. Never touch this in any other cases. Only for backup if something happened with the Release branch.
2. Release. This is the main branch that used for the production deployment. The Development branch is merged to this branch after all the testing is done.
3. Development. This branch is used for the final testing. Maybe just like internal release or something alike. Every feature branch that merged to this branch, needs to be released. Also if any hotfix is needed, this is the source branch and then merge the hotfix branch to this branch again after some fixing then do the testing again.

Aside from that sacred branches, there's other branches like features and hotfixes. My deployment tools is Deployer that integrated with Jenkins.

And for example I have 3 features with 3 branches like this

1. Auth Management (feature-auth-management branch),
2. Dashboard (feature-dashboard branch)
3. Cart (feature-cart branch)

What is the best way for the QA to do the test without cloning the project and change the branch on their own local machine? What come on my mind is, integrate the git branches with the server virtual host, so that every branch have their own sub domain, which I know that are not currently not available and maybe have some security issues. Another thing is to create Jenkins and Deployer instance for every branch manually which really have high effort. Maybe you guys have any other suggestions?

The reason of why the QA should test on feature test, on my personal opinion, is when the feature is done, and somehow it is really different from the requirement. The developer could just destroy that branch and just remake the feature without polluting the sacred branches. And another reason, so that we can take what feature to be release now and later.

It sounds like you could benefit from a staging environment, which is usually used exactly for the purpose you are looking for. As far as my experience goes, applications tend to work with a few environments:

• Development, which is used by developers to go crazy, since it holds no important data
• Testing, which is typically only used by QA to test out new features, however I have been with companies that will skip this environment and prefer just using staging for this as well
• Staging, which is used by QA and possibly clients to test out new features, it usually uses some mocked version of actual production data and should represent the production environment as much as possible
• Production, which might be obvious, is used by the actual users of your software

New features are typically developed in their own branches, which will then be moved onto the development branch (possibly after a peer review of some sort). The development branch can then be moved onto staging whenever a subset of new features are ready to be tested. Of course there are many personal tastes included in this process, so feel free to modify anything that you feel would work well in your case. Reading up on a staging environment might just give you the inspiration you seek.

Lastly though, when dealing with source control (if done right), a 'back up' branch like you seem to have should not be required, since any commit can be reverted.