Jaki problem git subtreerozwiązuje? Kiedy i dlaczego powinienem używać tej funkcji?

Czytałem, że jest używany do rozdzielania repozytoriów . Ale dlaczego nie miałbym po prostu utworzyć dwóch niezależnych repozytoriów zamiast skleić dwa niepowiązane w jedno?

W tym samouczku GitHub wyjaśniono, jak wykonywać scalenia poddrzewa Git .

W pewnym sensie wiem, jak go używać, ale nie wiem, kiedy (przypadki użycia) i dlaczego i do czego się odnosi git submodule. Używałbym modułów podrzędnych, gdy mam zależność od innego projektu lub biblioteki.

Powinieneś uważać, aby wyraźnie zaznaczyć, o czym mówisz, kiedy używasz terminu `` poddrzewo '' w kontekście, gitponieważ w rzeczywistości istnieją tutaj dwa oddzielne, ale powiązane tematy:

Strategia łączenia git-subtree i git subtree .

TL; DR

Obie koncepcje powiązane z poddrzewem pozwalają efektywnie zarządzać wieloma repozytoriami w jednym. W przeciwieństwie do git-submodule, w którym tylko metadane są przechowywane w repozytorium głównym, w postaci .gitmodules , i musisz osobno zarządzać zewnętrznymi repozytoriami.

Więcej szczegółów

Strategia scalania poddrzewa git jest w zasadzie bardziej ręczną metodą wykorzystującą polecenia, do których się odwołujesz.

git-subtree jest opakowującym skryptem powłoki, który ułatwia bardziej naturalną składnię. W rzeczywistości jest to nadal część contribi nie jest w pełni zintegrowane z git ze zwykłymi stronami podręcznika. Dokumentacja jest przechowywana wzdłuż boku zamiast skryptu.

Oto informacje o użytkowaniu:

NAME
----
git-subtree - Merge subtrees together and split repository into subtrees


SYNOPSIS
--------
[verse]
'git subtree' add   -P <prefix> <commit>
'git subtree' add   -P <prefix> <repository> <ref>
'git subtree' pull  -P <prefix> <repository> <ref>
'git subtree' push  -P <prefix> <repository> <ref>
'git subtree' merge -P <prefix> <commit>
'git subtree' split -P <prefix> [OPTIONS] [<commit>]

Natknąłem się na całkiem niezłą liczbę zasobów na temat poddrzew, ponieważ planowałem napisać własny wpis na blogu. Zaktualizuję ten post, jeśli to zrobię, ale na razie oto kilka istotnych informacji na temat tego pytania:

Wiele z tego, czego szukasz, można znaleźć na tym blogu Atlassian autorstwa Nicoli Paolucciego w odpowiedniej sekcji poniżej:

Po co używać poddrzewa zamiast modułu podrzędnego?

Istnieje kilka powodów, dla których możesz znaleźć subtreelepszy w użyciu:

• Zarządzanie prostym przepływem pracy jest łatwe.
• gitObsługiwane są starsze wersje (nawet wcześniej v1.5.2).
• Kod podprojektu jest dostępny zaraz po clonezakończeniu super projektu.
• subtreenie wymaga od użytkowników Twojego repozytorium uczenia się niczego nowego, mogą zignorować fakt, że używasz go subtreedo zarządzania zależnościami.
• subtreenie dodaje nowych plików metadanych, jak submodulesrobi (tj .gitmodule.).
• Zawartość modułu można modyfikować bez konieczności posiadania oddzielnej kopii repozytorium zależności w innym miejscu.

Moim zdaniem wady są dopuszczalne:

• Musisz poznać nową strategię łączenia (tj subtree.).
• Przekazywanie kodu z powrotem upstream dla podprojektów jest nieco bardziej skomplikowane.
• Odpowiedzialność za niemieszanie kodu super i podprojektu w zatwierdzeniach spoczywa na Tobie.

Z dużą częścią zgodziłbym się również. Poleciłbym zapoznać się z tym artykułem, ponieważ omawia kilka typowych zastosowań.

Być może zauważyłeś, że napisał tutaj również kontynuację, w której wspomina o ważnym szczególe, który został pominięty w tym podejściu ...

git-subtree obecnie nie zawiera pilota!

Ta krótkowzroczność jest prawdopodobnie spowodowana faktem, że ludzie często dodają pilota ręcznie podczas pracy z poddrzewami, ale nie jest to również przechowywane w git. Autor szczegółowo opisuje łatkę, którą napisał, aby dodać te metadane do zatwierdzenia thatgit-subtree już generuje. Dopóki to nie trafi do oficjalnej głównej linii gita, możesz zrobić coś podobnego, modyfikując komunikat o zatwierdzeniu lub przechowując go w innym zatwierdzeniu.

