Zasoby, scalanie gałęzi Git i wydań
Każdy ma skonfigurowany inny przepływ pracy git, ale na potrzeby tego posta załóżmy, że masz coś takiego:
- Oddział, w którym znajdują się wszystkie Twoje aktywa, niezabudowane.
- System ciągłej integracji, który buduje zasoby i tworzy nowy oddział lub może nową wersję.
- Oddział utworzony przez system ciągłej integracji, który zawiera zbudowane zasoby.
Głównym elementem tego przepływu pracy jest system ciągłej integracji. Oznacza to, że jeśli się nie powiedzie, to praca odpowiedzialna za budowanie aktywów i tworzenie nowego oddziału przestaje działać.
A kiedy tak się stanie, musimy to zrobić ręcznie. Jasne, to żmudne, ale nie trudne. Jeśli znajdziesz się w takiej sytuacji, oto jak możesz zabrać się za budowanie zasobów, łączenie gałęzi git i tworzenie wersji wersjonowanej.
Scalanie gałęzi Git
W tym poście załóżmy, że masz skonfigurowane narzędzie do kompilacji odpowiedzialne za kompilowanie zasobów. Może to być jedno z dostępnych narzędzi, ale zamierzam użyć różnych npm, aby zademonstrować ten punkt.
1 Skonfiguruj gałąź źródłową
Gałąź źródłowa obejmuje wszystkie aktywa niezabudowane. Zasadniczo są to wszystkie surowe źródła JavaScript, arkusze stylów i wszelkie inne komponenty związane z interfejsem, które nie zostały zbudowane.
Gdy kod jest gotowy, można go zbudować i przekazać do dowolnej gałęzi, nad którą pracujesz. Na potrzeby tego artykułu będziemy go nazywać develop.
Po wypchnięciu tych zmian, musimy zmienić branche na builtbranch.
2 Połącz gałąź źródłową z gałęzią zbudowaną
Gdy już jesteśmy na gałęzi builda, możemy zbudować wszystkie zasoby (ponownie, używając dowolnego narzędzia, które będzie dla Ciebie najlepsze). Ale zanim to zrobimy, musimy się upewnić, że przenosimy pracę do builtoddziału z developoddziału.
Innymi słowy, musimy się połączyć, developnawet develop-builtjeśli kod w develop-builtnim może być – lub prawdopodobnie będzie – nieaktualny po scaleniu.
Następnie faktycznie wykonujemy niezbędne polecenia, aby zbudować zasoby, dodać je i zatwierdzić do gałęzi, a następnie wrzucamy nową pracę:
To daje nam teraz jedną gałąź developze wszystkimi źródłami surowymi i jedną gałąź, develop-builtktórej możemy użyć do otagowania naszych wydań.
3 Oznacz zbudowaną gałąź
W tym momencie możesz po prostu oznaczyć develop-builtjako wydanie wersjonowane, możesz chcieć scalić je z masterlub w innym przypadku. Jeśli jednak chcesz zachować dwa oddzielne tagi, jeden dla tagu źródłowego, a drugi dla tagu rzeczywistej wersji, możesz to zrobić przez otagowanie developi develop-builtprzed wykonaniem dodatkowego scalania.
W szczególności możesz oznaczyć developjako wersjonowane źródło:
A develop-builtjako oznaczone wydanie:
W tym momencie możesz scalić to z mastergałęzią lub inną główną gałęzią, którą zdecydujesz się utrzymywać. Jeśli jednak używasz Composera, prawdopodobnie będziesz chciał odwoływać się do wersji wersjonowanych, więc tutaj możesz użyć karty.
Ostatnia uwaga
Pamiętaj, że Twój przepływ pracy może – i prawdopodobnie tak się dzieje – się różnić. Może używasz gałęzi, może używasz tagów, może używasz kombinacji tych dwóch jak powyżej.
Nie chodzi o to, aby powiedzieć, jak powinieneś to zrobić, ale ostatecznie o to, jak połączyć gałęzie git, aby twoja gałąź źródłowa mogła trafić do gałęzi zbudowanej, dzięki czemu możesz zbudować zasoby i wersjonować je w razie potrzeby.