Make sure the bug has a GitLab issue. Usually it is (that's why you are working on it), but if it's a bug you have found yourself, add it to GitLab before you start work. It's important to have a ticket, because it makes sure that the bug report, discussion about the fix, the regression test that checks it, and the eventual conclusion, are all recorded together. Comments in the code can refer to the ticket (e.g. See issue #2382 for an example). And so on. If there's no ticket, there is every chance that it'll get lost.
Comment your fix in the source code, and include a reference to the bug ticket number, e.g. "#1466" (this helps when grepping for the fix later).
GHC is guaranteed to compile and validate with the last two GHC releases; write your patch with this in mind. For instance, if you are working on what will be GHC 7.12 your patch should compile with GHC 7.8 and GHC 7.10.
Make one or several commits that embody your fix.
Separate changes that affect functionality from those that just affect
code layout, indentation, whitespace, filenames etc. This means that
when looking at patches later, we don't have to wade through loads of
non-functional changes to get to the important parts of the patch.
include the ticket number in the form "#NNNN" in the commit message, e.g.
withMVar family have a bug (fixes #767)
Git will then add a link to the commit from the ticket (as soon as the commit becomes reachable from the master HEAD), so that people watching the ticket can see that a fix has been committed, and in the future we can easily find the patch that addressed the ticket. When navigating the Git history on GitLab, you will also be able to jump directly to the ticket from the commit.
Please make sure you have setup git to use the correct name and email for your commits. Use the same name and email on all machines you may commit from, or add an entry to the .mailmap file in the ghc root directory.