Comment by codingdave
7 days ago
I've never worked on a team that had conventions for both commits and PRs. In general, the goal of such things is to help trace work across multiple systems, and for future research trying to track down old changes. All the places I've worked or consulted, they do that at the PR level, not the commit level. So PRs will start with a ticket #, commits are freeform.
That being said, some places do have commit standards. Just ask the team what they do when you start somewhere. Don't bring conventions in where a team doesn't use them - it just adds noise. If you or the team see how adding conventions can benefit your work, talk about it and make a decision together.
Good thing Microsoft has never been evil. Otherwise, one might be concerned about locking up your project's history in Github's/Microsoft's proprietary issue tracker (embrace, extend, extinguish!) rather than open source tools like Git that you can migrate out of.
Oh gosh yes, that sure would be dangerous to lock everything into Github. I've never worked on a team that did so, though. To be honest, I've never used Github's issue tracker at all. Seeing as PRs are also commits when they merge, PR-level tracking migrates just fine to any other system you'd like.
Why not just use the commit message then? What benefits do you get from building your workflow around the proprietary PR interface?
1 reply →