Uważam również, że ten post na blogu jest bardzo pouczający. Autor dodaje trzecią metodę poddrzewa, którą wywołuje git-streedo miksu. Artykuł jest wart przeczytania, ponieważ wykonuje całkiem niezłą robotę porównując te trzy podejścia. Przedstawia swoją osobistą opinię o tym, co lubi, a czego nie, i wyjaśnia, dlaczego stworzył trzecie podejście.

Dodatki

• wymienianie poddrzew git
• Odłącz podkatalog

Myśli końcowe

W tym temacie przedstawiono zarówno możliwości git segmentacji, jak i segmentację, która może wystąpić, gdy funkcja po prostu nie trafia w ślad.

Osobiście wzbudziłem wstręt, git-submoduleponieważ uważam to za bardziej zagmatwane, aby współpracownicy mogli to zrozumieć. Wolę również zarządzać WSZYSTKIMI moimi zależnościami w ramach moich projektów, aby zapewnić łatwe do odtworzenia środowisko bez prób zarządzania wieloma repozytoriami. git-submodulejest jednak obecnie znacznie bardziej znany, więc dobrze jest być tego świadomym i w zależności od odbiorców, którzy mogą wpłynąć na twoją decyzję.

Po pierwsze: uważam, że twoje pytanie ma tendencję do uzyskiwania mocno upartych odpowiedzi i może być tutaj uznane za nie na temat. Jednak nie podoba mi się ta polityka SO i chciałbym nieco przesunąć granicę bycia na temat na zewnątrz, więc zamiast tego lubię odpowiadać i mam nadzieję, że inni też.

W samouczku GitHub, na który wskazałeś, znajduje się link do Jak korzystać ze strategii scalania poddrzewa, który daje punkt widzenia na zalety / wady:

Porównanie scalania poddrzewa z modułami podrzędnymi

Zaletą używania funkcji scalania poddrzewa jest to, że wymaga mniejszego obciążenia administracyjnego od użytkowników repozytorium. To działa ze starszymi (przed Git v1.5.2) klientów i masz prawo kod po klonie.

Jeśli jednak używasz modułów podrzędnych , możesz zdecydować, aby nie przenosić obiektów podmodułów . Może to być problem ze scalaniem poddrzewa.

Ponadto, jeśli wprowadzisz zmiany w innym projekcie, łatwiej będzie wprowadzić zmiany, jeśli użyjesz tylko modułów podrzędnych.

Oto mój punkt widzenia oparty na powyższym:

Często pracuję z ludźmi (= committerami), którzy nie są zwykłymi użytkownikami git, niektórzy wciąż (i na zawsze będą) borykać się z kontrolą wersji. Poinformowanie ich o tym, jak używać strategii scalania submodułów jest w zasadzie niemożliwe. Obejmuje koncepcje dodatkowych pilotów, łączenia, rozgałęzień, a następnie mieszania wszystkiego w jeden przepływ pracy. Ciągnięcie z góry i pchanie w górę to proces dwuetapowy. Ponieważ gałęzie są dla nich trudne do zrozumienia, to wszystko jest beznadziejne.

W przypadku modułów podrzędnych jest to dla nich nadal zbyt skomplikowane ( westchnienie ), ale łatwiej to zrozumieć: to tylko repozytorium w ramach repozytorium (znają hierarchię) i możesz normalnie pchać i ciągnąć.

Udostępnianie prostych skryptów opakowujących jest łatwiejsze imho dla przepływu pracy modułu podrzędnego.

W przypadku dużych super-repozytoriów z wieloma repozytoriami podrzędnymi istotną zaletą modułów podrzędnych jest rezygnacja z klonowania danych niektórych repozytoriów. Możemy to ograniczyć na podstawie wymagań pracy i wykorzystania miejsca na dysku.

Kontrola dostępu może być inna. Nie miałem jeszcze tego problemu, ale jeśli różne repozytoria wymagają różnych kontroli dostępu, skutecznie blokując niektórym użytkownikom dostęp do niektórych sub-repozytoriów, zastanawiam się, czy łatwiej to osiągnąć dzięki podejściu submodułowemu.

Osobiście jestem niezdecydowany, czego mam użyć. Więc podzielam Twoje zamieszanie: o]

