We will show This section describes in detail the essential steps the workflow is composed of by using a very simple example. To this end, we created an will use a very simple example based on a ad hoc empty repository, named <code>test0</code>. The goal is to write the first release of the code by following the recommended workflow.

Once the repository is createdon GitLab, we create an issue. Every implementation should start with this step: '''first of all, create an issue'''!

Then, we create a merge request associated with the issue. We instruct GitLab to automatically create a branch associated with this issue as well. The branch will be called <code>1-first-release</code> and its source branch is <code>mainmaster</code>. This means then when the merge request is accepted, the new code in the branch <code>1-first-release</code> will be merged into the branch <code>mainmaster</code>.

Please note that the merge options are so that the branch will be deleted when the merge request is accepted. This usually makes sense because we don't need to keep the branch we when the job is done. If you are askingto yourself, don't worry: although the branch will be is deleted, commits will not be lost. Therefore, the history of changes will be preserved.

On GitLab side everything is in place, so we can work on our local host to write our code. For the sake of simplicity, we will just edit one file, <code>README.md</code>.

TheaThen, we checkout the branch named <code>1-first-release</code>:

/test0$ git branch -a

/test0$ git checkout 1-first-release

/test0$ ll

We edit the <code>README.md </code> file with our favorite editor, then we commit our changes and push them to the remote repository:

/test0$ git diff

/test0$ git add README.md /test0$ git commit -m "Change README.md"

/test0$ git push

We can now move back to GitLab[[File:Gitlab-side and close the merge requestwf-4.png|center|thumb]]

[[File:Gitlab-wfOn GitLab-4side we can close the merge request.png|center|thumb]]We mark it as ready in order to prepare it for merging:[[File:Gitlab-wf-5.png|center|thumb]]In case you have the permission to start the merging by yourself, you can press the "Merge" button. If you do not have such permission, for example because you have been assigned a <code>developer</code> role, this operation will be run by the <code>maintainer</code> of the repository.[[File:Gitlab-wf-6.png|center|thumb]]After merging is complete, you should see something like this:[[File:Gitlab-wf-7.png|center|thumb]]If we check the <code>master</code> branch, GitLab confirms that the merging was completed successfully:[[File:Gitlab-wf-8.png|center|thumb]]We can also see a graphical representation of we just did where it is clear the that temporary branch was deleted after having been merged into the <code>master</code> branch: [[File:Gitlab-wf-9.png|center|thumb]] == Conclusion ==We strongly recommend to use this workflow for any implementation, being it adding a new feature, fixing a bug, optimizing a function, or whatever. Even though it may seem a little bit cumbersome at first sight, it has proved to be very efficient and effective when several developers