After almost an year receiving valuable code contribution from community through GitLab, some difficulties were found by contributors when trying to organize their forked repositories and create a good merge request. This article presents a workflow to mitigate these common problems on contributor side.
These steps are recommended when contributing trough GitLab: https://gitlab.com/tikiwiki/tiki
- Fork the repository
- Clone the forked repository
- Checkout the correct target branch
- Create a new branch
- Commit changes
- Push changes
- Create a new merge request
- Create an account in https://gitlab.com
- Go to Tiki project page, https://gitlab.com/tikiwiki/tiki
- Click on fork badge at top right corner
- Select the target group you want to place your fork. It will take 15 minutes or more.
The steps below use Git command line, but it can be performed in any Git client embedded in IDE. Also fabiomontefuscolo is the GitLab user in this example and it should be replaced by GitLab user who forked the repository.
$ git clone email@example.com:fabiomontefuscolo/tiki.git tiki
$ git clone firstname.lastname@example.org:fabiomontefuscolo/tiki.git .
As Git will checkout all revisions since the beginning of Tiki (over 50 000 commits), will take quite a while, so you may want to limit this.
$ git clone email@example.com:fabiomontefuscolo/tiki.git . --depth=5
For each major version of Tiki, there is a working branch. If the contribution is a fix for version 19.1 for example, the contributor must checkout the branch 19.x.
$ git checkout 19.x
This is a very important step. It is a good idea to create another branch for the contribution. According to earlier steps, the repository now is set to branch 19.x and a new branch will start from this point. Suppose branch with the name fixing-left-sidebar, the following command will create this branch.
$ git checkout -b fixing-left-sidebar
If for some reason the contributor needs to stop his work and start a new one for the same branch 19.x, he can simply commit or stash his changes, switch back to 19.x and create the new contribution he needs. For example, a new urgent task appeared to fix a security issue:
$ git checkout 19.x $ git checkout -b fixing-xss-issue-on-register-form
In this way, the contributor can have two ore more unrelated jobs (fixing-left-sidebar and fixing-xss-issue-on-register-form) for the same target branch (19.x). It will also help on Merge Request creation. Please see the Atomic commit convention
Even running on GitLab, the community standards for commit messages should be respected. Remember to give a meaningful commit message and prefix it with a suitable tag explained in Commit Tags.
$ git add tiki-file.php $ git commit -m "[FIX] Removing bad characters from registration form to avoid XSS attacks"
In order to have changes available to create a new Merge Request, it is necessary to push the created branch to GitLab.
$ git push -u origin fixing-xss-issue-on-register-form
- Go to forked repository page in GitLab https://gitlab.com/fabiomontefuscolo/tiki
- Then put mouse over Repository and click on Branches entry
- Locate the branch desired (eg.: fixing-xss-issue-on-register-form) and then click on Merge Request button
- On top right corner, click on Change branches and select the correct target branch (eg.: 19.x)
- Write a detailed description. Include steps to reproduce a bug if needed or how to test a new feature
Here is an example: https://gitlab.com/tikiwiki/tiki/merge_requests/18/diffs
Find yours here: https://gitlab.com/tikiwiki/tiki/merge_requests/
Make sure you are respecting the Atomic commit convention
If there is an issue, fix quickly or indicate in the comments that you will do later, or that you need help.
Maintainers may ask you changes on that pull request. In this case, just checkout the branch related to the merge request, add new commits and push it again.
When commands like
git reset --hard or
git push --force is needed, it may be that there is a problem with the workflow and it should be planned again.