Creating quality pull requests

(work in progress article)

Github, bitbucket and others are offering great ways to contribute to other projects by forking the project and creating pull requests. In this article I'll share some of my experiences (that I learned the hard way), of contributing pull requests.

Check CONTRIBUTING

Mostly a repository will contain a contributing file or readme section with some guidelines of contributing to the project. Check this section and work through these guidelines.

Contributor License Agreements

Some repositories or companies will need you to sign a Contributor License Agreement. This CLA will allow the company to implement your code within their repository. For an example see: https://cla.developers.google.com/about/google-individual.

Discuss your changes

Often it will be good to discuss your change using the issue tracker. This will allow the owner to give you some instructions or get some background.

Coding

Create a new branch with your changes. Try to reflect the coding style of the repository as much as possible.

Create the pull request

Using clean single-commits in pull requests:

git fetch  
git rebase -i origin/master (or upstream/master)  

Pick the first commit (leave "pick"), and squash the others (start the line with "squash"). If you'll get mergeconflicts, you can resolve them with git mergetool and git rebase --continue.

Test if your merge has been succesfull by running the unit tests again. For example with go you'd use:

go test  
go vet  
golint  

Check the log to see if your commits has squashed to a single one.

git log  

If you've pushed already to master, then you need to force push. Rembember this changes history, and you need to know what you are doing.

git push -f origin master