A presentation at PHP Yorkshire in in York, UK by Lorna Jane Mitchell
A Meritocracy of Pull Requests Lorna Mitchell, Nexmo
meritocracy noun plural -cies • rule by persons chosen not because of birth or wealth, but for their superior talents or intellect • the persons constituting such a group • a social system formed on such a basis https://www.dictionary.com/browse/meritocracy @lornajane
Who Opens a Pull Request? @lornajane
Who Reviews a Pull Request? @lornajane
Pull Request Outcomes @lornajane
CLOSE @lornajane
Small (pull request) Is Beautiful @lornajane
CLOSE @lornajane
MERGE @lornajane
Beware Merge Conflicts Option 1 : git merge —abort Option 2 : edit and add each file, then commit. @lornajane
Special Project Requirements You may be asked to: • Rebase your branch • Squash your branch into a single commit Both of these use git rebase but in really different ways! @lornajane
Rebasing @lornajane
Rebasing @lornajane
Rebasing 1. git 2. git 3. git 4. git 5. git checkout master pull checkout feature rebase master push -f <— use with extreme caution @lornajane
Squashing Uses “interactive rebase” - rewriting branch history. 1. git rebase -i [base commit] 2. Text file is ordered oldest to newest! 3. Edit, re-order or remove lines as desired 4. Instructions are in the file: f for fixup just adds this commit into the one before @lornajane
Commit Messages https://chris.beams.io/posts/git-commit/ @lornajane
REVIEW @lornajane
Do not view the diff @lornajane
REVIEW @lornajane
Do not view the diff @lornajane
REVIEW @lornajane
Do not view the diff @lornajane
REVIEW @lornajane
Language Matters You “review” a pull request. You don’t “merge” one. @lornajane
REVIEW @lornajane
Diff and DiffTool Tricks git diff master…HEAD <— everything on this branch, regardless what has happened on master since Configure your difftool and then replace diff with difftool in any command to get a graphical interface @lornajane
Automate All The Things @lornajane
The Art of Feedback @lornajane
If you didn’t run the code, you didn’t review the PR. @lornajane
OPEN @lornajane
Pull-Request Ready? Your project is pull-request ready if: • It has a README • There is a CONTRIBUTING.md file with expectations in • Build/tests run when a PR is opened • (optional) A pull request template outlines dependencies @lornajane
A Meritocracy of Pull Requests
Resources • https://joind.in/talk/b45a3 • https://gitworkbook.com • https://lornajane.net • https://github.com/matthewmccullough/scripts And, of course: http://octodex.github.com @lornajane
We often speak of open source as a meritocracy; everyone’s patches are welcome. However with git used in the workplace as well as open source, being good at pull requests is a key career skill for all developers. This talk combines git tips, psychology and years of experience to present key information on working with pull requests. How to open one in a way that will make it more likely to be accepted without drama. How to review and evaluate a pull request so you don’t regret it in the morning. How (and if) to merge pull requests, including those big words like rebasing and squashing. And how to close them, merged or not. This talk recommended for everyone who uses pull requests and wants to work on this key skill.
