# 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.