Accepting a messy git history

GitHub recently introduced stacked pull requests, prompting a lively debate among developers about their approach to version control. Two camps have emerged: the commit-often advocates and the rebase adherents.

Commit-often enthusiasts view fine-grained commit histories as a reflection of genuine development progress. They argue that squashing merges simplifies the history but sacrifices valuable context. For them, a neat history is crucial for understanding the intent behind changes. Steve Klabnik, a prominent GitHub user, sees stacked pull requests as one of the most significant updates to hit the platform in years, hoping it will introduce developers to novel workflows.

Conversely, rebase proponents scoff at the idea of frequent commits, considering them wasteful. They maintain that every commit should be preserved, even if it means a messier history. These developers dislike squash merges, which they see as destructive to their meticulously crafted commit histories. They prefer merge commits to ensure transparency and traceability.

The heated discussion highlights a fundamental difference in philosophy: one camp embraces frequent commits and squashing for simplicity, while the other prioritizes meticulous history preservation. Ultimately, the debate suggests that a clean history is more resilient in the long run, as it tends to deteriorate over time without strict enforcement. For most developers, making peace with a messy history may be the most pragmatic approach, especially when lacking control over a repository.