Hello, We tried exactly the same thing (same modules for different clients) but things got so complicated to manage that we stopped to build websites this way. Why it became so complicated :
- Same code base for different clients doesn't allow you to customize them so when a client has a specific use case/need, you can't do it (and don't tell me that you will create a new module for this client which will override the first one for the parts you need to customize because you will have 2 modules doing the same thing and when you will have to do some changes, you will not remember in which one to look). - You MUST have one repository per module, it's easier to manage and see what your developers are doing. If you need to update only one module (i.e patch), you can then update your project easily with only the change you need (so you don't pull changes made on another module which can introduce bugs for a specific client or some merging headache). At this time, we have one repository per module. Each module for each client is forked from our "module" core codebase so when a change is made for a client and can be used by another (generic change), you update your client module, then make a pull request to the "module" core codebase which is then approved and incorporated. Then, when you need to work on another client which use the same module, you update your client's one by pulling the "module" core codebase, merge the changes with the customized one, test and voila. Regards, CAGGIARI Vincent.
