3 Answers
3

Depends--are you okay with potentially untested code going to production? For example--Dev A pushes changes intended for production, tests them out and they look fine. Meanwhile, Dev B tests in some code--but oops, he made a typo and now the application immediately fails on requests. Dev A, meanwhile, pushes to production, bringing in Dev B's broken changes.

You need a deployment strategy--that is, you need to always be sure that what you're pushing to production is (a) tested and (b) reliable. I'm of the opinion that production should NEVER be running "straight from git," if only because that makes it very easy for bad things to happen--i.e., if someone gains access to your frontend, they can now do whatever they want to your code base. At best, they can steal the code and your history. At worst, they can make changes to your code base--likely without you realizing it.

You could, for example, have a separate repository specifically for production--that you can fork from and then merge changes as you need--or deploy the code as a separate archive. This would give you a lot more control--and insight--into what is going to prod.