Both have plenty of experts with opinions. According to GitHub's official documentation,
If you plan to continue work on the head branch of a pull request after the pull request is merged, we recommend you don't squash and merge the pull request.
For what it's worth, GitClear's repos follow this convention as well -- we rebase commits as we develop a branch, so as to retain the commit messages that described the incremental work that was being authored. Read more about the benefits of rebase over squash in our Minimalistic Committing recommendations documentation.
Still, some GitClear customers have reasons that compel them to squash commits when merging a pull request. For example, teams that want to swap patches in-and-out of branches might prefer that a squashed merge makes it easier to remove a group of commits.
This page will describe how GitClear handles the Diff Delta for pull requests that are squash merged or conventionally merged.
If a commit has children in the main branch, that is considered the "gold standard" that the commit deserves Diff Delta.
When a pull request is conventionally merged, the commits (potentially rebased) that were authored in the course of developing the pull request are connected through to the main branch, so all of those in-progress commits retain their original Diff Delta.
The merge commit receives no Diff Delta, unless the merge makes changes that weren't in the default or feature branch. Usually teams try to avoid changing code in a merge commit, since it falls outside the standard PR review process, and is avoidable by rebasing prior to merging.
When a pull request is merged with the "Squash" strategy, git discards all of the commit history that occurred in the course of developing the pull request. To the extent that the discarded commits may have held incrementally useful explanation about why certain lines changed, that information is lost in a squash merge and replaced with the single git commit message made when the squash was triggered.
Since the commits in a squashed pull request do not meet the "gold standard" of having children in the main branch, they are generally considered "obsolete" to git and to GitClear. The individual squash merge commit is what remains from the pull request in the git commit lineage, so the squash commit is what GitClear has traditionally evaluated to determine the Diff Delta for a pull request.
When a pull request does not contain multiple authors (as described in following section), the squash commit is used as the final "source of truth" for how much change occurred within the PR. When processing the resulting squash commit, GitClear loosens the usual restrictions on the maximum volume of "changed lines" and "Diff Delta" that are allowed to exist within a single commit. This means that squash commits can receive thousands of points of Diff Delta. For a non-squashed commit, explicit confirmation is usually required prior to awarding such a high amount of Diff Delta.
A challenging case to reconcile Diff Delta is when multiple committers will work on a pull request that is subsequently merged via squash.
In this case, if GitClear uses the squash commit that is left in the main branch, there can be only a single author who will receive the Diff Delta for the entirety of the pull request changeset. GitClear customers, understandably, felt that this situation was not fair to the committers whose work had been wiped from the git history.
To accommodate these customers, GitClear implemented upgrades in 2025. Now, obsolete commits from a squashed pull request can still count toward the team/repo/committer Diff Delta. We do not default to this processing mode, because some git providers stop returning details about obsolete commits as time passes. But we can and do invoke this special processing mode as follows:
If a pull request is squash merged, and there is more than one committer that authored work within the pull request, then GitClear will invoke the special processing mode where commits not connected to the main branch still receive the original Diff Delta they were assigned when they were initially processed. When this processing mode is used, the squash commit itself receives no Diff Delta, because all of its work is credited via the incremental commits that went into the pull request. In this regard, it is similar to a conventionally merged pull request, which also has no Diff Delta assigned to the merge commit.
Normally, Diff Delta is on the lookout for identical file changes that occur across branches or repos, ensuring that we only give credit to each change on the first occasion it was authored.
Squashed pull requests present a challenge on this front, in that it's common that the same change will be observed in an incremental file that occurs in the PR, and that same change (or a superset of it) will occur in the squash merge commit that brings the work back to the main branch.
GitClear handles this by bifurcating each pull request delta attribution, according to the rules explained in the "Squashed pull requests with multiple committers" section. For the cases when the obsolete work-in-progress commits will have their Delta chosen over to the squash merge commit, GitClear revises the commits such that the "squash merge commit" has its changes classified as "duplicates" of the work from the pull request that is to be retained. Otherwise, if the squash merge commit is used as the source of truth for Diff Delta, then any copies of the changes in its files are considered "duplicate" of the canonical version of the change, which resides in the Diff Delta-carrying squash merge commit.