Analysis and Solutions for GitHub Pull Request Displaying Already Merged Commits

Problem Phenomenon and Background

During GitHub Pull Request reviews, developers frequently encounter a perplexing phenomenon: even after the target branch has incorporated commits from the main branch through merging operations, these commits continue to appear in the Pull Request's change list. This situation typically occurs when the target branch lags behind the main branch. After merging the main branch into the target branch, developers expect the Pull Request to display only unmerged changes, but already merged commits remain visible.

Root Cause Analysis

According to GitHub's official design principles, the Pull Request system does not automatically track changes to the target branch. This means that when the target branch updates through merging operations, the Pull Request's comparison baseline does not automatically recalculate. While this design choice may cause some inconvenience, it ensures stability and predictability in the PR review process.

From a technical perspective, GitHub records the commit state at the time of Pull Request creation as the comparison baseline. Even if the target branch changes subsequently, this baseline point does not update automatically. This explains why local git diff commands show correct differences while the GitHub interface displays different results.

Primary Solution: Temporary Base Branch Switching

The most effective solution involves forcing an update of the Pull Request's comparison baseline through GitHub interface operations. The specific steps are as follows:

1. Click the <kbd>Edit</kbd> button on the Pull Request page
2. Temporarily change the base branch to a different branch (such as a development branch or temporary branch)
3. Confirm the change, at which point the system displays a warning message: <strong>Are you sure you want to change the base?</strong>
4. Immediately change the base branch back to the original target branch
5. After refreshing the page, the Pull Request will display only truly unmerged changes

This operation leaves two log entries in the Pull Request's timeline, indicating that the base branch has changed. From a technical implementation perspective, this operation triggers GitHub to recalculate branch differences, thereby obtaining correct comparison results.

Alternative Approach: URL Comparison Method

For scenarios requiring quick viewing of accurate differences, GitHub's URL comparison functionality can be used:

http://githuburl/org/repo/compare/targetbranch...currentbranch

Where the following parameters need replacement:

• githuburl: GitHub instance address
• org: Organization or user name
• repo: Repository name
• targetbranch: Target branch name
• currentbranch: Current feature branch name

This method provides real-time branch comparison, unaffected by Pull Request caching mechanisms.

Community Discussions and Supplementary Insights

According to extensive GitHub community discussions, this issue appears in multiple scenarios, particularly more evident when using squash merges or rebase merges. When using these merge methods, GitHub creates new commit hashes, and even with identical content, GitHub does not recognize them as the same commits.

Workaround solutions suggested by many developers include:

• Performing rebase operations locally: git rebase origin/master
• Using git push --force-with-lease to safely push changes
• Creating new feature branches and initiating new Pull Requests

It's noteworthy that GitHub currently does not offer a true fast-forward merge option, which is also a factor contributing to this issue. Official recommendations suggest using merge commits rather than squash or rebase merges for long-term maintenance branches, as this better maintains branch synchronization.

Best Practice Recommendations

Based on problem analysis and solutions, the following workflow is recommended:

1. Before creating a Pull Request, ensure the feature branch is based on the latest target branch
2. Regularly synchronize target branch changes to the feature branch
3. Use the temporary base branch switching method to clean up displayed merged commits
4. For critical merges, consider performing fast-forward merges locally and pushing to remote
5. Establish team standards to unify merge strategies and reduce occurrence of such issues

By understanding GitHub Pull Request working principles and adopting appropriate workflows, developers can conduct code reviews and merge operations more efficiently, avoiding unnecessary interference and confusion.