Summary
The discussion on merge commits versus rebasing versus squashing is a common one in software development circles. The gist of the argument presented here is the belief that no single strategy is the right answer for all situations. Instead, each method has its place and should be used contextually. The author outlines personal preferences and experiences, favoring a mixed approach tailored to the specifics of each case.
Merge Commits
The author prefers using merge commits for the majority of pull requests (PRs), to preserve the true history of development. Merge commits show the flow of work and are easy to revert if needed. They also support the effectiveness of git bisect, a debugging tool, which works best with a history of smaller, buildable commits rather than large squashed commits. The ability to pinpoint a bug in a smaller change set is highly prized, and merge commits maintain this granularity. Having a policy of keeping each commit buildable is emphasized, although the author acknowledges human error and also recognizes the need to fix up commits for others in open-source projects.
Squashing
Squashing is used by the author when a PR consists of many Work-In-Progress (WIP) commits that only contribute to a single, focused goal with a relatively small overall diff. In these cases, squashing is beneficial to avoid cluttering the history with redundant "WIP" entries. However, the author notes the importance of rewriting the commit message to ensure it is descriptive and not just a concatenation of the squashed commit messages, which is the default behavior of Git.
Rebasing
Interactive rebasing is the method of choice for the author when dealing with PRs that contain both a large diff and many "WIP" commits. Rebasing allows for selective squashing and reordering of commits, which can clean up the project history. This process is believed to be part of good commit hygiene, a practice that developers should be familiar with. In situations with large PRs, the author prefers using a Git GUI client, which provides a more user-friendly interface for handling many changes—this is the sole situation where a GUI is preferred over the command line interface (CLI).
Concluding Remarks
Ultimately, the decision between merging, squashing, and rebasing should depend on the context of the changes being integrated into a codebase. The author's preferences illustrate a pragmatic approach that values preserving history, maintaining buildable commits, and ensuring clarity in the commit log. Good commit hygiene is underscored as an essential skill for developers, whether in open-source or professional environments.
Tags
- #VersionControl
- #GitWorkflow
- #MergeCommits
- #Squashing
- #Rebasing
https://gist.github.com/mitchellh/319019b1b8aac9110fcfb1862e0c97fb