Make sure the bug is in Trac. Usually it is (that's why you are working on it), but if it's a bug you have found yourself, add it to Trac 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 Trac #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.
Please try to follow the general convention for the Git commit message structure as many Git tools rely on this. Moreover, take into account that the commit message text is interpreted as WikiFormatting in Trac.
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 Trac, 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.
Files in GHC repos should use Unix conventions for line endings.
If you are on Windows, ensure that git handles line-endings sanely by running:
git config --global core.autocrlf false
Test your commits using the validation script or Travis. Alternatively, you can let Harbormaster build and validate your commits, see next step. (If you have write permission to the repository, then you must validate before pushing.)
Submit one or several code reviews to Phabricator. Wait for Phabricator/Harbormaster to build and validate your commits (bug minutes each, September 2014).
Alternatively: Create a Pull Request on GitHub. This variant should only be chosen for simple changes that are likely accepted without much review.