When a pull request is merged to master, the application gets deployed to production.
This motivates us to write good tests that we can trust. But, it also means that we must be judicious when we do the merge. How this happens depends on the team and the change.
For example, bugfixes are likely to go up immediately. New features can go up hidden under a feature flag, or they might need to wait for staff training or a sync with marketing.
The creator of the pull request is responsible for keeping their PR up to date with master, if the code is ready well in advance of other factors. Most teams acknowledge this with "Ready to Ship" being distinct from "Shipped".
When a change is shipped, both the author of the change and the developer on support that day/week maintain extra vigilance around the application and its user community to ensure nothing has gone wrong.