How to manage customized source code for each customer

I once made branches for each customer with git, but gave up when I was 10 customers.

In conclusion, customer-specific management is not actually management, but rather procrastination of problems, only accumulation of technical debt, so we don't do it.There is only one source, and customer-specific features can now be implemented via plug-ins.

It is theoretically manageable as long as it is a core branch, a custom function branch, and a customer-specific branch.

However, in the meantime, the commitment of "quick" will be made to the customer branch, and if a bug is found, the development branch of all the code that other customers are running will be tested and merged, and in the meantime, the previous commit will cause conflicts.Merge must also verify hundreds of commits each time.

Even if you manage it well, it's hard to manipulate the source of v1.0 that was up and running a year later.Even if you can manage bugs on documents, you can't merge with confidence.Besides the source, there is also data migration.

Some people may say, "It's easy to manage," "Give up is not good for hundreds of commits," or "If you write the unit test properly," but personally, I don't think it's productive to do this kind of work and take a lot of time to manage.I think it's going against the age of web services.So we came to the first conclusion.

Plug-in means designing an internal API, ensuring backward compatibility when API versions have the same major number (v1.x) and giving a version when backward compatibility is not guaranteed. v1.x->v2.x.In this way, you can manage your customers only with major numbers such as v1 and v2 series.The v1 family is easy to patch, but v1->v2 requires migration.

Note: Semantic Versioning