Podkatalogi Checkout w Git?

Nie ma realnego sposobu, aby to zrobić w git. A jeśli nie będziesz wprowadzać zmian, które wpływają na oba drzewa jednocześnie jako jedna jednostka robocza, nie ma dobrego powodu, aby używać jednego repozytorium dla obu. Myślałem, że przegapię tę funkcję Subversion, ale odkryłem, że tworzenie repozytoriów ma tak małe administracyjne obciążenie umysłowe (po prostu ze względu na fakt, że repozytoria są przechowywane tuż obok ich roboczej kopii, zamiast wymagać ode mnie wyraźnego wybrania jakiegoś miejsca poza roboczą kopią copy), że przyzwyczaiłem się do robienia wielu małych, jednofunkcyjnych repozytoriów.

Jeśli nalegasz (lub naprawdę tego potrzebujesz), możesz utworzyć repozytorium git z katalogami mytheme i myplugins i dowiązaniami symbolicznymi z instalacji WordPressa.

MDCore napisał (a):

Wykonanie commitu, np. mytheme zwiększy numer rewizji dla myplugin

Zauważ, że nie jest to problemem dla git, jeśli zdecydujesz się umieścić oba katalogi w jednym repozytorium, ponieważ git całkowicie rezygnuje z koncepcji monotonicznie rosnącej liczby wersji dowolnej formy.

Jedynym kryterium, jakie rzeczy należy złożyć w jednym repozytorium w git, jest to, czy stanowi ono pojedynczą jednostkę, tj. w Twoim przypadku, czy są zmiany, gdzie nie ma sensu patrzeć na zmiany w każdym katalogu w izolacji. Jeśli masz zmiany, w których musisz edytować pliki w obu katalogach jednocześnie i edycje należą do siebie, powinny być jednym repozytorium. Jeśli nie, to nie glom je razem.

Git naprawdę bardzo chce, abyś używał osobnych repozytoriów dla osobnych podmiotów.

Submodule

Nie dotyczą chęci przechowywania obu katalogów w jednym repozytorium, ponieważ faktycznie wymuszają posiadanie osobnego repozytorium dla każdego katalogu, które następnie są łączone w innym repozytorium za pomocą podmodułów. Co gorsza, ponieważ katalogi wewnątrz instalacji WordPress nie są bezpośrednimi podkatalogami tego samego katalogu i są również częścią hierarchii z wieloma innymi plikami, używanie repozytoriów per-directory jako podmoduł w zunifikowanym repozytorium nie przyniosłoby żadnych korzyści, ponieważ zunifikowane repozytorium nie odzwierciedlałoby żadnego przypadku użycia / potrzeby.

Jedną z rzeczy, których nie lubię w rzadkich checkouts, jest to, że jeśli chcesz sprawdzić podkatalog, który ma kilka katalogów głęboko, twoja struktura katalogów musi zawierać wszystkie katalogi prowadzące do niego.

Jak obejść to jest klon repo w miejscu, które nie jest moim obszarze roboczym, a następnie utworzyć dowiązanie symboliczne w moim katalogu obszaru roboczego do podkatalogu w repozytorium. Git działa tak całkiem ładnie, ponieważ takie rzeczy jak git status będą wyświetlać pliki zmian względem Twój aktualny katalog roboczy.

Właściwie, "wąskie", "częściowe" lub "skąpe" kasy są obecnie intensywnie rozwijane dla Gita. Uwaga, pełne repozytorium będzie nadal dostępne pod .git. Tak więc, pozostałe dwa posty są aktualne dla bieżącego stanu Gita, ale wygląda tak, jakbyśmy w końcu byli w stanie zrobić małe checkouts. Sprawdź listy dyskusyjne jeśli interesuje cię więcej szczegółów-szybko się zmieniają.

git clone --filter od git 2.19 działa teraz na Githubie (testowany 2020-09-18, git 2.25.1)

Ta opcja została dodana wraz z aktualizacją protokołu zdalnego i naprawdę zapobiega pobieraniu obiektów z serwera.

Aby sklonować tylko obiekty wymagane dla d1 tego repozytorium: https://github.com/cirosantilli/test-git-partial-clone potrafię:

git clone \
  --depth 1 \
  --filter=blob:none \
  --no-checkout \
  https://github.com/cirosantilli/test-git-partial-clone \
;
cd test-git-partial-clone
git checkout master -- d1

Omówiłem to bardziej szczegółowo w: Git: jak sklonować podkatalog tylko Gita repozytorium?

Jak wskazuje twoja edycja, możesz użyć dwóch oddzielnych gałęzi do przechowywania dwóch oddzielnych katalogów. To utrzymuje je w tym samym repozytorium, ale nadal nie możesz mieć commitów obejmujących oba drzewa katalogów. Jeśli masz zmianę w jednym, która wymaga zmiany w drugim, będziesz musiał zrobić to jako dwa oddzielne commity, i otwierasz możliwość, że para checkouts z dwóch katalogów może wyjść z synchronizacji.

Jeśli chcesz traktować parę katalogów jako jeden Jednostka, możesz użyć "WordPress / wp-content" jako głównego repo i używać .plik gitignore na najwyższym poziomie ignoruje wszystko oprócz dwóch podkatalogów, które są interesujące. Jest to prawdopodobnie najbardziej rozsądne rozwiązanie w tym momencie.

Podobno od dwóch lat pojawiają się niewielkie checkouty, ale nadal nie ma po nich śladu w repo Git development, ani żadnych oznak, że niezbędne zmiany kiedykolwiek tam nadejdą. Nie liczyłbym na nich.

Nie można pobrać pojedynczego katalogu repozytorium, ponieważ całe repozytorium jest obsługiwane przez pojedynczy .folder git w katalogu głównym projektu zamiast mnóstwa subversion .katalogi svn.

Problem z pracą na wtyczkach w jednym repozytorium polega na tym, że wykonanie commitu do np. mytheme zwiększy numer wersji dla myplugin, więc nawet w subversion lepiej jest używać oddzielnych repozytoriów.

Paradygmat subwersji dla podprojekty to svn: externals co tłumaczy się nieco na submodules w git (ale nie do końca w przypadku, gdy używałeś wcześniej svn: externals.)

Jest tu Inspiracja. Wystarczy użyć shell regex lub git regex.

git checkout commit_id */*.bat  # *.bat in 1-depth subdir exclude current dir, shell regex  
git checkout commit_id '*.bat'  # *.bat in all subdir include current dir, git regex

Użyj cudzysłowu, aby uniknąć interpretacji regex powłoki i przekazać symbole wieloznaczne do Gita.

Pierwszy nie jest rekurencyjny, tylko pliki w 1-głębi subdir. Ale drugi jest rekurencyjny.

Jeśli chodzi o Twoją sytuację, następujące informacje mogą wystarczyć.

git checkout master */*/wp-content/*/*
git checkout master '*/wp-content/*'

Wystarczy zhakować linie zgodnie z wymaganiami.

Możesz przywrócić niezatwierdzone zmiany tylko do określonego pliku lub katalogu:

git checkout [some_dir|file.txt]