So don't commit irrelevant changes to your feature branch, this falls upon the "blind commits" -category of problem.
The best way to explain why certain changes were made is not in the commit messages as you should not review separate commits but the end result of the work in the feature branch.
What I do if some change is unclear is usually one of the following:
Add a comment in the review/PR myself
Add a comment in the code
Refactor it so it's clear
Oh and if you don't know which of the changes you made are relevant to your feature branch anymore you don't commit often enough.
Like @Duke here, my team does frequent PR reviews and frequent merging (and once we have our CD stuff fixed, we'll be releasing on merge) and we don't have a problem with commit messages as they're mostly a personal thing that doesn't survive the merge (due to squash merging).
Master is kept clean by just squash merging. Individual commits are for the individual(s) who is(are) driving the branch. Usually the branch scope is small enough that it only lives for 1-2 people for maybe a week or so. (Also, you're not allowed to merge your own PR.)
But most of the time, it's too much a hit to individual productivity to worry about mandating a certain commit cadence or making messages be meaningful beyond a few hours after merging.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
So don't commit irrelevant changes to your feature branch, this falls upon the "blind commits" -category of problem.
The best way to explain why certain changes were made is not in the commit messages as you should not review separate commits but the end result of the work in the feature branch.
What I do if some change is unclear is usually one of the following:
Oh and if you don't know which of the changes you made are relevant to your feature branch anymore you don't commit often enough.
I agree, and hopefully can add to this a bit:
If you're having problems with unrelated work sneaking into a branch, then you probably have one or more of the following issues:
Like @Duke here, my team does frequent PR reviews and frequent merging (and once we have our CD stuff fixed, we'll be releasing on merge) and we don't have a problem with commit messages as they're mostly a personal thing that doesn't survive the merge (due to squash merging).
Master is kept clean by just squash merging. Individual commits are for the individual(s) who is(are) driving the branch. Usually the branch scope is small enough that it only lives for 1-2 people for maybe a week or so. (Also, you're not allowed to merge your own PR.)
But most of the time, it's too much a hit to individual productivity to worry about mandating a certain commit cadence or making messages be meaningful beyond a few hours after merging.