We would like to enforce a policy in our git repositories so that master must be merged/rebased (let's ignore merge vs rebase for now) to feature branches before creating pull requests.
The reason we'd like to have this policy is to force developers to consider functionality added in other feature branches and to reduce merge conflicts later.
Is this something typically done in a development team and what tools (git-hook?, functionality in a specific CI tool?) do you use for that purpose?
First, you don't merge/rebase master.
You merge/rebase the local development/feature branch on top of master, in order to replay local commits on top of an updated (git fetch) origin/master, to make sure the pushed feature introduces only new commits on top of the most recent state of master.
You can facilitate that locally with the config pull.rebase and rebase.autostash (see "Can “git pull” automatically stash and pop pending changes?")
That is best done when only one developer is working on a given feature (because it can involve a push --force of that rebased branch if pushed often)
On the server side, hooks (like this one) are only possible if you have control of said server (not the case for instance for online servers like github.com)
