Praca z Zend Framework i Git w dużych projektach

Mam problemy z pracą z ZF i Git w całkiem dużym projekcie. Aplikacja zf ma około 20 modułów i na razie wszystko jest przechowywane w jednym repozytorium git. Więc kiedy płacisz za aplikację, zamawiasz cały zestaw modułów, arkuszy CSS, plików JS itp.Praca z Zend Framework i Git w dużych projektach

Co chciałbym zrobić, to coś takiego jak w wordpress lub drupal: masz swoją główną aplikację i dla każdego moduł masz osobne repozytorium git, które można sprawdzić w katalogu modułów. Po dokonaniu zakupu pracujesz nad nim, a następnie go zatwierdzasz. Ale zend nie może tego zrobić, ponieważ pliki multimedialne (css, js, images) są przechowywane w inny sposób w katalogu/public (każdy moduł może mieć własny css, pliki js w/public/_MODULE_NAME_/css na przykład). Pracuję w/application/modules /.

Pytanie więc brzmi: jak pracować z aplikacjami modułowymi Zend Framework i git?

Źródło

2012-07-06 Alex Dicianu

Zawsze możesz umieścić zasoby statyczne (CSS, JS, itp.) W swoim katalogu modułów i albo skopiować je do 'public' jako zadanie kompilacji lub utworzyć dowiązania symboliczne w' public' – Phil

brzmi jak podobny problem, że raz miał: http://stackoverflow.com/questions/6680768/how-do-i-organize-my-git-repo – eckes

W ZF2 moduły są w pełni niezależne, można je dołączyć jako submoduł (całkowicie odrębne repozytorium), ale w ZF1 o określonej strukturze nie jest to możliwe. – bedeabza

zwykle udaje się poradzić sobie z konfiguracją miękkich linków, posiadające jedną super-projekt w foldera Web i symlinking z modułów z innego folderu:

* SuperProject/ 
    + application/ 
    + ModuleA --> ../../Modules/ModuleA/application 
    + ModuleB --> ../../Modules/ModuleB/application 
    + config/ 
    + views/ 
    + layouts/ 
    + public/ 
    + ModuleA --> ../../Modules/ModuleA/public 
    + ModuleB --> ../../Modules/ModuleB/public 
    + css/ 
    + js/ 
    + library/ 
+ Modules/ 
    * ModuleA/ 
    + application/ 
     + config/ 
     + views/ 
     + models/ 
    + public/ 
     + css/ 
     + js/ 
    * ModuleB/ 
    + application/ 
     + config/ 
     + views/ 
     + models/ 
    + public/ 
     + css/ 
     + js/

Do ulubionych katalogi są repozytoria The SuperProject/publiczny jest punktem wejścia dla serwera http (z dowiązaniami symbolicznymi po włączeniu oczywiście). Oczywiście nie dodajesz żadnych plików modułu w repozytorium SuperProject, ale tylko zmiany w katalogach globalnych (na przykład application/config /) - w najlepszym razie ignorujesz moduły poprzez plik .git_ignore. Ponieważ metoda ta opiera się na dowiązaniach symbolicznych, będzie działać tylko na systemach unixoid. Chociaż nie jest doskonały, to najmniej kłopotów.

Źródło

2012-07-26 10:32:11 Lars

dotyczące dowiązań symbolicznych: czy to może działać na Win32 z połączeniami (http://technet.microsoft.com/en-us/sysinternals/bb896768.aspx, http://en.wikipedia.org/wiki/Symbolic_link # NTFS_Junction_points)? – eckes

@eckes to może działać, jeszcze go nie wypróbowałem. Ale od szybkiego badania wydaje się, że implementuje tę samą cechę, co symboliczne dowiązanie symboliczne. Czy masz system Windows, aby go przetestować? – Lars

tylko XP. I naprawdę interesująca rzecz (linki symboliczne NTFS, które obsługują również pliki, nie tylko foldery, http://en.wikipedia.org/wiki/NTFS_symbolic_link) nie działają tam, ale wymagają przynajmniej Vista. – eckes

Praca z Zend Framework i Git w dużych projektach

Odpowiedz

Powiązane problemy