* Describe what your branch does and what testing you've done: don't rely on commit messages.

* Click 'Submit new merge request'

* Notify the main maintainer(s) of the project (they should receive an email, but...)

Making a Merge Request will send an email to the person you assign it to, and will show a diff of your branch versus the branch you are asking to merge your changes into. Follow the steps below to make a Merge Request in GitLab:

Your changes will be reviewed, and the maintainer(s) may have follow up questions for you or may ask you to make some changes, or squash some commits and generally clean things up.

1. Describe what your branch does and what testing you've done: don't rely on commit messages.

1. Click 'Submit new merge request'

Now your changes are ready to be reviewed. The project maintainers may have followup questions for you or ask you to make changes.

Make any changes, as needed, and comment on the Merge Request when you are ready for another review. As long as you push your changes to the same branch of your initial Merge Request, you should not need to create another one.

### Bringing in Changes

This is a heated topic in some circles; some people prefer merging and merge commits, where others prefer a cleaner history and rebasing. The style should be determined by the maintainer(s), I personally prefer rebasing.

If you are the maintainer of a project, you may need to respond to Merge Requests and occasionally bring changes in to the 'production' branch from contributor's forks or branches.

How you bring those changes in depends on your preferences; some people prefer merging and merge commits, where others prefer a cleaner / more linear history and using 'rebase'.

If you are responsible for maintaining a project, do yourself a favor and read about the various methods people use for bringing in changes.

I'd rather leave this hazy, for the time being, until people get more familiar with git; information about both methods is readily available.

Merging is easy, especially within GitLab, because it can essentially all be done through the web interface using Merge Requests. Rebase (in my opinion) provides a clearer linear history of the project, but requires more understanding of git than this simple guide strives to impart.

Merging is easiest, especially with GitLab, because it can essentially all be done through the web interface.

[Information on rebasing](http://git-scm.com/book/en/v2/Git-Branching-Rebasing)