I am one of those who would insist on correctly splitting commits. Commits are a communication tool, and a well-crafted series of commits makes reviewing pull requests, which is a chore for most people, a lot easier. Months or years later, it is still important to easily review changes.
In a Gitflow repository I don't particularly like squashing feature branches since a sequence of commits allows the author to better document what they were thinking about. Squashing is fine in Trunk-based development since feature branches are usually less extensive.
I hate intermediary merges on feature branches because they tend to make up a large portion of the branch history and are harder to review than normal commits.
In a Gitflow repository I don't particularly like squashing feature branches since a sequence of commits allows the author to better document what they were thinking about. Squashing is fine in Trunk-based development since feature branches are usually less extensive.
I hate intermediary merges on feature branches because they tend to make up a large portion of the branch history and are harder to review than normal commits.