I’m an imperfect human, but I don’t always see the value in having 5 commits that say “fixes lint error” and another few “fixes typo” in the git log for every feature branch. Perhaps there is a middle way.
There are also technical reasons to separate commits. Moving files is best done in a separate commit, otherwise --follow might not work as you might expect. Squashing that together with changes might very well break that logic.
Always rebase before pushing for review, just don't squash everything. One would hope that much would be self evident.
A PR may contain several distinct meaningful related commits, this has nothing to do with typo fixes.
But even then, when you want to revert or cherry-pick a commit on another branch, you don't want random unrelated changes (which increase the risk of conflicts).
Also, a single commit containing 10 squashed commits doesn't help for git bisect.
I do minor history rewrites on my feature branches all the time.
1. Fix typo or other small nit.
2. `git add -p` to add only the small change.
3. `git commit -m fixer`
4. `git stash`
5. `git log --oneline main..` and copy the SHA of the commit I want to fix.
6. `git rebase -i SHA~`
7. In the text editor launched by `rebase`, move the "fixer" commit after the one I want to modify.
8. For the `fixer` commit, change "pick" to "fixup". Save and quit, allowing the rebase to complete.
9. `git stash pop`
This works most of the time, so long as the nit I want to fix isn't too far back in history. For those nits that aren't easy to fix with the workflow above, I just create an ordinary commit and leave it. It's annoying to have 5 "fixes lint error" commits in every feature branch, but it's fine to have them every once in a while.
`git commit --fixup` and `git rebase --autosquash` automate a bit of the drudgery for this workflow. Sharing because I just got introduced to them recently.
I guess that depends on how detailed the commit messages are and how many changes they have, which will be affected both by the specifics of the project and the people in it.
Consider the following:
[8 files changed] ISSUE-541 added DB migrations and repositories for the new functionality of managing Foos
[2 files changed] ISSUE-541 refactor the DB migrations to do Bar before creating one of the views because of it breaking otherwise due to Baz
[11 files changed] ISSUE-541 refactor old services to use the new Foo functionality, because it should be more consistent than using native queries with complex SQL
[3 files changed] ISSUE-541 fix problems with fetching data in some of the old services, because edge cases were not covered, add unit tests to cover this functionality
[7 files changed] ISSUE-541 add services for managing Foos, though they will only be used in ISSUE-544, add comments about this
[20 files changed] optimize the imports in the Foos package and remove unused code (should automate this later)
In one of the cases, the changes are larger and therefore more meaningful descriptions of what each commit does are probably a good thing - if the refactoring of code would break anything that wouldn't be immediately apparent but would later be detected, being able to click in the commit in the IDE history and see what exactly was changed as a part of it could be pretty useful!
Whereas in the other case, there are fewer files changed, so the pattern that i've seen emerge is that most people won't care much about detailed commit messages, because of which it is no longer that useful.
Of course, i've also seen people (the majority of my coworkers, though it depends on the company) not really care about commit messages or even making smaller atomic commits at all, thus a feature branch could look like the following:
Then again, the majority of people in my current company also always leave merge request descriptions completely empty and expect you to figure out what the code does by its contents alone in the diff, without providing any context or further considerations. Personally, i'm against this and while i don't want to sour our relationships by nagging about it, personally i always write out a bit of information about what each feature branch accomplishes, as well as even include a few images or GIFs.
That has made my own life much easier when something seemingly breaks 9 months down the line and no one has any idea why, whereas i can just look at the merge request for the offending code and see all of the charts and explanations i need.
Personally, i think that the closer your documentation (of any sort) is to your code, the better the end results.
> In one of the cases, the changes are larger and therefore more meaningful descriptions of what each commit does are probably a good thing - if the refactoring of code would break anything that wouldn't be immediately apparent but would later be detected, being able to click in the commit in the IDE history and see what exactly was changed as a part of it could be pretty useful!
This has happened to me when tracking down bugs a whole bunch of times in our various svn codebases, where commits can't be squashed like in git. Once it even happened in a linting commit when someone accidentally messed up indentation in python.
That's a problem I avoid by spicing the log with commit messages from http://whatthecommit.com/ ! :)