Jak użyć git do przechowywania plików domeny pod DA z uwzględnieniem uprawnień?

[dan 2]

Mam serwer VPS z directadminem na nim parę swoich projektów, Pojawia się oczywiście problem synchronizacji lokalnej wersji roboczej z produkcyjną na serwerze. Chcę to sobie maksymalnie usprawnić.

 

Lokalnie na maszynie developerskiej stosuje gita do obsługi wersjonowania (windows, gui).

 

Chcę mieć możliwość z synchronizacji repo z VPSem (najlepiej dla różnych użytkowników, tak jak standardowo DA robi, użytkownik-domeny). Tj. mam projekt A, użytkownik USERA w DA, projekt B, użytkownika USERB, itd. - jak to pogodzić przy synchronizacji plików, żebym nie musiał odpalać chown dla całych katalogów?

 

Doczytałem, że jak już to najlepiej użyć gitosis do zarządzania repo. Gita mniej więcej ogarniam (co prawda pod Windowsem i za pomocą GUI, dlatego mam nieco zagwozdek jak to uruchomić na Debianie...).

 

Prośba o sugestie jak to rozwiązać od doświadczonych kolegów albo przynajmniej nadanie kierunku :-)

-----

gitolite rzekomo lepszy po chwilowych poszukiwaniach...

 

I chyba pomieszałem użytkowników, którzy mają uprawnienia do repo z użytkownikami na serwerze (konta DA). W zasadzie na chwilę obecną nie potrzebuję więcej niż jednego użytkownika z dostępem do repo, bardziej zależy mi na jak najłatwiejszej aktualizacji plików z maszyny developerskiej na produkcyjną z DA z zachowaniem kontroli i możliwością ew. cofania zmian.

 

 

Edytowano Lipiec 25, 2013 przez dan (zobacz historię edycji)

[blackfire 185]

USERA, USERB to są różne konta unixowe? Mówisz o chown'owaniu po synchronizacji więc zakładam że tak i że możesz zrobić ssh USERA@serwer i ssh USERB@serwer. Jeżeli nie, to daj znać bo wtedy to będzie trochę inaczej wyglądać.

 

W takim układzie nie potrzebujesz żadnego gitolite'a (o gitosisie zapomnij, nie jest od lat utrzymywany), masz po prostu dwa niezależne repozytoria, każde na swoim koncie.

 

Przeczytaj tego posta, żeby się zorientować w praktykach związanych z obsługą zdalnych repo gita, powinien Ci wyjaśnić, dlaczego masz użyć dwóch repo na każdym koncie:

 

http://www.megiteam.pl/blog/2009/11/01/zeby-bylo-git/

 

Jak już na każdym koncie masz katalog na repo (powiedzmy ~/app.git) i katalog na drzewo robocze (powiedzmy ~/app), to po prostu ustawiasz odpowiednie remote'y w swoich lokalnych repozytoriach, coś typu:

git remote add origin ssh://USERA@SERWER/~/app.git

Dla serwisu USERB analogicznie. Pamiętaj, żeby odciąć dostęp do katalogu ~/app/.git (w katalogu roboczym), na przykład .htaccessem.

 

Jeżeli -- czego się trochę spodziewam, czytając o zmianie właściciela plików -- pchasz zmiany do tych repozytoriów logując się na konto roota, to przestań i nie rób tak więcej. Jak najbardziej da się wykonać chown po pchnięciu zmian, ale to jest na tyle zły pomysł, że nie podam Ci rozwiązania.

[dan 2]

@blackfire - wielkie dzięki za wskazówki i linka, zagłębiam się w temat dalej :-)

 

Tak, USERA, USERB to userzy linuxa. Faktycznie pchanie zmian z konta danego usera rozwiąże problem zmiany uprawnień plików.

[dan 2]

@blackfire - w tym artykule z linku na megiteam jest użyta konstrukcja, repozytorium domowe, na serwerze repozytorium "serwerowe" i do tego tworzona jest kopia robocza "repozytorium". Jest jakieś przeciwwskazanie żeby "serwerowe" repozytorium było jednocześnie plikami serwera? (w skrócie chodzi o to żeby nie tworzyć kopi repozytorium w celu w ogóle uruchomienia aplikacji na serwerze... - mam nadzieję, że jasno się napisałem...)

[megi 358]

Dokładnie o tym jest ostatni akapit tego artykułu Artykuł jest z 2009 roku i te zmiany o których Grzesiek pisał, czyli że git domyślnie nie pozwoli Ci na opublikowanie zmian do repozytorium, które zawiera katalog roboczy są już w gicie. Jeżeli miałbyś katalog roboczy i repo w jednym to git push nie spowoduje, że zmiany będą widoczne w aplikacji, jeżeli o to Ci chodzi.

Edytowano Lipiec 25, 2013 przez megi (zobacz historię edycji)

[dan 2]

@megi - świeta racja, choć walczyłem wytrwale, żeby tego uniknąć... ;-) W praktyce da się ustawić odpowiednią flagę i działać bez kopii repo ale w codziennym użyciu wychodzą babole i problemy w synchronizacji. Własnym doświadczeniem potwierdzam, że jednak pośrednie repo na serwerze daje pracę bez zgrzytów aktualizacyjnych.