There are a number of different workflows that might work here. Something that influences the choice of workflow is "how often do the libraries in CommonLib get updated?"
If the answer is that CommonLib is updated infrequently, then it might be possible to treat CommonLib like a toolbox or blockset. You can use a project start up shortcut to add the network location of CommonLib to the MATLAB path (and have a shutdown shortcut to remove it). When it is discovered as a dependent file or files of the project then it can be marked as an "external dependency" to show that it is expected for it not to be part of the current project.
CommonLib itself might well be in its own Simulink Project that is opened when development work is needed on CommonLib. If a user of Project1 has made changes to CommonLib then they can open the CommonLib Simulink Project, check for modified files, run the tests and validation procedures that are specific to the CommonLib Simulink Project and, once all changes are tested & reviewed, submit. Other users of CommonLib will get these changes the next time they update their CommonLib project.
There are a lot of variants on these workflows, such as SVN externals as described by Chris.