4 ms·
In my way of working, the 'why' can go into the overall PR and the 'what' into the individual commits. Both are important - the reason for changes and a concise
by VadimPR 4y ago
In my way of working, the 'why' can go into the overall PR and the 'what' into the individual commits. Both are important - the reason for changes and a concise summary if what you've done.
- jiggywiggy 4y agoPRs are not easy to read in the commit history, a year later a commit message is mostly flat without context.
- VadimPR 4y agoDepends on how you merge - I prefer squash (yes, controversial). If you do merge commits, then I agree individual 'why' needs to be within the commit.
- KyeRussell 4y agoNot to make this a merge strategy debate, but this is most of the reason why I’ve opted for squash merging for my team. I’ve been happy for quite some time.
- almog 4y agoI'm not against squash commits, yet assuming you're using it to squash an entire PR into a single commit (so that you get a linear history) and given that you also prefer that "the 'why' can go into the overall PR and the 'what' into the individual commits", then you might end up with a 'what' part that can be hard to understood, that's because squashed commits do not point to the exact code change that they originally referred (unless of course the entire PR is very small).
- lelandfe 4y agoAs I always say in these conversations, PR descriptions and comments are ephemeral. Your git history should be forever, but you’re not guaranteed to be in the same repo on the same host for eternity. I have already worked on multiple projects that got handed to us as a .git/ folder. Commit messages referencing non-existent issues abound. I now make my whole team ensure that nothing crucial is left to live in the PR alone.