I\'m trying to ascertain best-practices for shared code amongst Git repositories.
So far, I\'ve obviously come across submodules which seem like they - almost - fit
A submodule is a git repository, with its own .git directory, so it must be contained in a directory. I don't believe there's any way to easily get around that. You're going to have to package your stuff into a directory somehow - and if core.php goes with the stuff in core, it makes complete sense for them to be together in a submodule repo!
rmk's answer, suggesting you do this all in one repo, using core and core.php as a starting point is another reasonable one. You should make your decision based on your anticipated workflow. A submodule will be good if you plan on modifying the core* content separately from the projects which use it; you can then update the submodules in the various projects that use it. A baseline repository will be good if you want to modify the core* content to suit a specific project; you can then pull from the baseline repo to get updates, merging them with the changes you've made in the project repo.
Perhaps you are best off maintaining core.php and core in a separate repo, and then using it as a remote. Then you can manage it by pulling it into any project it is used. In order to do this, just start the new project as a separate git repo, and then pull in the 'core' repo as a subtree.
This chapter shows you how to do it:
Updated Reference: http://git-scm.com/book/en/v2/Git-Tools-Advanced-Merging#_subtree_merge Original Reference: https://git-scm.com/book/en/v1/Git-Tools-Subtree-Merging
It is a little better for you than the setup advised in the previous section of the book (6.6).
Look at it; it might be helpful.
If you can use symlinks (e.g. you are not using Windows), then you can set up core
and core.php
like this:
# "base" repository layout:
core/
core.app
# each app repository layout:
base/
core/
core.php
core -> base/core/
core.php -> base/core.php
app/
In each app repository, the base/
directory is either a submodule that uses the “base” repository or a subtree merge of the “base” repository.
Both methods will let you start making changes to the base code in the context of a particular app and later pull those changes back into the main base repository. When using submodules you have to be careful to always publish new base commits before publishing any app commits that reference those new base commits (this is not a problem when using subtree merges because each app is “flat” and effectively has its own copy of the base).
The third-party git subtree command seems like a very nice way to manage the subtree merge, if you decide against submodules.
git init newapp
cd newapp
ln -s base/core
ln -s base/core.php
git add core core.php
git commit -m'point to base (to be added next)'
# hook up base
git subtree add --prefix=base git@git.example.com:me/app_base.git master
mkdir app
# edit app/bar.php
# update base
git subtree pull --prefix=base git@git.example.com:me/app_base.git master
.
|-- .git/
| |-- ...
| `-- ...
|-- app/
| `-- bar.php
|-- base/
| |-- core/
| | `-- foo.php
| `-- core.php
|-- core -> base/core/
`-- core.php -> base/core.php
git init newapp
cd newapp
ln -s base/core
ln -s base/core.php
git add core core.php
git commit -m'point to base (to be added next)'
# hook up "base"
git submodule add git@git.example.com:me/app_base.git base
git commit -m'incorporate base'
mkdir app
# edit app/bar.php
# update base
(cd base && git fetch origin && git merge origin/master)
git add base
git commit -m'updated base'
.
|-- .git/
| |-- ...
| `-- ...
|-- .gitmodules
|-- app/
| `-- bar.php
|-- base/
| |-- .git/
| | |-- ...
| | `-- ...
| |-- core/
| | `-- foo.php
| `-- core.php
|-- core -> base/core/
`-- core.php -> base/core.php