Mam repozytorium Git, w którym cały mój kod znajduje się w gałęzi master, a poprzednio po prostu ignorowałem wszystkie pliki Drupal, więc zachowałem ścisłą separację między kodem, który napisałem (lub zmodyfikowałem lub mógłbym zmodyfikować) a kodem które można wygenerować za pomocą Drusha lub cokolwiek innego.
To wydawało się dobrą strategią, dopóki nie musiałem ulepszać Drupala. Uświadomiłem sobie, że chcę móc wycofać się, jeśli coś pójdzie nie tak, i jakiego lepszego narzędzia użyć do tego celu niż Git. Pomyślałem sobie, że będzie to idealna sytuacja dla gałęzi funkcji, więc stworzyłem drupal-7.14gałąź, dałem jej własną, .gitignoreaby zignorować cały mój kod i pliki ustawień i zwracać uwagę tylko na te pliki, które są częścią instalacji Drupal, których nie chciałbym dotykać. Zrobiłem aktualizację ręcznie (pobieranie, rozpakowywanie, rozpakowywanie, kopiowanie), sortując przypadki graniczne, takie jak robots.txt i .htaccess, i zastępując .gitignore Drupala własnym. Naprawiłem niektóre ustawienia, które działały z 7.14, ale nie z 7.15, aby odzyskać po błędzie 500, a potem wszystko wydawało się idealne. Zmieniłem nazwę oddziału drupal-7.15i już miałem iść szczęśliwie.
Dopóki nie zdałem sobie sprawy z tego, co nieumyślnie zrobiłem: pliki, które wcześniej nie zostały wyśledzone przez moją gałąź master, ale pozostały w katalogu roboczym, były teraz usuwane z katalogu roboczego podczas sprawdzania master, ponieważ nie były już plikami nie śledzonymi! Nie!
Jeśli połączę drupal-7.15gałąź z mistrzem, utracę separację kodu.
Prawdopodobnie istnieje sposób na konwersję gałęzi do submodułu. Zakładając, że to możliwe, może to być najlepsza strategia. Zanim to zrobiłem, wiedziałem, że submoduły są „właściwym” rozwiązaniem, ale ponieważ nie zdawałem sobie sprawy z efektu ubocznego używania rozgałęzień dla plików wcześniej nie śledzonych, postanowiłem skrócić rogi i pójść tą drogą. (Również wszystkie podejścia, które widziałem przy użyciu podmodułów z Drupalem, zakładają, że zaczynasz nowy projekt, a Drupal będzie gałęzią master. Nie jest dla mnie pożądane, aby uczynić kod kogoś innego gałęzią master, a ja już to zrobiłem repozytorium z gałęzią master. Wyglądało na to, że samo uaktualnienie byłoby niepotrzebnie skomplikowane).
Może być jakieś inne rozwiązanie, o którym nie myślałem.
Jak najlepiej się z tego zregenerować przy jak najmniejszej liczbie wad?
AKTUALIZACJA : Jest w fazie rozwoju (na maszynie wirtualnej z systemem Linux na moim laptopie) i nie została jeszcze wprowadzona do produkcji. Zanim przejdziemy do produkcji, planuję mieć wszystko opakowane w moduły funkcji, ale to jeszcze nie jest na miejscu.
AKTUALIZACJA 2 : Podmoduły mogą nie działać. Według Pro Git „Submodules pozwalają zachować repozytorium Git jako podkatalog innego repozytorium Git”. Drupal nie zapewnia tak miłej separacji. Zamiast całego kodu Drupala znajdującego się w podkatalogu, relacja jest mniej więcej odwrócona, ale nadal nie ma czystej separacji, ponieważ możesz edytować swój plik .htaccess i plik robots.txt, więc kod i repozytorium Drupal są ze sobą mieszane. Ja patrząc na obejście tego problemu .
źródło
Odpowiedzi:
Z powyższej dyskusji wynika, że twoje pytanie nie dotyczy naprawienia repozytorium git, ale utrzymania witryny Drupal w git i tego, jak to działa z podstawowymi aktualizacjami.
Myślę, że standardową praktyką jest przechowywanie wszystkich plików w twoim repozytorium, w tym rdzenia Drupala. Oddzielenie kodu Drupala od kodu niestandardowego wydaje się fajnym pomysłem, ale nie uważam tego za konieczne i nie widzę, jakie to daje korzyści. Wydaje się również, że zakłada się, że nigdy nie będziesz chciał łatać rdzenia (lub musisz to zrobić w ramach wdrożenia), co, choć nie jest najlepszą praktyką, jest zdecydowanie czymś, co chcesz zrobić, jeśli coś się zepsuje w produkcji. Utrzymywanie ładnych i skoncentrowanych zobowiązań pomaga również uzyskać tego rodzaju separację.
Rozwiązaniem, które zastosowałem, jest utrzymanie całego kodu w tym samym repozytorium, umieszczenie jak największej liczby Funkcji lub innych rodzajów eksportu / kodu / konfiguracji oraz utrzymanie listy poprawek, które należy zastosować do niedziałającego -box core i contrib.
Po aktualizacji rdzenia zacznij w swoim środowisku programistycznym:
drush sql-dump). Dokonaj zatwierdzenia za pomocą zrzutu lub zapisz go w bezpiecznym miejscu.drush up drupal)drush updbna produkcji.git reset --hard HEAD~2należy to zrobić), albo cofnij dwa zatwierdzenia, jeśli chcesz zachować historię. Zamień bazę danych na zrzut.Zrzut bazy danych jest konieczny, ponieważ w przeciwnym razie nie można cofnąć zmian dokonanych w bazie danych przez aktualizacje. Możesz także wykonać aktualizację w oddziale, w którym to przypadku cofnięcie oznacza tylko wypisanie wzorca. Jest to trochę niewskazane, jeśli pracujesz na jednej stronie deweloperów, ponieważ tak naprawdę nie możesz przełączyć się z powrotem na master i nadal pracować tam równolegle z powodu bazy danych.
Korzystanie z tego prostszego przepływu pracy po stronie git pozwoli ci wykorzystać pełną moc git, gdy jest to potrzebne, bez komplikacji podmodułów itp. Jeśli to nie wydaje się odpowiednie, czy możesz wyjaśnić, dlaczego potrzebujesz dalszego oddzielenia kodu?
źródło
Z moich komentarzy powyżej, to pytanie, które masz, dotyczy utrzymywania plików witryny Drupal za pomocą git i tego, jak to działa z podstawowymi aktualizacjami. Nie wspominałeś nic o tworzeniu kopii zapasowej i aktualizacji bazy danych. Spróbuję nie kopiować niczego z odpowiedzi gorona.
Stworzyłem post na blogu o tym problemie Uaktualnienie rdzenia Drupal na twojej stronie dzięki Git
Alternatywne metody
Nie podałeś tego, ale jeśli chcesz śledzić zmiany między wersjami Drupala, zrobiłbym to, używając tagów zamiast gałęzi . Po zakończeniu zatwierdzania aktualizacji do master , oznacz kod jako 7.x.
źródło
Korzystam z instalacji z dwiema gałęziami, tak jak OP: jedną z własnym kodem niestandardowym i jedną z moimi plikami niestandardowymi i podstawowymi. Zetknąłem się z tą samą sytuacją: ignorowane pliki podstawowe są usuwane podczas przełączania między oddziałami.
Skończyło się na tym, że mam dwa identyczne katalogi git: - jeden do pracy nad moim niestandardowym kodem, z podstawowymi plikami obecnymi, ale zignorowanymi, i nigdy nie przestawiłbym się na „pełną” gałąź w tym katalogu - jeden do wykonywania scaleń, więc mógłbym wykonuj przełączanie gałęzi i scalanie tylko w tym katalogu.
Powodem, dla którego wybrałem tę konfigurację z dwoma gałęziami, jest to, że chcę łatwo śledzić wszystkie lokalne zmiany do plików podstawowych, łatwiej jest sprawdzać i ponownie stosować podstawowe mody podczas uaktualniania plików podstawowych.
źródło