How to Organize a Framework-Based Project in Git

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.

I feel your pain as I deal with this sort of thing every day. My situation is having to maintain multiple customer versions of an open source project, each with a different selection of plugins, core hacks, etc. It's not fun when you have 50 of them.

I've not yet found an ideal (perfectly clean) solution, but my modifications to GitFlow are:

• Make a separate branch (other than master) for each customer's production code. Use master for the definitive all-features version, and only merge what the customer wants into their own ones.
• Keep developments (or added plugins etc) on tightly defined hotfix and feature branches, and leave them in place, even once merged, so you can merge into other customer branches if you need to. This also makes it easy to keep track of who has what features by crunching through the logs.
• When developing new features, branch from the latest common ancestor of all customers if possible. This means that you will be able to merge into develop and then master, but also merge into the customer production branches without (in theory) causing conflicts.
• Have one main repo just for development work, which looks like GitFlow. Have another that has your dev repo as a remote, which is used to store customer branches so that your dev repo has a clean(er) history.
• If you really can't resolve a conflict easily and need to cherry-pick a whole branch at once, use rebase --onto like this. Just make sure it's clear in the commit messages where the feature cam from and why it's not been merged normally.

Using git has had an added side benefit in that we can now run a cron job across all the production servers which checks for unstaged files in the git repos. We now know if the support staff have been dicking about with the production code on the servers without telling anyone, which has prevented a lot of headaches :)

Hope that helps.