I never thought about it and instantly wanted to reply “wait why can’t you do that‽” but now that I thought about it, what would you want the history to look like in that case?
A slightly weird rebase?
A single commit which seemingly copy pasted the entire other branch with no relation to it left behind?
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’m not a fan of changing history in general. Rebase can also he dangerous.
I think ultimately it’s a matter of scale. Sometimes it can be useful to look into the details of the development of a single feature, but in a large project, that rarely happens. I’m not a fan of squashing, but for large projects, it helps to keep your history manageable.
I never thought about it and instantly wanted to reply “wait why can’t you do that‽” but now that I thought about it, what would you want the history to look like in that case? A slightly weird rebase? A single commit which seemingly copy pasted the entire other branch with no relation to it left behind?
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’m not a fan of changing history in general. Rebase can also he dangerous.
I think ultimately it’s a matter of scale. Sometimes it can be useful to look into the details of the development of a single feature, but in a large project, that rarely happens. I’m not a fan of squashing, but for large projects, it helps to keep your history manageable.