4 ms·
AFAIK it's usually to keep the git history clean but doing it manually is so painful. In my company, we enabled GitHub's "Squash and Merge" option (1) so we hav
by mportela 5y ago
AFAIK it's usually to keep the git history clean but doing it manually is so painful. In my company, we enabled GitHub's "Squash and Merge" option (1) so we have the best of both worlds: a clean history and an 1-click squash process.
(1) https://github.blog/2016-04-01-squash-your-commits/ https://github.blog/2016-04-01-squash-your-commits/
- julenx 5y agoWith GitHub's squash + merge, clean history still depends on the person doing the merge, because when clicking the squash + merge button, GitHub places all commit messages in one large chunk of text, which devs are able to edit before confirming the merge, but it takes some discipline to do so. In my experience, devs rarely pay attention to this, so commit messages end up as a big list of: * Ticket-1234 feature * fix * cleanups * fix * another fix * now the real fix Which I wouldn't qualify as a contributor to a "clean" history. It'd be great if GitHub's UX around crafting the commit messages would be more considerate and foster more meaningful commit messages. (edit: formatting)
- avgcorrection 5y agoThis is exactly what happens in practice.
- avgcorrection 5y agoThere’s nothing particularily clean about a multi-week pull request with 50+ commits getting squashed with all the commit messages concatenated together as bullet points. I’ve tried to go back to commits/issues like that and it’s hard to understand what one section of the commit message corresponds to in the diff. There’s no way to automate version control.