...
4: Pull against master. Always create pull requests on OpenMRS's master branch, unless the ticket description or comments specifically say otherwise. The reviewer of the pull request will always take care of backporting your changes to other branches, whenever necessary. In theory below the title of your pull request in Github, there should be a line saying something like 'XYZ wants to merge 1 commit into openmrs:master from XYZ:master'
5: Update first. Pull the latest changes from upstream and resolve conflicts if any. Use this command: git pull --rebase upstream master
Although you may have run this command as you started working on the ticket, you need to run it again immediately before creating the pull request. The reason for this is that there could be changes committed upstream during the time when you were working on the ticket. If you find yourself taking more than a day to complete a ticket, ensure that at the beginning of each day you work on the ticket, you pull the latest changes by running this same command.
...
7: Follow our coding conventions. Make sure you have read and followed our Coding Conventions. Please read them carefully and check the diff of your commit. Make sure your IDE is properly configured as explained. This helps reduce the time we need to review your code.
8: Avoid a noisy pull request. When committing, you may at times see files to be committed, which you did not intentionally change. Some could simply have formatting changes as a result of running mvn clean install. Please ensure that you do not include any such files in your commit.
9: Squash! The best practice is to commit at the level of an idea (feature/fix). While you may have made 10+ commits while you worked, before you submit a pull request, make yourself look even smarter as if you knew how to do it all at once by "squashing" your changes into one that addresses the ticket. For example: git rebase -i HEAD~3, where the "3" in HEAD~3 is refers to the number of prior commits you want to squash and then git commit.[ref]
Large features may be done across a handful of commits, but most bug fixes and small features can be squashed into a single commit, making the commit history easier to follow.
Consider squashing when creating a pull request; don't worry about squashing subsequent commits performed in response to the reviewer(s) comments. Ultimately, the person merging the pull request will perform a "squash on merge" via GitHub to make the final result appear as a single, clean commit.
...
Lastly, please make sure that you have the Using Git page, especially the "Submit the code" section.