At the very least you need to provide the developers the code they work on. This limits your ability to restrict their access. You can provide libraries for other sections of code, but this can create barriers to resolving bugs.
There have been cases where employees stole code and tried to create competing services. Those I know of have been successfully dealt with through legal means after the fact. Ownership of the code should be handled by contractual terms with those that use it. Copyright may also apply.
Other than frameworks and libraries, which are increasingly pulled from or available the open source community, their is little code I have worked on that would be of much use on future projects. Those in-house frameworks that I have used were not as robust as the competing open-source frameworks.
I have worked in restrictive code control environments, but they only had checkpoints and future code work was done on code version not extracted from teh code control environment. This lead to significant issues, where source code for released versions could not be retrieved as it wasn't tracked anywhere.
Having managers merge the code limits the access to the full copy. However, managers may be more likely to be able to successfully make use of that access. I would rather restrict the code access to the developers.
Most developers will only have the code they need to work with on their system. This can be a significant portion of the system, but likely not the full system. With good code reuse, they may have a significant portion of the system available as libraries. Larger sites generally have multiple repositories, and limit access to the teams requiring access. Code browsers can allow developers to browse the code from other projects they need to resolve related bugs.
Code locking systems tend to add friction to the development process. I have seen little if any value added by code locking. Good communication and revision tracking add significant value. Having a manager merge the code would appear to be a another approach to code locking.
There are advantages to using a review process to gateway changes into the released code. There are various approaches that can be used. They all require tracking changes, which increases change management overhead.