Elliot Chance
Jul 29 · 2 min read

Thanks Fredrik for the original article. I know it’s been pointed out that squash is an option and some arguments have been raised against it. I have worked at companies where rebasing features was required and it certainly has it advantages (more than just vanity) but also had its pitfalls. I have also worked in companies where any change to history is frowned upon and there are just as many disadvantages with this method.

I only exclusively use squash now — it’s the best of both worlds. I’m not discounting the arguments against it. No strategy is perfect, or we would all be using that one.

The biggest failing with merging or rebasing is that you are always left with commits that are broken for CI. Whether you like it or not, this is the reality. You either get tons of “fix test”, “minor” commits or you get rebased commits that have not been tested in isolation and break when bisecting (which makes them useless).

If a small commit (despite being an isolated change) could not belong as a application release itself, it’s actually no use being isolated. The intent of the change should be a commented in the code more so than the commit message.

On the other hand, having a feature be rebased into 10 commits (let’s assume they are perfectly isolated and tested individually, which never happens) is less helpful to me because I want to see the entire change most of the time to get a complete context. A large patch isn’t objectively more difficult to debug than a small patch. That’s why we have error messages and stack traces.

    Elliot Chance

    Written by

    I’m a data nerd and TDD enthusiast from Sydney. I love exploring new technologies and working on modern ways to solve age old problems 🤓 elliotchance@gmail.com