I agree but one thing I've realized recently is how all the history and discussion happening in a PR tend to be lost once the PR is merged. Not completely lost because it's still there in the "closed" PRs, but undiscoverable.
For example, you come across one line that doesn't make sense to you but you sense that there's a reason behind it. 'git blame' will tell you the specific commit but the commit message might not be explicit and you won't be able to find the corresponding pull-request easily.
I mentioned it on Twitter and exchanged with a GitHub employee that seemed to understand my issue. Hopefully they'll improve on that…
4. the sneaky commit
when do I use it?
after the code has been reviewed and merged into master
I need to make a small change (eg a copy change or
bugfix) that’s not even worth notifying others about
what I do
just push the new commit to master.
I will note that github has being particularly prolific in getting git advice out there, they're working to educate developers in git, full stop. Though one or two pieces (such as this one) seem to suggest it's github specific advice.
This has not been my experience at all, it seems to loose non-line comments always, and line comments sometimes.
---
In any case, I've been doing a lot of work on the Rust language recently, and there is an integration bot ("bors") which detects `r+` comments on the last comment on a pull-request, then runs 13 different configurations of the full test suite (4 platforms, 2 architectures, optimisations on/off, with/without valgrind; although not all combinations of these). If (and only if) all 13 test runs pass, the bot automatically pushes the commits to master.
(Almost) all commits go through bors, with increasingly less common pushes straight to master to get the test suite to pass again after some breakage. (The test suite used to only with 3 configurations for each pull request, so breakage occurred semi-often.)
(An example, https://github.com/mozilla/rust/pull/7693)
When it works, it is really nice; get someone to review, they approve it and the whole process is managed from there, no mistakes possible. (However, apparently the GH api is unreliable, so bors has moments of madness.)
The sneaky commit will get you many frowny faces on chat.
It works rather well. Does anyone else work like this?
Our development process does include pull requests, and code review is mandatory (with the number of reviewers configurable at some level), as is a successful build from Jenkins. Stash's UI will not permit a merge operation without satisfying those criteria. There's also a restriction on the master branch so the sneaky commit isn't even possible.