You really don't want customer specific branches/forks. Multiple main branches are a pain to maintain. In some cases they are really needed - for example, when you are trying to stabilize a release or support an old version - but in those cases there are usually few of them, and the problem of what-to-push-where is something you have to solve regardless. Here we are talking about branch-per-customer, which you'll have to maintain for as long as you keep the customer, and merge each new feature into each of these branches - possibly with different conflicts for the same commit...
First I'd suggest to rethink the problem - do you really need client-specific features? Sure, some clients are big and/or important enough to request features and have you invest time and money to develop them - but these clients do not own the copyright for these features, and you'll have to test, document and maintain them anyways - so why not just make these features part of product? Your other customers will benefit from having these features, and you will benefit from not having to maintain so many main branches.
If, for whatever reason, you really can't or don't want to ship these features to clients other than the ones who requested them - consider a plugin architecture. The common ways are to host a scripting language engine or to provide an API and run the plugins as external processes. The customer specific code will be a plugin, developed and owned by either you or the customer(pro - they'll bother you less about tweaking the plugin. con - they'll start bothering you for support regarding the plugin architecture). The plugin will have it's own codebase, separate from the main project, so as long as you pay attention to backward compatibility in your plugin mechanism the plugins should not be too hard to maintain.
Keep in mind that plugins are limited by the plugin architecture - but even if you can't put a feature in the main project, you can usually put the minimal plugin API changes required to implement it as a plugin.