Supporting a product that is customized for multiple customers is not a version control problem. It is a design and distribution problem.
Maintaining multiple code bases is a real pain. It's bad enough to need to duplicate the code base to support multiple platforms and languages, let alone multiple customers. Better instead to build a modular product. Sure, there will be elements that will require a larger degree of customization, and a small percentage of overlap where the code may need to be effectively duplicated, but it is better to create a very finely grained modular system design to cope, instead of attempting to branch where the risk is that the branches may become so divergent as to never be able to merge.
I myself work on an API that presently supports 3 hardware platforms, and greater than 3 customers. At the minimum, we would need to manage 9 separate code-bases if our code was not designed to be modular from the start. When I first arrived at the company nearly 10 years ago, the existing code base used conditional compiler directives to deal with 3 variants on a single platform, was about 50 times smaller than the present API incarnation, and took twice the effort to maintain. It took a lot of work, but we now have a product that never needs to be branched, and will be able to support literally any number of clients, platforms, and customizations.
So to specifically answer your question, It is better to maintain a single main branch provided you implement a design that will support a more modular development approach, and if your customization is required to be unavailable to more than a single customer, then you solve the problem in the way that your modules are accessed by your code, and in how they are deployed.
You can use tools to display all the hardcoded strings inside the application, and hopefully the filename will show up.
Check OllyDBG on Windows and strings on Linux (it's a cmd-line application).
A more complex solution: fire up your favorite asm debugger (OllyDBG, GDB) and get your hands dirty.
Best Answer
Use what you want. Use what makes sense for what you are doing now.
While I'm mostly a command line guy (I use the GUI only to get a graphical representation of revision graph), I've trouble to understand why you think using the command line gives you a better understanding of what happens behind the hood (well excepted for GIT :)), usually there is a clear mapping between the two even if CL may give you access to some little used features.
Now in my opinion, automating what can be automated in the process is part of the job and for that, CL is mandatory.