The Obvious Solution: Import the Code into Your Project
Letâs revisit one of the options glossed over earlier: why not just import the library into your own project in a subdirectory? Then you can copy in a new set of files if you ever want to update the library.
Depending on your needs, this method can actually work just fine. It has these advantages:
You never end up with the wrong library version by accident.
Itâs extremely simple to explain and understand, and it relies only on everyday Git features.
It works exactly the same way whether the external library is maintained in Git, some other version control system, or no version control system at all.
Your application repository is always self-contained, so a git clone of your application always includes everything your application needs.
Itâs easy to apply application-specific patches to the library in your own repository, even if you donât have commit access to the libraryâs repository.
Branching your application also makes a branch of the library, exactly as youâd expect.
If you use the
subtree
merge strategy, as described in Specialty Merges, your git pull -s subtree command, updating to newer versions of the library is just as easy as updating any other part of your project.
Unfortunately, there are also some disadvantages:
Each application that imports the same library duplicates that libraryâs files. Thereâs no easy way to share those Git objects between repositories. If KDE did this, for example, and you did want ...
Get Version Control with Git now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.