In the company where we work, we use SVN as a version manager, we plan to migrate to GitLab, but we are not very clear about what the workflow should be like, taking into account the following:
Some questions that arise, is how many branches should we handle? At what time would everything go to the master branch? Taking into account that the number of incidents can be high, is it necessary to create a branch for each incident to be resolved?
One of the main differences between SVN and git is that in git creating branches in git is very cheap, therefore there is no problem in creating a branch for each incidence or functionality.
The workflow that best suits your needs is the github flow in which a branch is created for each incident or functionality, as indicated above, once it is ready, a merge request is created which triggers in gitlab the continuous integration engine that can be configured to run the automated tests and to compile the code or install it on a test server.
In this flow, the quality department would review the merge requests and "approve" them so that the support department can perform the merge and update the production version. (These steps can also be automated through the CI.
Finally, it is important to add that it is probably convenient to tune a bit the gitlab configuration to adjust to that workflow, for example, to prevent merge-requests that are not fast-forward, issue that will add work in the development (to keep the branches updated) but will ensure that the code verified by the quality department is the one that will be taken to production.