2 ms·
A couple jobs ago, I was at a company that had a "mandatory" squash / rebase / merge workflow so history would be clean. On top of that, they forced all their d
by icedchai 4y ago
A couple jobs ago, I was at a company that had a "mandatory" squash / rebase / merge workflow so history would be clean. On top of that, they forced all their developers to update a change log as part of the merge. That file was a source of contention / merge conflict for nearly every PR, often requiring additional rounds of rebasing. On top of that, it was full of information that could've been gathered from the git log. Big waste of time, in my opinion.
- ChadNauseam 4y agoWe had something kind of similar, but designed to avoid merge contention. We had each PR include a randomly-generated number, and a `changelogs/` folder where you could add a `${number}.md` that was either blank or had a message that would be added to the changelog. After you made the PR, you could run a bash script to edit the PR to contain the number and generate the `${number}.md` file. It felt kind of silly and I don't know if anyone actually looked at the changelogs, but it took 2 minutes out of my day and worked well.