The Squash Merge Dilemma: Balancing Simplicity and Attribution

When it comes to merging code changes into a main branch, squash merging has been a popular choice for many developers working on commercial software. The primary reason for this preference is simplicity. By squashing commits, the commit history on the main branch becomes streamlined and easier to understand at a glance. This clarity is particularly valuable when deploying code to production using a trunk-based deployment methodology.

Squash merging allows developers to focus on the overall evolution of the codebase without being bogged down by the numerous intermediate commits that may have been made during the development process. These intermediate commits often include messages like "fixed," "remove .txt file," or "updated test," which can clutter the commit history and make it harder to identify the key changes that led to a functioning version of a feature.

Moreover, squash merging simplifies the process of reverting changes if a bug is introduced. With a clean and concise commit history, it becomes easier to identify the specific commit that introduced the issue and revert it without affecting other changes.

However, when it comes to open source projects, the considerations for squash merging are different. In the open source world, contributors often volunteer their time and effort to improve a project without monetary compensation. As a result, it is essential to ensure that their contributions are properly attributed and recognized.

Historically, GitHub's handling of squash merged pull requests has been suboptimal in terms of attribution. The account that merged the squash pull request would take all the credit, overshadowing the individual contributors' efforts. While GitHub has made improvements in recent years by attributing the commit author and merge author, there are still limitations when it comes to pull requests with multiple committers. In such cases, the attribution is given to the last commit author when the pull request is squashed.

To address this issue, it is crucial for maintainers and reviewers of open source projects to be considerate when merging pull requests. Take the time to understand how commits with multiple authors work and explore alternative merging strategies that preserve individual contributions.

One approach is to use a merge commit instead of squashing. This allows each contributor's commits to remain distinct in the history, ensuring proper attribution. Another option is to use a tool like Co-Authors Plus that allows for multiple authors to be credited on a single commit.

It is also worth reconsidering the practice of enforcing squash merging as the only option in open source projects. While it may provide simplicity for the maintainers, it can discourage contributors who value having their individual commits recognized. Instead, consider offering flexibility in merging strategies and allow contributors to choose whether to squash their commits or maintain a more detailed history.

Ultimately, the decision to squash merge or not should be based on the specific needs and goals of the project. In commercial software development, where simplicity and clarity are paramount, squash merging can be a valuable tool. However, in open source projects, where attribution and recognition of individual contributions are essential, alternative merging strategies should be explored to ensure that every contributor receives the credit they deserve.

By being mindful of the impact of squash merging on attribution and considering the unique dynamics of open source projects, we can foster a more inclusive and appreciative community that values and recognizes the efforts of all contributors.