Jak zorganizować repozytoria git dla projektu?


9

Pracuję nad modułem synchronizacji treści dla Drupala. Istnieje moduł serwera, który znajduje się na stronie internetowej i udostępnia treści za pośrednictwem usługi internetowej. Istnieje również moduł klienta, który znajduje się w innej witrynie i pobiera i importuje zawartość w regularnych odstępach czasu.

Serwer jest tworzony na Drupal 6. Klient jest tworzony na Drupal 7. Będzie potrzebna wersja serwera Druapl 7. A potem będzie potrzeba wersji Drupal 8 zarówno klienta, jak i serwera, kiedy zostanie wydana w przyszłym roku.

Jestem całkiem nowy w git i kontroli źródła, więc zastanawiałem się, jaki jest najlepszy sposób na skonfigurowanie repozytoriów git? Czy byłoby w przypadku posiadania osobnego repozytorium dla każdej instancji, tj .:

Drupal 6 server = 1 repository
Drupal 6 client = 1 repository
Drupal 7 server = 1 repository
Drupal 7 client = 1 repository
etc 

Czy może bardziej sensowne byłoby posiadanie jednego repozytorium dla serwera, a drugiego dla klienta, a następnie tworzenie oddziałów dla każdej wersji Drupal?

Obecnie mam 2 repozytoria - jedno dla klienta, a drugie dla serwera.

Odpowiedzi:


7

O ile projekt nie jest naprawdę ogromny, wybrałbym pojedyncze repozytorium z podkatalogami dla serwera i klienta i utworzyłbym gałąź dla każdej wersji. Nadal możesz mieć wiele kopii repozytorium na wypadek, gdybyś chciał uzyskać dostęp do wielu wersji jednocześnie.

Dzięki utrzymywaniu wielu repozytoriów przesyłanie zmian będzie trudniejsze niż to konieczne (zmiana bazy jest łatwiejsza niż stosowanie poprawek). W (nieprawdopodobnym) przypadku nie zostaną wprowadzone zmiany w wielu wersjach, nadal nic nie stracisz ...

Ponadto zawsze możesz przełączyć się na wiele repozytoriów: wystarczy sklonować repozytorium i usunąć gałęzie, których nie chcesz. Odwrót jest trudniejszy.

Wybrałbym wiele repozytoriów tylko wtedy, gdy serwer i klient nic nie współużytkują lub jeśli kod jest naprawdę ogromny.


W ten sposób zamierzam iść, ponieważ Drupal przechowuje różne wersje jako oddziały. Też dałbym +1, ale potrzebuję 15 powtórzeń!
littledynamo

4

Widziałem i pracowałem z takimi odmianami. Wszystko w jednym folderze z podfolderami dla serwera i klienta lub po jednym repozytorium. Wolę pojedyncze repo dla każdej głównej części projektu.

W przypadku dużych zmian wersji po prostu utworzę też nowe repozytorium. Zdecydowanie nie mają dla nich różnych gałęzi. Chociaż gałęzie są potężne do implementacji nowej funkcjonalności i być może jednej stałej gałęzi wdrażania, zawsze unikam zbyt wielu z nich działających równolegle przez długi czas. Zawsze będziesz musiał je utrzymywać (wykonywać zmiany bazy, gdy zmieni się gałąź master itp.), Więc utrzymuj podstawową strukturę tak prostą, jak to możliwe. Posiadanie dodatkowego repo jest (moim skromnym zdaniem) mniej bolesne niż żonglowanie gałęziami w różnych stanach. Zwłaszcza jeśli klient i serwer nie współdzielą dużo kodu.

Nie wiem wiele o Drupal i tym, jak silne są różnice między wersjami. Dlatego preferuję różne repo, bardziej opiera się na moim doświadczeniu z Railsami. Pomiędzy wersjami występują czasem duże różnice w nazwach plików lub strukturze folderów (np. Potok zasobów), co sprawia, że ​​wygodniej jest utworzyć nowe repozytorium. Drupal (lub jakikolwiek inny framework) może mieć mniejsze różnice, wtedy byłoby po prostu kontynuować w ramach istniejącego repozytorium.


1
Dzięki. Jest to interesujące, ponieważ właśnie odkryłem, że moduły Drupal Core przechowują osobne wersje jako gałęzie. Myślę, że ma sens naśladowanie tej struktury. Dałbym +1, ale potrzebuję 15 powtórzeń!
littledynamo
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.