Prawdziwy przypadek użycia, w którym poddrzewo git było zbawieniem:

Głównym produktem naszej firmy jest wysoki modułowość i rozwijany w kilku projektach w oddzielnych repozytoriach. Wszystkie moduły mają oddzielną mapę drogową. Cały produkt składa się ze wszystkich modułów wersji betonowych.

Równolegle dla każdego klienta dostosowywana jest konkretna wersja całego produktu - oddzielne oddziały dla każdego modułu. Czasami trzeba dostosować kilka projektów jednocześnie ( cross-module customization).

Aby mieć oddzielny cykl życia produktu (konserwacja, gałęzie funkcji) dla niestandardowego produktu, wprowadziliśmy poddrzewo git. Mamy jedno repozytorium git-subtree dla wszystkich niestandardowych modułów. Nasze dostosowywanie to codzienne „wypychanie poddrzewa git” z powrotem do wszystkich oryginalnych repozytoriów do gałęzi dostosowywania.

W ten sposób unikamy zarządzania wieloma repozytoriami i wieloma bankami. git-subtree kilkakrotnie zwiększyło naszą produktywność!

AKTUALIZACJA

Więcej szczegółów na temat rozwiązania, które zostało opublikowane w komentarzach:

Stworzyliśmy zupełnie nowe repozytorium. Następnie dodaliśmy każdy projekt, który miał gałąź klienta do tego nowego repozytorium jako poddrzewo. Mieliśmy zadanie Jenkinsa polegające na regularnym przekazywaniu zmian głównych w oryginalnych repozytoriach do gałęzi klienta. Pracowaliśmy tylko z „repozytorium klienta”, używając typowego przepływu git z gałęziami funkcji i konserwacji.

Nasze repozytorium „klienta” posiadało również skrypty budujące, które również dostosowaliśmy dla tego konkretnego klienta.

Istnieje jednak pułapka przedstawionego rozwiązania.

W miarę jak szliśmy coraz dalej i dalej od głównego rozwoju produktu, możliwa aktualizacja dla tego konkretnego klienta była coraz trudniejsza. W naszym przypadku było to w porządku, ponieważ stan projektu przed poddrzewem był już daleko od głównej ścieżki, więc poddrzewo wprowadza przynajmniej porządek i możliwość wprowadzenia domyślnego przepływu git.

Zasadniczo poddrzewo Git jest alternatywą dla podejścia Git-submodule: jest wiele wad, a raczej powiedziałbym, że podczas korzystania z git-submodules trzeba być bardzo ostrożnym. np. jeśli masz „jedno” repozytorium, a wewnątrz „jednego”, dodałeś kolejne repozytorium o nazwie „dwa” za pomocą modułów podrzędnych. Rzeczy, o które musisz zadbać:

• Kiedy zmieniasz coś w „dwóch”, musisz zatwierdzić i wcisnąć wewnątrz „dwa”, jeśli jesteś w katalogu najwyższego poziomu (tj. W „jednym”), zmiany nie zostaną podświetlone.

• Gdy nieznany użytkownik próbuje sklonować Twoje „jedno” repozytorium, po sklonowaniu „jednego” użytkownik musi zaktualizować moduły podrzędne, aby uzyskać „dwa” repozytorium

Oto niektóre z punktów i dla lepszego zrozumienia polecam obejrzenie tego filmu: https://www.youtube.com/watch?v=UQvXst5I41I

• Aby przezwyciężyć takie problemy, wymyślono podejście poddrzewo. Aby uzyskać podstawowe informacje o poddrzewie git, zapoznaj się z tym: https://www.youtube.com/watch?v=t3Qhon7burE

• Uważam, że podejście do poddrzewa jest bardziej niezawodne i praktyczne w porównaniu do modułów podrzędnych :) (jestem bardzo początkującym w mówieniu tych rzeczy)

Twoje zdrowie!

Aby dodać do powyższych odpowiedzi, dodatkową wadą korzystania z poddrzewa jest rozmiar repozytorium w porównaniu z modułami podrzędnymi.

Nie mam żadnych rzeczywistych metryk, ale biorąc pod uwagę, że za każdym razem, gdy wysyłany jest moduł, wszędzie tam, gdzie ten moduł jest używany, otrzymuje kopię tej samej zmiany w module nadrzędnym (kiedy jest później aktualizowana w tych repozytoriach).

Więc jeśli baza kodu jest mocno zmodularyzowana, suma się to dość szybko.

Jednak biorąc pod uwagę, że ceny magazynów zawsze spadają, może to nie być istotny czynnik.