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.
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.
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.
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:
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.
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.