Skip to main content

Command Palette

Search for a command to run...

Commit SHA not What you expected?

Published
2 min readView as Markdown
Commit SHA not What you expected?

Introduction

When a Merge Request (MR) or Pull Request (PR) is raised against a feature branch, and the latest commit SHA presented in the MR/PR interface differs from the "head commit" of the local feature branch.

Possible reasons

  • Local Changes Not Pushed:

    The most common reason is that there are new commits on the local feature branch that have not yet been pushed to the remote repository. The MR/PR interface reflects the state of the remote branch, so if local changes are not pushed, the head commit on the remote will be older, resulting in a different SHA.

  • Rebasing or Amending History:

    If the feature branch's history has been rewritten locally using git rebase or git commit --amend, the SHAs of the rewritten commits will be different from the original commits that were previously pushed. When the MR/PR is based on the older, un-rebased history, and the local branch now has the rebased history, the head commit SHAs will naturally diverge.

  • Squashing Commits during Merge:

    Some platforms or workflows automatically squash commits when merging a feature branch into a target branch (e.g., main or develop). When this happens, a new, single commit is created representing all the changes from the feature branch. This new squashed commit will have a different SHA than the individual commits that were on the feature branch, leading to a discrepancy if the MR/PR is showing the squashed commit.

  • Force Push After History Rewrite:

    If a force push (git push --force or git push --force-with-lease) was used to update the remote feature branch after a history rewrite (like rebasing), the remote branch's history will be replaced with the new history. If the MR/PR was opened before this force push, it might still reference the older, now non-existent, commits.

  • Merge Commits on the Feature Branch:

    If the feature branch has been updated by merging in changes from another branch (e.g., main), a merge commit is created. This merge commit will be the new head of the feature branch, and its SHA will differ from the previous head commit. If the MR/PR was initiated before this merge, it might not reflect the latest merge commit.

Conclusion

To ensure consistency, it is crucial to push all local changes to the remote branch before opening or updating an MR/PR, and to be aware of how history-rewriting operations or merge strategies might affect commit SHAs.