1. Set up the Git and GitLab environment.
In order for you to modify the code & share it without affecting the original project you will have your own personal space to play with. In GitLab this is called a fork. A fork is a copy of the original project in your own namespace.

In order to do that in GNOME GitLab, go to the overview of the project you chose and click the fork button.

This might take several minutes to complete; fortunately this step is only necessary once.

Once the fork is done, GitLab will show a banner asking to set up ssh keys. This is necessary for authentication and security measures when pushing code. Follow the steps displayed until the ssh keys are generated and added.

After the ssh keys has been successfully set up, set the fork as a git remote. This is necessary so that your fork is accessible from your computer. For that, copy the url displayed in the overview of your project.

Then go to where the code of the project is located and type in a terminal:

git remote add fork $project_url

Substituting '$project_url' by the url of your fork.

Now create a branch for your work called for example 'my_work'. For that, type in a terminal:

git checkout -B my_work

2. Open your project in gitg.

3. Set your author details.
Providing this information means that the work is credited to you. Other developers can later see who made the work and get in touch should they have questions.

4. Create a commit with your changes.
A commit means you make your changes permanent. Go to the staging area, stage your files and press the commit button.

And now you can do the actual commit, clicking the “Commit” button and it will show:

Now we can write our commit message following the guidelines. The commit message should follow a standard format: a short title of 50 chars length, followed by a longer explanation of 72 chars length each line, followed by a link to the relevant bug. Your commit message should look something like this:

modified-file: Short title describing your change

Context of the bug/issue/change.

The problem, when happens and why we need the change.

Overview of the fix.

Closes GitLab issue link

For example:

5. Create a merge request.
Now you have a branch on your own project's personal space and you are ready to propose this change to the original project. The term for that is a merge request.

So let's push your branch to create a merge request. For that, type in a terminal:

git push fork

And a message with a link to create a merge request will appear in the terminal. Click that link and, once the GNOME GitLab opens, set the target branch on the original project, then click 'Submit'.

Your merge request will likely go through several iterations of reviews. Wait to get comments about how you can improve the work, and then make modifications if they are necessary.

If your merge request is accepted in the first review, you don’t need to do this step, at least this time. Wait until the maintainer merge the merge request.

If you need to modify your merge request it's needed to reset the code changes to the previous commit, but with your changes in the stage area. To do so you can do it with this terminal command (copy your commit message since it will be removed):

git reset --soft HEAD^

Now change the files you need and put them in the stage area as we learnt and commit again. Now you can update the branch with a forced push. For that, type in a terminal:

git push fork --force-with-lease

Note: This will replace the contents of the branch in GitLab with the local content, make sure the local contents are the ones you want to update.

After the branch is updated, the developers will review again and repeat the process until your contribution is accepted.