A risk of allowing too much bureaucracy in commit processes is that engineers try to avoid the slowdown as much as possible. For example, several unrelated cha

A risk of allowing too much bureaucracy in commit processes is that engineers try to avoid the slowdown as much as possible. For example, several unrelated changes may bleed together into “super commits” so as to clear bureaucratic hurdles only once. Next thing you know, it’s harder than ever to identify the exact cause of any one issue: you have more changes in each commit, fewer comments than ever, and a high probability that no thorough review was really conducted. Large blobs make the review process completely fall apart. In the past I dug up too many cases of people allowing 50-file steamrollers into a repository when the entire “review” was literally two words (“looks good”). While this probably happened due to time constraints, it makes the entire thing pointless. With a simpler commit process, engineers might submit smaller change requests at a time and people asked to review “7 files” might do a thorough job instead of balking at requests to review “50 files”.