hariprasad Narnavara, I think multibranch pipelines are the best solution to the problem you're trying to solve.
Each developer wants to see the results of their changes as applied to the master branch. They don't want the disruption of seeing the untested work of others intermixed with their changes. A single job and a single branch means that the developers need to decide which of the builds within the job are theirs and they need to decide which of the commits are theirs within that build.
If instead each developer pushed their changes that needed to be evaluated to a separate branch for the change they were proposing, then the multibranch pipeline will automatically create a job dedicated to that branch. The developer will see only their changes on the new job for their new branch. They can add more commits, amend their commits, invite code review of their commits, and when those things are complete, they can merge that branch into the master branch. The multibranch pipeline insulates them from the unverified changes of others and allows them to do a better job of preparing their changes to be merged into the master branch.
The multibranch pipeline works well with plain git (using branches), with Bitbucket (using branches, pull requests, and optionally forked repositories), with Gitea (using branches, pull requests, and optionally forked repositories), and with GitHub (using branches, pull requests, and optionally forked repositories). Please reconsider the capability of multibranch pipeline as a better solution to the problem you're trying to solve. It is something you can implement immediately and integrates well with Blue Ocean and other components.
The free Jenkins Pipeline Fundamentals course introduces the multibranch pipeline concept very well.