The perennial problem with discussions of Git workflows is the underlying belief that there exists, if only we can find it, the One True Workflow. This belief is false.<p>Git is a powerful, general tool that lends itself to just about any workflow imaginable and, because of its adaptability, different teams will naturally converge on different Git workflows as "right." These teams, however, have a hard time imagining and thus accounting for the conditions and preferences of other teams, and end up advocating for their workflows as the best workflow.<p>Thus we end up with strongly held and yet contradictory beliefs. Some people claim that "rebasing is a bad habit: it destroys history" while others claim that "rebasing is a good habit: it prevents repo cruft." Who is right?<p>It depends on your preferences, which ought to reflect your team, your project, and your company culture.<p>For my projects, I prefer to edit my work into tight, clean commits before merging them into the mainline branch. That's because I value the <i>logical story</i> of my software's evolution and not the <i>physical story</i>. I want my commits to tell the story that Feature X was built from three sequentially self-supporting changes XA, XB, and XC, not that, while developing Feature X, (1) I was sick for two days, (2) Bob committed an important unrelated hotfix to the mainline tree that (3) I had to work around, and (4) Sally had to later revert Bob's commit. That I was sick, that Bob commited a hotfix, that I had to work around it, and that Sally rolled it back are all real. They happened. But none of those things are fundamental to the nature of Feature X and how I rendered that nature into code. I consider that stuff noise and make sure it's gone before my commits land in production.<p>But that's me. Maybe <i>you</i> care about that stuff. If so, your Git workflow and mine are going to be very different.<p>And that's okay.