Recommended workflow for multiple modules (themes)
I have an app (cms) which structure is like this:
BASE:
开发者_C百科 /application/
/public/
themes/
default/
mobile/
This is a base, central repository for all our projects. Then the projects get their own skin:
(which are based on /default/
theme)
CLONE1:
/application/
/public/
themes/
default/
mobile/
own/
...
own-theme-12/
(this app has 12 custom themes based on the default one).
The whole thing is about maintaining the applications and keeping all the CLONES up to date with the BASE.
Now, we add BASE as remote repo:
(/clone1/)$ git remote add base-repo /path/to/base.git
Then pull for updates when needed:
(/clone1/)$ git pull base-repo develop
When the .php
files in /application
are modified everything works great. The problem begins when we modify the files in default
theme in BASE repo (e.g. typo in reset.css
). We need those changes in CLONE1/default
theme and all of the CLONEx/own-x/
themes.
Of course some bash script will be needed to tell where to copy and commit the changes, but how to keep the whole thing in sync without merge conflicts?
We use git flow
. The default
and mobile
themes are not in the separate branches by now. Do we need them to be? We don't use submodules yet.
There are many ways to organize this workflow, but which would you choose as the optimal one?
You can use git-subtree to help with this sort of problem. Basically, what you're doing is building a custom app based on an upstream app, and your custom app has two kinds of changes: app fixes and special themes. You want to take the app fixes and send them upstream, but you don't want to send your special themes upstream.
If you create two subtrees at the toplevel: one for your upstream app, and one for your themes, you can then split/join them with git-subtree. The themes inherited from the upstream can be symlinked from the app directory into the themes dir. So you get something like this:
/app/code/*.php
/app/themes/default/
/app/themes/mobile/
/themes/default -> ../app/themes/default
/themes/mobile -> ../app/themes/mobile
/themes/own-1/
When you want to send app changes upstream, you do something like
git subtree split --prefix=app --rejoin
Considering the application needs those theme directories to function, they should be kept as directory, not as branches.
You cannot deploy several branches into production (you select version from one branch or another, not all of them). You can deploy multiple directories, allowing the application to run without having any knowledge about an SCM.
For the rest, a script executed as a merge driver could:
- merge the content of
BASE/default
tolocal/default
- check if the same file (like
reset.css
exists in other directories and start reporting the same evolutions on it as well).
I don't have specifics on the exact mechanism, but I suspect a merge driver is a good entry point to propagate the changes.
精彩评论