Question

Here’s the scene:
I’m currently working on my own framework and on a client’s website. Here is the structure:

.
..
_application
_framework
_public

I’d like to have a repo with _framework/* _public/index.php and the structure _application (empty folders for _controllers _models and _views) on github. Also I’d like to have a repo containing ALL of this locally.

I understood that with git-modules I could do this, but after looking up some tutorials I still don’t understand the way of doing this.

Could someone explain it a bit more to me? Thanks a lot!

Answer 1

It seems to me that you could define one repo per structure you want, and combine them in a super-project through submodules.

See this question for some details on the nature of submodules.

Extract:

A submodule enables you to have a component-based approach development, where the main project only refers to specific commits of other components (here “other Git repositories declared as sub-modules”).

A submodule is a marker (commit) to another Git repository which is not bound by the main project development cycle: it (the “other” Git repo) can evolves independently.
It is up to the main project to pick from that other repo whatever commit it needs.

However, should you want to, out of convenience, modify one of those submodules directly from your main project, Git allows you to do that, provided you first publish those submodule modifications to its original Git repo, and then commit your main project referring to a new version of said submodule.

But the main idea remains: referencing specific components which:

• have their own lifecycle
• have their own set of tags
• have their own development

The list of specific commits you are referring to in your main project defines your configuration (this is what Configuration Management is all about, including mere Version Control System)

---

So if you really have two structure which can evolve independently one from another, submodules are a good fit.