[deuill]

I always felt that rebasing as part of a workflow was part lack of discipline when creating commits, and part desire to hide work that is incomplete or "imperfect".

As with most things, there's no silver bullet that applies to every single case; different workflows work best for different teams and projects. Gitflow is both reasonable and fairly simple to understand and implement, but so is commiting straight to master and tagging "when it's done" for a single-person hobby project.

There's also no free lunch, and maintaining a clean history (whatever that means) takes more effort than just applying a set of rules (such as, always rebase, squash commits) after the fact. Linus Torvalds has said it better than I could ever do[0].

As far as the article itself goes, the author maintains that:

> A few common commits on my branches are: “WIP,” “Run Rubocop,” and “Fix typo.”

And then goes on to say that the solution to this is to rebase, rather than creating better commits from the get-go, or just deferring any commits until the end of the feature work, and then staging interactively in order to create multiple thematic subdivisions, or just commiting the entire workspace.

[0]: http://www.mail-archive.com/[e-mail]/...

[mkiwala]

> that rebasing as part of a workflow was part lack of discipline when creating commits

Because we have rebase, there is not as much need for discipline when creating commits, because you can change change them later.

> and part desire to hide work that is incomplete or "imperfect"

When I do any kind of work, I usually submit the finished work to whomever needs it. It's not hiding, it's just giving people what they need.

When I use `rebase -i` in my workflow to alter my commit history, it's almost always for the purpose of helping code review. I want my commits to lead a reviewer logically down a path that helps them understand the role each change makes in a push request.