Używanie git flow z poddrzewem git

Question

Właśnie zmigrowałem duże repozytorium svn do git i zacząłem używać gitflow. To działało jak czar, ale teraz myślę o podzieleniu tego dużego repo na kilka mniejszych.

Niech supposse drzewo katalogów repo jest następujący:

/repo 
    - libs 
    - apps 
    -- app 1 
    -- app 2 

I chcemy podzielić ją na trzy repo, jeden z konstrukcją szkieletową (libs i Aplikacje katalogi) i dwóch pozostałych z apps katalogów .

Jeśli użyję podklasa git w taki sposób, że będę mógł używać przepływu git indywidualnie w każdej części, czy będę musiał użyć go globalnie?

PS: To jest moje pierwsze pytanie na stackoverflow, proszę być miły :)

Answer 1

nie używam przepływ git, ale jestem zdania, że ​​odpowiedź zależy od tego w jaki sposób modułowy jesteś. Czy można wdrożyć strukturę rdzenia bez wdrażania aplikacji 1 i aplikacji 2? Czy możesz rozmieścić app1 i app2 niezależnie od siebie? Czy Twój zespół programistów jest wystarczająco duży i wystarczająco zaawansowany, aby traktować je jako niezależne przepływy pracy?

Jeśli odpowiedź na te pytania brzmi "tak", argumentowałbym, że traktuję je jako wiele projektów, z których każdy ma wyjątkowy przepływ. Jeśli odpowiedź na którekolwiek z nich brzmi "Nie", uniknęłabym złamania twojego projektu. W rzeczywistości, jeśli zmiany w aplikacjach app1 i app2 będą również wymagać zmian w głównym repozytorium przez większość czasu, uniknęłoby to w ogóle złamania twoich repozytoriów.

Zagnieżdżone repozytoria, niezależnie od tego, czy są wykonywane z poddrzewem, podmodułami, czy (zabraniają bóstwo), z samej tylko definicji .gitignore powodują, że przepływ pracy jest bardziej skomplikowany. Polecenia takie jak git bisect i git log stają się nieco mniej przydatne; Historia śledzenia i błędy stają się nieco trudniejsze. Nowi programiści muszą nauczyć się trochę więcej, aby rozpocząć kodowanie. Z własnego doświadczenia: ostrożnie obchodź się z tą ścieżką. Jeśli Twoje sub-repos są mocno splecione, wrócisz za rok, pisząc tę ​​odpowiedź dla kogoś, kto chce złamać swój projekt, na przykład kłopotliwą wersję Git Pay Forward.