3 ms·
It is also useful for conveying intent. If the commit message describes one thing, and the code does the opposite (or doesn't do it at all), that's something th
by vitus 3y ago
It is also useful for conveying intent. If the commit message describes one thing, and the code does the opposite (or doesn't do it at all), that's something the "gatekeeper" can and should call out.
I've certainly sent out changes for review where I forgot to include a crucial file (or subdirectory).
- withinboredom 3y agoAbout to say this as well, but would like to add. When I have a bug dealing with Foo in Bar, seeing a commit message like “Updated Foo to support Baz\nSee issue #123 for additional context. Also discussed in chat (link).” When looking for a recent bug, I’m going to review that commit immediately without having to do any bisecting/blaming. Easy peasy. Mostly though, I tend to see just “support baz” as a commit message, which drives me bonkers.
- hmeh 3y agoI'll offer a perhaps controversial perspective. What if only people that had context did reviewing? As in, what if when someone needed a review, it was their job to ensure that the reviewer had the context necessary. That is, it was "push" rather than "pull". What if a team's process was set up in such a way that separate phase-gate reviews were not typically necessary. That is, the team tended to work in pairs where there was constant reviewing going on, and the team was practiced at pulling people in when necessary to review specific parts, e.g., things they had never done before or needed additional guidance on. Do we all remember waterfall development? Where PMs would write specs, then they would throw those specs over the wall to devs, who would then throw code over the wall to testers? Does anyone feel like, perhaps, we've done it again with pull requests and we've started favoring asynchronous hand-offs, rather than one-piece-flow?