Imali smo nedavno diskusiju Pull Request vs Pair Programming, evo jednog kul članka u sličnoj zoni.
…
Iz članka:
Here’s a list of tips to make your Pull Request better. It isn’t exhaustive, but I think it addresses some of the more important aspects of creating a good Pull Request.
A small, focused Pull Request gives you the best chance of having it accepted.
Just as the Single Responsibility Principle states that a class should have only one responsibility, so should a Pull Request address only a single concern.
The reviewer of your Pull Request will most likely be reviewing your contribution using a diff tool. Both GitHub and Stash provide browser-based diff views for reviewing. A reviewer can even configure the diff view to be side-by-side; it makes it much easier to understand what changes are included in the contribution, but it also means that the code must be readable on half a screen.
You may feel the urge to change the formatting of the existing code to fit ‘your’ style. Please abstain.
Before submitting a Pull Request, build it on your own machine. True, works on my machine isn’t particularly useful, but it’s a minimum bar. If it doesn’t work on your machine, it’s unlikely to work on other machines as well.
Assuming that the code base in question has automated tests, make sure all tests pass before submitting a Pull Request.
Again, assuming that the code in question already has automated (unit) tests, do add tests for the code you submit.
Self-documenting code rarely is.
Write good code, but also write good prose. This is partly subjective, but there are rules for both code and prose. Code has correctness rules: if you break them, it doesn’t compile (or, for interpreted languages, it fails at run-time).
Sometimes, a reviewer will point out various issues with your Pull Request, and you’ll agree to address them.
11. Don't do PRs.
Neregistrovani korisnici mogu videti samo jedan komentar — registracija je besplatna i može da traje i samo 10s putem Linkedina. Na ovom postu su još učestvovali: