I use rebase often: I develop on a feature branch, experiment there a lot, and before I push it, I rebase it to squash the thing into more managable and straigh

I use rebase often: I develop on a feature branch, experiment there a lot, and before I push it, I rebase it to squash the thing into more managable and straightforward pieces. (I push my branches public when they're ready, and when I won't rebase them anymore) For example, there's this project where the test environment is on another system, and I hardly ever test locally. So when I break something, there's a good chance I won't notice that until the test runs. At that point, I make a small commit to fix it. I could push that all out, and merge the whole thing onto my master branch, but that would be a lot of useless clutter: development mixed with random fixes. I prefer my development line reasonably clean, so I rebase & squash things together before making them public. This doesn't mean that my whole feature development will be one big patch, no. But it will be a series of clean changes, as it should be. Easier for everyone to understand later. One line of development will look like a smooth, linear progression, but there can be many similar feature branches, which get merged to master at various points, and that line will not look all that linear. Smooth - hopefully, but not linear.