How to Use Git as a Sole Developer

First, if you really want to use git for this, then consider using its Submodule functionality:

Git's submodule support allows a repository to contain, as a subdirectory, a checkout of an external project. Submodules maintain their own identity; the submodule support just stores the submodule repository location and commit ID, so other developers who clone the containing project ("superproject") can easily clone all the submodules at the same revision. Partial checkouts of the superproject are possible: you can tell Git to clone none, some or all of the submodules.

The linked page contains a detailed discussion including examples of how to use it exactly.

That said, I would recommend not to use your version control system for dependency management and rather start using a build tool that can handle these things for you, such as Maven or Ant. There is even a PHP-specific build tool in development called Phing, but I haven't used it myself yet. It is mentioned in an article that discusses your question: Version Control != Dependency Management.

The reason build tools may be a better fit in the long run is because they often also support different repository types, external libraries (and different locations) and extensive checking. If you however just want to integrate these two libraries and don't want any additional hassle, the submodule approach is probably sufficient.

TL;DR: your git workflow isn't really the problem. The problem is that you need more, smaller iterations on the features you put in your topical branches. This will reduce the pain of keeping these topical branches up-to-date and integrating them into the upstream.

You definitely want to keep unmerged branches up-to-date with the changes in their upstream, and rebasing is generally the correct way to do this.

Your comment that "sometimes a feature is bigger than what a branch should be" leads me to believe that you have long-running topical branches that you find difficult to integrate with your integration branch. This, in my experience, is the actual root of your pain.

Imagine if your topical branches lasted a few hours and then were merged back in to the integration branch. These ephemeral branches are likely to be trivial to keep up-to-date and trivial to merge back into your integration branch. On the other hand, imagine a long-running topical branch that spans multiple releases of the software without integration. It would probably be quite difficult to integrate. This should lead you to conclude that short-running topical branches that are frequently rebased against master are easier to work with.

The question, then, becomes "why would features be bigger than what a branch should be?" This is probably because you're trying to do too much at once. The best way to keep topical branches short-lived and to make integration painless is to work in an iterative fashion where the minimum marketable feature is ruthlessly hewn down to its bare essentials and further work on that feature is added on in separate increments.