Firstly, you need to weigh up the cost/benefit of what you're trying to achieve.
Generally preventing code theft by developers is a very steep uphill battle, but fortunately I don't think it's a very common problem. I can't think of many prominent examples of code theft except in some cases where very specific proprietary algorithms are involved, or perhaps an employee jumping ship to a client and taking their code with them.
In terms of physically restricting access to code, really the only viable way is to restrict access to repositories. Even then, that will only be significantly effective if your application architecture in such that entire components can be operated as separate services and high risk employees can work on low risk components which might interact with the high risk components as a "black box" without having to give them access to the code.
It sounds like a high risk employee jumping ship with the project they're working on is your biggest threat and fundamentally they need access to that code to do their job so there's not much you can do about that.
The threat of legal action or damage to their professional reputation usually provides enough incentive for developers to do the right thing. Perusing these controls is probably a more practical approach. Endeavouring to hire trustworthy employees should also be obvious.
With regard to your deployment process specifically, it's pretty bad from both a security and operational standpoint. It seems you're without any form of version control, and I'd be shocked if you weren't frequently overwriting each others changes accidentally and trying to figure out who changed what without any way to know for sure.
It's typically considered good practice for:
- Your developers not to have direct access to your production servers except via an automated deployment process that takes code from version control where changes will be attributed to a specific developer
- To have a discrete deployment (as oppose to incrementally changing files) sourced from an explicit version control version
- For developers to have unique accounts, and typically their version control access dictates access to the production servers via their ability to commit code which will then be deployed automatically
There's plenty of resources on implementing version control and deployment management so I won't go into it too much further.