Pipelines for multiple release branchs

You configure what builds will be triggered by a commit by setting up a VCS Trigger for each build configuration that you want to get triggered by a VCS event. This VCS Trigger can be then configured, for each build configuration, whether it should be triggered by any given set of changes, taking into account branch, and even path to the files.

Are you suggesting to have different build configuration per branch(which will get trigger only for a branch) in master ??  

If you want to follow different steps for each branch, then yes, you should create a build configuration (or set of build configurations) for each pipeline (not branch). Let me reword my previous answer in a q-a format to see if I can make it a bit clearer:

What is the expected behavior in case branches have different pipeline configurations ? e.g. master has 2 build configurations and branch B has 3 build configurations, vcs root default branch is set to master.
As said, the builds configuration or VCS Root configuration is irrelevant for which builds will be triggered. Only the VCS Trigger of each build configuration is used to determine which builds get triggered upon a VCS check in. You can have any number of builds configured to be triggered with the same branch on the same root and all of them will be triggered at the same time.

If checking is made against branch B how many build configurations teamcity would run? Will it load configuration dynamically from the branch?

As many builds as you have configured a VCS Trigger for will get run. If the VCS Root is configured to only track a given branch, then you can use a simple VCS Trigger. If you share the same VCS Root for all configurations and only want some build configurations to be triggered, simply add them to the branch filter on the VCS Trigger.

If this is not possible, what are the best practices to handle this scenario ? Should we create different projects per branch? 

Projects are mainly thought to give organization and scope for features like permissions, parameters or shared configuration, so this would be irrelevant for the triggers. The best practice is to create a build configuration (or chain of them if you have shared/parallel steps) for each pipeline, then attach a VCS Trigger to the configuration (or last build of the dependency chain, it will trigger automatically its dependencies) and configure the trigger to be activated on the branch you are interested in.