GitHub's Local Merge Policy Shift: Implications for Software Development Quality

The Shifting Sands of GitHub Branch Protection

A recent change in GitHub's behavior is causing ripples among developers who rely on specific workflows for merging pull requests, particularly those who prioritize GPG signing their merge commits. This update, affecting repositories with branch protection rules, has effectively halted a previously accepted method for integrating approved feature branches into the main branch, raising questions about developer autonomy and software development quality.

The Workflow That Was: Local Merges with GPG Signatures

Prior to at least February 26, 2026, developers could follow a specific sequence to merge approved pull requests while ensuring their GPG signature was attached to the resulting merge commit. This workflow was essential for teams focused on robust commit history and verifiable authorship, contributing significantly to software development quality and auditability. The steps were:

• Create a feature branch within the repository and push it.
• Submit a pull request (PR) on GitHub.com and get it approved.
• Locally, check out the tip of the main branch.
• Perform a git merge of the approved feature branch, creating a 2-parent merge commit signed with the developer's GPG identity.
• Push this GPG-signed merge commit to refs/heads/main on GitHub.

Despite branch protection policies that typically mandate changes via PR, this specific workflow was historically permitted, allowing developers fine-grained control over their merge history.

The Change: Pushes Rejected

As of at least February 26, 2026, this workflow is now being rejected by GitHub, with pushes failing and returning the following error:

GH013: Changes must be made through a pull request error

This rejection occurs even when an approved pull request already exists for the feature branch in question. The inability to push a locally-signed merge commit directly to a protected branch, even after PR approval, disrupts established developer workflows and impacts how teams manage their commit integrity.

Why This Matters for Software Development Quality

The core issue for many developers is the loss of the ability to GPG-sign their merge commits. GPG signatures provide cryptographic assurance of a commit's author and integrity, making them a critical component for maintaining high software development quality, security, and compliance in many organizations. Without this capability, the audit trail for merges becomes less robust, potentially complicating forensic analysis or accountability tracking. While GitHub offers its own merge strategies (squash, rebase, or merge via UI), these do not typically allow for a developer's personal GPG signature on the resulting merge commit, nor do they create a traditional 2-parent merge commit in the same way a local git merge does.

This change also impacts how teams might use git analysis tools to review commit history, as the nature of merge commits and their associated metadata could differ. Developers lose a degree of control over their repository's history, which can be a point of contention for those who value precise, verifiable commit graphs.

Community Reaction and Next Steps

The initial response to this discussion on GitHub Community has been an automated acknowledgment of product feedback submission. This indicates that while the feedback has been received, there is no immediate solution, workaround, or official statement regarding the change or its intent. The community is left to grapple with the implications and seek alternative strategies or await further clarification from GitHub.

For teams that rely heavily on GPG-signed merge commits for their software development quality standards, this development necessitates a re-evaluation of their Git workflows and potentially a shift in their approach to branch protection and code integration. We encourage developers encountering this issue to share their experiences and any potential workarounds to foster a collaborative solution within the devactivity.com community.