Sometimes you really don’t want to look over the commit history of your colleagues. As long as it’s a small feature, a single commit is a pretty good option.
I like squash merge on small changes, but when larger code changes are there it becomes a huge commit which is difficult to review if you ever have to go back.
It’s fine if the changes belong in a single commit. Otherwise, an interactive rebase to craft a clean, quality history before merging is much, much better.
Sometimes you really don’t want to look over the commit history of your colleagues. As long as it’s a small feature, a single commit is a pretty good option.
Rather than:
That’s basically my commit history for every repo where I need the pipeline to run to see if everything works.
Haha same. But that’s why you do it in another branch, and then squash-merge.
I like squash merge on small changes, but when larger code changes are there it becomes a huge commit which is difficult to review if you ever have to go back.
It’s fine if the changes belong in a single commit. Otherwise, an interactive rebase to craft a clean, quality history before merging is much, much better.