I don't know about you but I love the feeling of getting to hit the merge button on my code and sending it off to production. That's our ultimate g...
For further actions, you may consider blocking this person and/or reporting abuse
Good stuff.
Book marked this!
Thanks for sharing Kara!
I believe that the what and why of the PR should be well described in the ticket of the tasks (Jira maybe). Its ID should be present on the name of the branch and its link in the PR comment. The how should probably be clear from the code itself(good naming, small functions, encapsulation, clear API...) documentation and the tests.
All that should minimize the need to explain that in the PR and it is probably more future proof.
Awesome stuff.
Another angle you might approach on the same theme is the technical (this covered the human side very well, and I wish it were obvious, but hey, I'm glad, given it clearly isn't to many, it's got some coverage). The technical side that still befuddles me at times is characterised by the symptom that when I issue a PR on github I am surprised by a sudden explosion in commits! Go figure, I don't understand why, and I'm keen to learn how to avoid it.
The workflow that lands one there is as follows:
The technical workflow for managing upstream, origin and local and a local branch with a change that wants to be a PR, given upstream has moved on since branching ... is what interest me. How to get a clean PR with only the commits I intend to deliver and submit for review is the question I have not solved.
Some great tips in here. Big fan of being your own reveiwer. I always catch something when I review my own PR. It helps avoid wasting other peoples time too
Great
Very good!
Great post!!
Thank you for this great guide. I can only agree with everything you said.
Great perspective. Thanks.
great job !
Wild how much effort and politics go into a pull request in a company. Good advice.
Thanks for sharing