I feel like you may be misunderstanding how Git works. A commit hash, or SHA, refers to a commit in the repository. A commit in the repository contains the state of the entire repository at that point in time, it does not reference a difference between two states. Older source control systems, such as SVN and CVS worked on a diff-based system like you describe. You can still get the difference between two commits out of Git, but that is not what is stored in Git or what is represented by a commit.
So check suites and check runs are created for specific commits, not the difference between two commits, as stated in the documentation.
To answer your questions:
How are check suites and check runs associated to a pull request?
By strict definition, they’re not. They’re associated to single commits. Some commits are associated with pull requests and there are visualizations on the PR timeline view for those check suites.
What event and data to use to analyze a pull request?
The way that GitHub is designed is that the result state of the list of check suites executed against the last commit of the pull request is the state of the pull request itself. This is because when the pull request is merged, the repository will either equal the last commit of the pull request, or very closely resemble it (in the case that there have been changes on the default branch since the pull request branch was created). So the state of the check suites executed against the last commit is the most valid predictor of the success or failure of the pull request after merging. The state of the check suites executed against any previous commit are no longer valid predictors because any problems in those previous commits could have been fixed in the latest commit. This is why the state of the check suites of the last commit are surfaced in the GitHub Pull Request UI:
Pull Request from the above screenshot
In the example above, when
eff2f76 was the last commit (March 20), the state of the pull request was that it was not ready to be merged because one or more check suites that were associated with
eff2f76 failed. Then, on May 31, rafeca added some more commits to the pull request that resulted in
df3352c. All of the check suites associated with
df3352c passed, so the pull request at
df3352c is ready to be merged. Or I could go in and add some more commits that include a problem and it would go back to being not ready to merge. And so on.
So, to summarize:
A check run is associated with a single commit and returns a status when complete
A check suite is a collection of check runs associated with a single GitHub App and a single commit that summarizes the status of the individual check runs
Multiple check suites can be executed against an individual commit
The results of the check suites on any commit can be used to determine what problems might exist on that commit
For example, perhaps you’re building a cross-platform application. One of the check suites might indicate a problem with the Windows build, whereas the macOS and Linux build check suites both pass.
The mergeability of a pull request can be determined based on the states of the check suites of the last commit on the pull request
GitHub has ways that you can indicate that certain check suites are required while others are not. For example, perhaps the build verification test check suite is required to pass whereas the check suite that calculates code coverage is not required to pass
I hope that helps and let me know if you have any more questions.