I've taken a service to support e-commerce on the PrestaShop platform.
I found the environment configured this way:
The main application files are on bitbucket. To do maintenance, I change the files via git and do the deploy of the
BitBucket for the server where the application is.
git does not manage the database.
I wonder if there is an environment model or some workaround for this problem.
This is an old question that even the official PrestaShop forum does not answer.
To implement the commits in the modules you will have to create administrative policies where several useful functions would be blocked, among them, modifications in the themes, modules, overrides and others.
Whenever you need to add some module, theme or other function within the situation you described in the question, you will have to do it first in the production environment. That is, it would no longer be possible to control this through the BackOffice of PrestaShop, if you want all the control by the GIT.
This topic holds true for other modular platforms as well.
You will have the advantage of being able to control by git, but the platform loses a significant part of the resources. Because the attraction of this type of platform is so that lay in programming can install resources without needing to know anything about programming.
But the reality is that a module does not always work well when updated. Sometimes they cause flaws where you need a professional and experienced programmer to solve. In the end, the feature that allows a layman to install things without knowing what he is doing, becomes a two-way knife.
About the database , how to control structure versioning (schemas) is a matter of opinion, but a schema dump is usually done and saved in a common text file. So you can add the structure to the git control. Some people also prefer to add the data (together or separately from the schema). It depends a lot on the situation. Particularly save essential parts of settings. The data itself, the ones that consume more space like order tables, clients, logs, products, etc, I'd rather not stick together even in git. Saved separately. This is because if you always save all the data with each commit, in a short time the space in the storage media reaches the limit quota and it is very easy of that because a simple small store usually has little more than 1GB of data. If you do 5 commits in a day, it means + 5GB of bank data only, and most of the time you do not even need to have all this information "duplicated."
Hint, As you have already got the project with this structure and by asking this type of question, I assume that the previous person did not give you instructions. Based on this, I advise you to make a thorough checkup between the versioning and the data that is in production. Most likely you should have changes in the production environment incompatible with what is in git.
So just be careful about it. I suggest pulling everything out of production via FTP, or any other viable medium, and re-commit everything with your new management and administrative policy if you want to continue controlling for git. Document this well and provide the documentation to the store owner so that the day you stop providing support, the next programmer can know how to continue.Of course, first of all, have a meeting with the owner to explain the situation. From there, formalize in contracts and proceed with the service as agreed because all this is service, it is much more laborious and must be encumbered. If your support agreement does not include this painstaking level of work, you can go out of business by working far beyond your budget. Over time this will build up and weigh to your side.