Version Control with Git

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 to check out the ...