I am planning my directory structure for a linux/apache/php web project like this:
Only www.example.com/webroot/
will be exposed in apache
www.example.com/
webroot/
index.php
comp1/
comp2/
component/
comp1/
comp1.class.php
comp1.js
comp2/
comp2.class.php
comp2.css
lib/
lib1/
lib1.class.php
the component/
and lib/
directory will only be in the php path.
To make the css and js files visible in the webroot directory I am planning to use symlinks.
webroot/
index.php
comp1/
comp1.js (symlinked)
comp2/
comp2.css (symlinked)
I tried following these principles:
- layout by components and libraries, not by file type and not by "public' or 'non public', index.php is an exception. This is for ea开发者_运维百科sier development.
- expose onle the minimal set of files in a public web directory and make everything else unaccesable to the web. Symlinking files that need to be public for the components and libs to a public location, but still mirroring the layout. So the component and library structure is also visible in the resulting html code in the links, which might help development.
- git usage should be safe and always work. it would be ok to follow some procedure to add a symlink to git, but after that checking them out or changing branches should be handled safely and clean
How will git handle the symlinking of the single files correctly, is there something to consider?
When it comes to images I will need to link directories, how to handle that with git?
component/
comp3/
comp3.class.php
img/
img1.jpg
img2.jpg
img3.jpg
They should be linked here:
webroot/
comp3/
img/ (symlinked ?)
If using symlinks for that has disadvantages maybe I could move images to the webroot/ tree directly, which would break the first principle for the third (git practicability).
So this is a git and symlink question. But I would be interested to hear comments about the php layout, maybe you want to use the comment function for this.
As soon as you need to reuse some set of files elsewhere, that's when you should start thinking in term of components or (in git) submodules
Instead of managing webroot
, and comp
, and lib
within the same repo (which is the SVN or the "Centralized way" for CVCS), you define:
- n repos, one per component you need to reuse (so '
img
' would be a Git repo reused as a submodule withinwebroot
, for instance) - a main project for referencing the exact revision of those submodules you need.
That is one of advantages of submodules of symlink: you reference one exact revision, and if that component has some evolutions of its own, you don't see them immediately (not until you update your submodule anyway).
With a symlink, you see whatever state is the set of files at the other end of that link.
精彩评论