Skip to content

Instantly share code, notes, and snippets.

@4383
Created October 12, 2017 14:17
Show Gist options
  • Save 4383/8ca87db24b7ac7e0d328b33ef654923a to your computer and use it in GitHub Desktop.
Save 4383/8ca87db24b7ac7e0d328b33ef654923a to your computer and use it in GitHub Desktop.
Pull request / Merge request workflow

Your feature or fix are currently done in your fork you must create a merge request on the upstream project for spreed your changes to others contributors.

In gitlab GUI open your fork (normaly in your namespace), if you've pushed your branch into your fork repository a new button has available in the GUI create merge request, so click on!

The page loading a new merging form, you must fill it! At start you must select the king of merge request in the selectbox available (example: doc/fix/feat) and respond to asked questions.

Once you have filled out the form, you must inform commiters team by ping them, so you need to send message by starting a discussion in your merge request. For that:

@commiters need review

Now commiters group affect the review to a member of the project team (it's can be a commiter or a contributor). Reviewer check the changes and can discuss about this, or directly reject or validate changes.

For rejecting the changes reviewer must send a comment to commiters group:

@commiters changes required

Now commiters are notified about the reject and reaffected the merge request to the author for changes. In this case the author must implement review comments and commit changes and ask for a new review (cf. need review).

workflow restart...

If the new review validate changes, reviewer must send a discussion comment for approval that:

@commiters shipit

Commiters are notified of the review success and merge the request to the upstream.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment