How to manage two identical projects, the name of the opportunity to refine them together and separately?

Question

css

Hello!
There is a situation: there is a current project in git. It works and everything is great. There is only one branch in the git repository - it is also a release branch, without dev branches.
Now there is a need to create a copy of this project for another company. The project will be slightly modified for this company, but in general, the code base will remain 99% original. But in the future, it is planned to improve both the original project and the copy, as well as general improvements together.

How can you conveniently work on two projects in parallel, while being able to conveniently refine both projects and each of them separately?

My options:
1) Use two independent repositories. But here the question is that it will be inconvenient to make changes to both projects.
2) Use different branches within the same repository or submodules.
3) Refine the current project so that there is 1 common core, which will be finalized separately, and for each company create its own repositories where "plugins" for this core will be stored. But in this case, you will have to significantly rewrite the current code.
The third option sounds best, but it will take a lot of time to implement it in order to clearly define the "border" between the plugin and the core. Well, it will also take a lot of rewriting.

Answer 1

In order for it to work inside use, you need to remove all styling inside the symbol

Answer 2

svg sprite needs to be embedded in html, it will not work as a file, and just change the parameter through css. For example:

#menu path{
  stroke: #000;
}

Answer 3

Two repositories. In both, add one more origin - to another project.
If you need to make changes to both projects, then first do it in one, then in another project, merge the changes from another origin.
You need to write code as independent as possible. Use modularity, for modules to external API and event/listeners to communicate externally. In places where the logic differs - to the maximum polymorphism, i.e. avoid merges at all costs.
The second option is shit. The third option is too complicated.