When working in teams, pull requests play an important role in knowledge transfer, building a team culture, and ensuring high-quality merges. For example, a developer A forks a Git project to work on a feature. Then, after several commits that implement that feature, developer A issues a pull request to his team (or certain developers depending on the project policy). Code reviewers start reviewing the code and inserting comments within the changed code regarding code style, enhanced code, potential bugs, improvement suggestions, etc. Developer A can reply to the comments and make the necessary changes and commit them. This process is iterative and can go on for while until the pull request is approved by the reviewers. Then developer A (or a certain developer) merges his fork with the main project.
So in theory, projects can be decomposed into merges instead of commits. A merge is a sequence of commits related to one task. Breaking the evolution of a project into snapshots after each merge can produce better results when analyzing software evolution.