I think the people well-versed enough in git to use "git add -p" to review their own changes, and commit them separately, are the same people that would correctly test their commits.
At least from my small sample size of people, that is true.
This is definitely not true for the outsource companies here in the 3rd world.
It gets even worse when you face people who have used SVN for years. Once they realize that they can commit non-working code on their feature branch as long as the result of the final merge into master is OK, they start to dump random work-in-progress stuff into git repo. As the result, blame and bisect are completely broken, but who cares, that's another developer who would feel the pain trying to make sense from the changeset history two years from now, not you.
One way to mitigate that is to always squash-merge the suspect work. In some orgs, it's really hard to establish a culture of good "git hygiene". Typically CI is already branch-focused, and the merging process after CI/review/etc. is tailored to just throw out the "noise" from the incoming branches.
This also handles issues such as staff who just don't get that long-lived, continually remerged (from master) branches are evil when viewing history using `git log --graph` or similar GUI views.
Comments
I think the people well-versed enough in git to use "git add -p" to review their own changes, and commit them separately, are the same people that would correctly test their commits.
At least from my small sample size of people, that is true.
This is definitely not true for the outsource companies here in the 3rd world.
It gets even worse when you face people who have used SVN for years. Once they realize that they can commit non-working code on their feature branch as long as the result of the final merge into master is OK, they start to dump random work-in-progress stuff into git repo. As the result, blame and bisect are completely broken, but who cares, that's another developer who would feel the pain trying to make sense from the changeset history two years from now, not you.
One way to mitigate that is to always squash-merge the suspect work. In some orgs, it's really hard to establish a culture of good "git hygiene". Typically CI is already branch-focused, and the merging process after CI/review/etc. is tailored to just throw out the "noise" from the incoming branches.
This also handles issues such as staff who just don't get that long-lived, continually remerged (from master) branches are evil when viewing history using `git log --graph` or similar GUI views.