Some of what you say makes it sound like your workplace doesn't do code reviews. Reviewing changes submitted as incoherent batches of commits is a pain, to put it nicely. Especially if they're large commits. Especially if they're so incoherent that there are a bunch of changes mixed in that are completely unrelated to the change I'm reviewing.
No, code reviews are really simple. Do a PR on GitHub, or BitBucket, or whatever you use and you get a diff of ALL the changes in a branch. If you don't use those tools, you can always do a merge locally and view the full set of changes. I've been doing this for quite a few years and there is no problem in viewing all the changes in a feature branch.
Just learn to use the tools you have instead of making everyone spend extra effort.
The tools can't exclude a bunch of irrelevant changes if they're submitted with the code to be reviewed. Instead of the submitter doing a little extra work they're forcing the reviewer to.
The tools can't explain why changes were made when a bunch of commits have a single comment that doesn't explain anything, like "feature completed". Instead of the submitter doing a little extra work they're forcing the reviewer to.
If everyone learned to use the tools well there wouldn't be these problems, obviously, but it's clearly not as black and white as "Commits absolutely do NOT need to be some coherent chunks".
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.
Some of what you say makes it sound like your workplace doesn't do code reviews. Reviewing changes submitted as incoherent batches of commits is a pain, to put it nicely. Especially if they're large commits. Especially if they're so incoherent that there are a bunch of changes mixed in that are completely unrelated to the change I'm reviewing.
No, code reviews are really simple. Do a PR on GitHub, or BitBucket, or whatever you use and you get a diff of ALL the changes in a branch. If you don't use those tools, you can always do a merge locally and view the full set of changes. I've been doing this for quite a few years and there is no problem in viewing all the changes in a feature branch.
Just learn to use the tools you have instead of making everyone spend extra effort.
The tools can't exclude a bunch of irrelevant changes if they're submitted with the code to be reviewed. Instead of the submitter doing a little extra work they're forcing the reviewer to.
The tools can't explain why changes were made when a bunch of commits have a single comment that doesn't explain anything, like "feature completed". Instead of the submitter doing a little extra work they're forcing the reviewer to.
If everyone learned to use the tools well there wouldn't be these problems, obviously, but it's clearly not as black and white as "Commits absolutely do NOT need to be some coherent chunks".
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.