Am asking this question because, after raising PR and send it for review to multiple teammates, I see the necessity of creating new commits, before PR is closed with merge or no-merge.
Is PR request mainly indicating a feature branch to review?
Or
Is PR request mainly indicating a specific commit on a branch for review?
A PR refers to a branch you want merged into master (or any other branch it's raised against). Pushing additional commits to the branch you opened the PR on will add them to the PR.
Until you define "Pull Request"—I'm assuming this is what PR stands for—or pick a particular hosting provider such as GitHub or Bitbucket, the question can't quite be answered. The reason is that pull requests aren't a Git thing, they're a hosting-provider thing. It's up to the hosting-provider to implement them, and everyone who does, has some subtle difference in their implementation, vs the next guy's.
Once you do define PR precisely, it's also helpful to pick your definition of the word branch, because in Git, when people say branch, they may mean different things. (See What exactly do we mean by "branch"?)
That said, both GitHub and Bitbucket handle pull requests in very similar ways. If you're using some other provider, chances are good that they follow this trend. On both GitHub and Bitbucket, when you make a Pull Request, what you have done is to create something that is very much like a branch. (Whether it is a branch, or not, depends on your personal definition of branch.) You can keep adding more commits to this thing-that-is-like-a-branch and the pull request automatically updates, so that people who are on the web site, viewing the pull request, can see the new commits.
The method by which you add new commits to your pull request can also vary from one hosting provider to another. For GitHub, you simply git push to whichever branch you used, on whichever repository you used, to initiate the pull request. GitHub then update the pull request itself, automatically. I have much less experience with Bitbucket and am not sure if their PRs behave the same way, but that's what I would expect.
A PR is indicating a branch to review compared to another, for example, Master branch.
When you create a PR, the system will evaluate how many new commits have been made to the feature branch since the moment it has been branched off of the Master branch.
I want to add few sentences which mostly focus on explaining how you can interact with PR rather that giving strict definition of terms.
PR is branch created with intent to integrate changes into some project PLUS set of collaboration services for people who work together in the project. Basically these services is what makes PR different from just a branch with code.
Current de-facto standard set of features offered by PR in different source code hosting providers are:
discussions. They might be attached either to the PR as a whole to discuss high-level things or to individual pieces of code. (imo these "scopes" of conversations is one of the most important features of PR).
advanced cross-reference embedded into the conversations where you can easily relate/link your text to pieces of code, bugs, features, commits and any other entities. this works mostly automatically (autocomplete). It also powers "conversations" feature so that co-workers can easily relate every iteration of changes in open PR to question/proposals/requests appeared during the discussions of PR.
Other features exist which also help to manage code changes but not so specially attached to PRs.
