Reputation: 804
How can I manage my application versions with git when I have more than one client that has diferent modules, reports and etc? Should I create one repo for each client? Creating branchs for each client is wrong cause branches are supposed to be merged back to master, right?
Conclusions:
-> Is wrong to use branchs to manage different versions of your system.
Upvotes: 2
Views: 635
Reputation: 2017
I'm going to propose what I think are two possible answers, neither of which really answer the exact question that you're asking; but I think that the way that you've asked the question could lead potential answers down a particular path. It's not a problem with the way the question is asked, more the things that we're (at least I am) drawn to when reading it.
Proposal 1
Have distinct repositories per module of your application. As you have hinted in the comments to the question, the "core" receives a lot of commits each week. Maybe that could be one repo (or several, nobody can really say without looking at your code for a while). Each optional module could also have its own repo. Then you could have an additional repo for code that supports "release engineering" related activities, like packaging the application in different ways for different clients: different modules/configurations for different clients.
Proposal 2
If the idea of splitting modules up like in proposal 1 sounds impossible (coupling too tightly or otherwise), then I would still try to pull out configurations as data that gets fed to whatever your build system is. Ideally you probably don't want to maintain a different version of your code for each client, that sounds like a maintenance nightmare. This way you have your canonical version of your code, and you just build it differently for each client. You shouldn't have to update in several different branches when you find a bug in something on one version.
There are likely many other ways to approach this, better or worse. A combination of the two could also work well I think.
Upvotes: 1