4 ms·
When you work on a team that requires code reviews (pull requests) before every check-in, the "body" portion of the commit does not really make sense as the dev
by webo 11y ago
When you work on a team that requires code reviews (pull requests) before every check-in, the "body" portion of the commit does not really make sense as the developer pretty much has to include that information in the code review description either way.
Most teams automatically put a link to the corresponding code review in the commit message/body.
- ReidZB 11y agoOn GitHub, single-commit PRs automatically have their body text set to the body text of the commit. (Annoyingly, GitHub doesn't reflow the body text, so it looks "jagged"...) For multiple-commit PRs, I usually just give some surrounding context and let the reviewers read each commit message separately (with the three dot button).
- unfunco 11y agoI'd still prefer a body with a good commit description, since review descriptions are not attached to the history. I've been thinking about this a little recently, the conversations that determine the direction of a product are not part of the history, if a repository is shared there's no way to see that information without going through emails, or going through issues on GitHub or Bitbucket or whatever else.
- webo 11y agoIs this something we can change though? As you mentioned, these conversations happen everywhere including offline meetings and hallway chats.
- e28eta 11y agoAt work they're consolidating systems, and we might lose our entire code review history. Having some redundancy isn't necessarily a bad thing.