Partial Git deployment strategy?

Question

I need to setup a Kohana dev environment that allows me to make full use of shared module / system classes across separate applications. Each application typically belonging to a different client. I use Git for source control, but am struggling to come up with a clean deployment method that will allow me to pull only those parts of the dev environment specific to a client / app down into that client's production environment (assuming that the client's production environment will have Git installed).

Dev enviroment:

- kohana
  - applications
     - clientapp1
     - clientapp2
  - modules
  - public_html
     - clientapp1
     - clientapp2
  - system
     - 3.0.1
     - 3.0.5

Client 1's production environment:

- /
 - applications
     - clientapp1
 - modules
 - public_html
     - client_app1
 - system
     - 3.0.5

Naturally, I want to have total control over each client "sub repo" as if it were an independent repo (in terms of gitignore, etc). I have seen topics that cover Git's sparse checkout feature, but it seems like it may cause a few problems down the line from a maintenance point of view, and I don't like the idea of the entire repo's metadata existing in client's production environment repo.

As you can probably tell, I'm not exactly a Git poweruser, so any suggestions / wisdom are very welcome!

score 1 · Accepted Answer · edited May 23 '17 at 12:30

Ideally, each of your directories (app/clientapp1, app/clientapp2, public_html/clientapp1, ...) is a submodule

I.e: main project git repo:

kohana
  - applications
  - modules
  - public_html
  - system

Where you add your submodules:

- kohana
  - applications
     - clientapp1  -> remote: /path/to/app_client1app Git repo
     - clientapp2  -> remote: /path/to/app_client2app Git repo
  - modules
  - public_html
     - clientapp1  -> remote: /path/to/pubhtml_client1app Git repo
     - clientapp2  -> remote: /path/to/pubhtml_client2app Git repo
  - system
     - 3.0.1  -> remote: /path/to/sys Git repo, tag 3.0.1
     - 3.0.5  -> remote: /path/to/sys Git repo, tag 3.0.5

The fact that you are using only submodules allows you:

- /
  - applications
     - clientapp1  -> remote: /path/to/app_client1app Git repo
  - modules
  - public_html
     - clientapp1  -> remote: /path/to/pubhtml_client1app Git repo
  - system
     - 3.0.5  -> remote: /path/to/sys Git repo, tag 3.0.5

to define another main project, this time used for deployment
work directly in special deployment branches within those submodules, allowing you to control their files in a client specific environment.
(see true nature of submodules)

Great answer, thanks. Submodules seem the way to go, but it seems I may be asking too much; I don't like the idea of needing to maintain 3 separate submodule repos for each client distribution. A directory shuffle to make the dir layout more client-centric may help... — Mathew, May 28 '10 at 13:45
@MatW: I confirm 2 submodules cannot coexist within the same directory (see http://stackoverflow.com/questions/2922807/creating-a-union-branch-of-a-number-of-git-branches/2925458#2925458). As you comment, reorganizing the code layout to be closer to the deployment target might be a good avenue to explore. — VonC, May 28 '10 at 14:22

Partial Git deployment strategy?

1 Answers1