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?
I don’t work with merges, so maybe I’m way off base, but I thought they meant, they’re working on another branch or fork, then merging the base branch into theirs every so often to get the newest changes, and then that creates multiple merge commits, which they can’t squash at the end…?
I’m not sure, about that last part, but the rest, I’ve definitely seen with contributors that didn’t know to work with rebases (and unfortunately we’re on GitHub, which only half-assedly supports working with rebases by default).
Yeah, I’m with you. I mean, git isn’t magic. You “can” squash anything, including a merge commit, by just being at the end result, running git reset <commit you want to be squashed offof> and then running a manual git add and commit there. That’s basically all a squash is.
But what you’ll be left with us a single commit that contains all of the code from the branch you’re squashing and also all the code pulled in from every branch you merged, all written as though it all came from this one commit. And maybe that’s what you want? But it feels like also maybe it’s not?
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.
Rebasing is not dangerous. You can always go back if something is not to your liking.
You don’t rebase shared history, you use rebases to craft a clean, quality commit history for your own branches before merging. If everyone does this, then squashing is unnecessary, because garbage commits don’t exist. It is the far superior way of doing things if you actually care about having good commits.
Keeping a quality history rather than squashing also makes many other git tools much better, such as git blame, git revert, git bisect, and so on.
That doesn’t make sense. There’s a world between “garbage commit” and “fancy new feature” and most of it is irrelevant to anything.
I don’t want git bisect to make me check if “run clang-format” broke anything. I don’t want to revert a feature but leave in unit tests that will fail (or worse, the opposite). I don’t care when git blame tells me “rename X to Y”, I want to see the context that motivated this change.
Squashed commits are atomic, built and tested. Anything in between is whatever reviewers let slip in. It’s easier to check a MR description is well written than 5 commit messages (that might get rebased without you noticing)
Rebasing is dangerous if you rebase shared history. If you rebase a local branch, you have to be aware of how much of that local branch you may already have shared.
On top of that, if you’ve got a lot of commits you’re rebasing in a merge conflict that can become extremely repetitive.
So ideally, you only rebase single commits that you haven’t pushed yet. As long as you do that: always pull main and rebase on top of that before you push single commits, rebasing is fine. But the more you deviate from that, the riskier it becomes.
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.
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?
I think it doesn’t really make sense. Because you can’t “squash” one commit. squash is taking multiple commits and making them one.
When you do a “squash merge” you are really saying “squash all the commits that are on this branch and not the target” then merge.
So you can’t “squash a merge commit” you need at least one additional commit to squash in.
I don’t work with merges, so maybe I’m way off base, but I thought they meant, they’re working on another branch or fork, then merging the base branch into theirs every so often to get the newest changes, and then that creates multiple merge commits, which they can’t squash at the end…?
I’m not sure, about that last part, but the rest, I’ve definitely seen with contributors that didn’t know to work with rebases (and unfortunately we’re on GitHub, which only half-assedly supports working with rebases by default).
Yeah, I’m with you. I mean, git isn’t magic. You “can” squash anything, including a merge commit, by just being at the end result, running
git reset <commit you want to be squashed off of>and then running a manual git add and commit there. That’s basically all a squash is.But what you’ll be left with us a single commit that contains all of the code from the branch you’re squashing and also all the code pulled in from every branch you merged, all written as though it all came from this one commit. And maybe that’s what you want? But it feels like also maybe it’s not?
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.
Rebasing is not dangerous. You can always go back if something is not to your liking.
You don’t rebase shared history, you use rebases to craft a clean, quality commit history for your own branches before merging. If everyone does this, then squashing is unnecessary, because garbage commits don’t exist. It is the far superior way of doing things if you actually care about having good commits.
Keeping a quality history rather than squashing also makes many other git tools much better, such as
git blame,git revert,git bisect, and so on.That doesn’t make sense. There’s a world between “garbage commit” and “fancy new feature” and most of it is irrelevant to anything.
I don’t want git bisect to make me check if “run clang-format” broke anything. I don’t want to revert a feature but leave in unit tests that will fail (or worse, the opposite). I don’t care when git blame tells me “rename X to Y”, I want to see the context that motivated this change.
Squashed commits are atomic, built and tested. Anything in between is whatever reviewers let slip in. It’s easier to check a MR description is well written than 5 commit messages (that might get rebased without you noticing)
Rebasing is dangerous if you rebase shared history. If you rebase a local branch, you have to be aware of how much of that local branch you may already have shared.
On top of that, if you’ve got a lot of commits you’re rebasing in a merge conflict that can become extremely repetitive.
So ideally, you only rebase single commits that you haven’t pushed yet. As long as you do that: always pull main and rebase on top of that before you push single commits, rebasing is fine. But the more you deviate from that, the riskier it becomes.
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.