Appropriate use of git subtree/submodule/subproject/slave

Question

I am developing a website in Drupal, and my development directory tree is as follows:

modules
    -->moduleA
        -->moduleA.inc
        -->moduleA.info
        -->moduleA.php
    -->moduleB
        -->moduleB.inc
        -->moduleB.info
        -->moduleB.php
themes
    -->themeA
        -->themeA.info
        -->page.tpl.php
    -->themeB
        -->themeB.info
        -->page.tpl.php
ShellScripts
    -->scriptA.sh
    -->scriptB.sh
legacyPerlScripts
    -->script1.pl
    -->script2.pl

There is no large development team; I am developing all the modules and themes myself. The modules and themes are somewhat independent, and each has its own version number. However, some large tasks may require an upgrade to several modules. Furthermore, the modules, themes, and scripts should be deployed together, e.g. it would not be a good idea to use the current version of module A with an older version of module B, since module B may depend on a new feature in module A.

What is the best practice for using git for revision control? The options as I see them are:

1. Put everything in one large, monolithic repository.
2. Create a separate repository for each module, theme and script directory.
3. Use git-slave (gits) to create subprojects for each module, theme, and script directory.
4. Use git submodules
5. Use git subtrees

Which of these 5 options is the most common for a web development project such as this?

Answer 1

Keep it all in one repository. You already have everything organized by directory. If anything, you may want separate branches tracking work for each client which may involve changes to any of the directories.

Answer 2

Submodules are a bad solution for tightly coupled code. We had two main projects that shared a subproject for database migrations that both projects depended on. We implemented this with submodules, and the steps for making changes to the migrations were something like this:

1. Commit the changes to the submodule.
2. Push the changes to origin.
3. Back up to the superproject that you were currently in.
4. Commit and push the new submodule ref.
5. Move to the other superproject's copy of the submodule.
6. Pull the latest changes from origin.
7. Back up to that superproject.
8. Commit and push the new submodule ref.

On top of that, you always needed to make sure you were on the correct branch for all three projects. It was a huge pain. Submodules just weren't made for that sort of development. We ended up making the database migrations part of one of the two main projects, and the code just isn't shared anymore (it was only really shared as a convenience anyway).

I did look into subtree merging, but it only looked marginally better than submodules.

It really sounds like you should just leave it as one repository and use branching and tagging to manage the different versions of your various modules, especially if this is all to be deployed together anyway.