GitLab/Workflows

= Introduction =

GitLab is a code hosting, review, and continuous integration platform. We're running a community consultation on moving from Gerrit to GitLab for Wikimedia code review.

This aims to be a tutorial describing workflows for using our trial GitLab instance for Wikimedia development. Depending on the result of the consultation, it may evolve into a reference for production use.

Add an SSH key
Visit the SSH settings in your profile and add a public key. See the GitLab documentation for more details on this process.

= Making a GitLab Merge Request =

Create a branch
Use the convention :

Make your changes
Write some code and save your changes.

Stage and commit your changes
Let's say you've edited the  in. You should be able to see this using :

Stage the file and commit:

You should now be able to see this commit in the log:

Fork the repository
If you don't have developer-level permissions on the project you'd like to contribute to, you'll first need to copy the repository to your own account. This is known as "forking". Visit the repository page, for example gitlab-test.wmcloud.org/mediawiki/core, and click "Fork" in the upper righthand corner.

Next, add a remote for your fork:

If you've done this successfully, it should show up in your remotes:

Push your commit to GitLab
If you have commit access, you can push directly to a branch on the origin with.

If you're using a fork, push instead to the remote you added above with.

Create a Merge Request on GitLab
You may notice that GitLab responded to the push with a link to create a new merge request from your branch. You can follow that link directly, or visit the trial GitLab instance, navigate to the branch list for the repository, and click the "Merge request" button in the listing.



Provide an informative title and description for the merge request, and @-mention the users you'd like to see review your code.

Merge options
In the "Merge options" section:


 * Check "Delete source branch when merge request is accepted" to avoid cluttering the repository with already-merged feature branches.
 * In the general case, you should use "Squash commits when merge request is accepted".
 * This can be omitted if you plan to submit a merge request containing multiple commits.
 * If the logical structure of your change dictates multiple commits, you may use interactive rebase to achieve the desired history and force push to your work branch before merge. This is an advanced workflow, but supported.
 * Check "Allow commits from members who can merge to the target branch", unless you have a specific reason to prevent others from making changes.

Making new commits
Typically, you'll just make a new commit on your work branch, as usual, and push to the correct remote:

Or:

The new commit makes it very easy for reviewers to see what changed since they last saw the merge request, and will be squashed into the other commits when the pull request is merged, assuming that the pull request is set up to squash commits on merge (as recommended above).

Force pushing to a branch
If, instead, you wish to rewrite the history of the branch, for example by altering an existing commit or rebasing your work on top of upstream changes, GitLab allows force-pushing to a branch that's associated with a merge request.

This is mainly suitable for merge requests which are not meant to be squashed on merge, typically because they contain two or more commits that should remain separate. In that case, you clean up the history locally and then force-push it to update the merge request.

TODO: I wonder if it would make sense to still push  commits without force-pushing, and only do a  +   from time to time? I like the idea of this, but the autosquash feature is probably too complicated or confusing to users not familiar with it if there isn’t good support for it from the GitLab UI. --Lucas Werkmeister (WMDE) (talk) 17:19, 16 October 2020 (UTC)