Workflow for Developers

The workflow for staging and production environments is relatively straightforward:

changes need to be committed to git
the build job in the pipeline for the commit needs to be run
the deploy job in the same pipeline needs to be run to deploy the artifact from the build to the environment

The main questions when establishing a development workflow are where to develop, and how to get these changes into git.

Developing on a local / 3rd party server

If you have your own development server where you can test changes as they are made, the question is simply one of how to commit these changes to git when you are ready to deploy to staging. The simplest way is to clone from gitlab to the dev server, run composer install to get the site working, and then commit changes and push them to gitlab. If you prefer to use your own repository, you can add the gitlab repository as an additional remote, and push to gitlab when you're ready to deploy.

To set up the development site you’ll need a working lamp stack with a version of PHP that corresponds to the Magento version that you’re running, as well as Elasticsearch for Magento > 2.4 and then perform the following actions:

Clone the Git repo containing the Magento project.
Configure the web server package in use (e.g. Apache, NginX) to point the testing domain to the location of the cloned repo.
Create a fresh database and import a recent SQL backup for the store.
Populate app/etc/env.php with the database connection details.
Run composer install to download upstream modules/extensions required by Magento
Run bin/magento setup:static-content:deploy to generate the static content.
If required, clone the Media directory for the store to allow product/theme images.

Developing on an M.D.G. IT server

There are several ways to work if developing on an M.D.G. IT development server:

If you're comfortable with command line git, you can edit the files directly on the dev server, either in SSH using a CLI editor, or using a local editor which connects to the server over SFTP. When you're satisfied with your changes, you then log in to the server using SSH and run git commit and git push. The ability to push directly from the dev server to gitlab needs to be set up by M.D.G. IT. The advantage of this is that you can see your changes reflected immediately, and that you can test your changes before committing them, leading to a cleaner and more manageable commit history. The disadvantage is that you have to be comfortable with CLI git—something that's definitely worth the hour or two to learn.
Alternatively, you can follow this guide to setting up Microsoft Visual Studio with your new development server. Once set up, this will allow you to edit the files on the development server directly, and then push files to your Gitlab repository, all from within VS Code
If you prefer to be able to work from any machine, VS Code can be set up as a web app, hosted on the development server. This allows you to make changes in the browser which are immediately testable, as with running VS Code as a standalone app connecting to the development server.

Please don't hesitate to contact support if you need advice on which method is best for you and your team.