Próbujemy przyjąć udany model rozgałęziania Git zaimplementowany przez git-flow. Teraz pracujemy nad co najmniej dwoma gałęziami wydania, jedną dla najnowszej stabilnej wersji, a drugą dla następnej („podglądowej”) wersji. Nie rozumiem, dlaczego wszystkie wydania wydają się „linearyzowane” do mastera i tam oznaczone. Dlaczego nie oznaczyć wydań w ich gałęziach wydań? Dlaczego w ogóle mistrz ? Albo po co rozwijać gałąź i nie używać do niej mastera ?
Odpowiedzi:
W modelu git-flow Twoja „najnowsza wydana” wersja faktycznie jest odwzorowywana na gałąź master, podczas gdy „wersja zapoznawcza” jest mapowana na releasegałąź git-flow . Jest rozwidlany developi ostatecznie łączony masterz momentem rzeczywistego wydania. Wtedy to stanie się Twoją „najnowszą wersją” i zazwyczaj będziesz naprawiać tylko błędy w tym wydaniu, używając hotfixgałęzi git-flow . W ten sposób Twój masterzawsze reprezentuje najbardziej stabilny stan Twojej najnowszej wydanej wersji.
Jeśli chcesz naprawić błędy dla starszych wydań lub zrobić tam coś innego, rozwidlisz supportgałąź z odpowiedniego zatwierdzenia w master(będziesz mieć wszystkie wersje, jakie kiedykolwiek zostały tam utworzone). supportgałęzie są nadal eksperymentalne ( zgodnie z dokumentacją ) i nie są dobrze udokumentowane. Ale jak widać z pomocy wiersza poleceń:
usage: git flow support [list] [-v]
git flow support start [-F] <version> <base>
te gałęzie dopiero się rozpoczęły i nie mają być łączone z powrotem do masternor develop. Zwykle jest to w porządku, ponieważ poprawki do „starożytnych” wydań lub funkcji, o które prosili klienci, aby zostały zaimplementowane w „starożytnych” wersjach, nie mogą lub nie powinny wracać master. Jeśli nadal myślisz, że chcesz przenieść poprawkę do swojej głównej linii rozwojowej (reprezentowanej przez masteri develop), po prostu rozpocznij hotfix, wybierz najlepsze zmiany i zakończ hotfix.
git flow supportnie jest oznaczona jako eksperymentalna.
Wygląda na to, że przeważnie model mentalny z nieco zbyt dużym naciskiem na gałęzie. Zgadzam się, możesz po prostu oznaczyć zatwierdzone przez siebie commity zamiast scalać je z powrotem w master.
Ale obraz jest ładny. Scalenie wszystkiego z powrotem w master daje wyraźne wskazanie wydań w porządku czasowym zamiast umieszczania tagów wersji rozrzuconych po całym wykresie.
Myślę, że ten model nie działa jednak przy naprawianiu błędów w starszych wersjach. To psuje porządek.
Odpowiadając na twoje pytanie: myślę, że jest to zestaw reguł, które w niektórych przypadkach tworzą prosty model myślowy. Nie wszystkie zasady mają sens z czysto technicznego punktu widzenia, ale to nie czyni ich złymi. Modele mentalne są dobre dla ludzi.
supportgałęzie są przeznaczone do naprawiania błędów w starszych wydaniach, choć nadal są oznaczone jako „eksperymentalne”.
Osobiście uważam, że wspomniany przepływ git jest zbyt skomplikowany.
Jeśli korzystasz z GitHub, wypróbuj GitHub flow(zgodnie z opisem Scotta Chacona).
Jest to szczególnie przydatne do współpracy nad wieloma funkcjami, przeglądu kodu i można go połączyć z rozwiązaniem Continuous Integration przy użyciu Commit Status API.
AKTUALIZACJA : Istnieje nowa oficjalna witryna internetowa The GitHub Flow ™
AKTUALIZACJA 2 : Jest nowy oficjalny (i uproszczony) przewodnik GitHub dla GitHub Flow ™: https://guides.github.com/introduction/flow/
masteranomalią chronologii dzieła.
supportsłużą gałęzie. Ale masz rację, to rzeczywiście anomalia, że takie wydania nie są z powrotem scalane master, co - w moim rozumieniu - powinno obejmować wszystkie wydania produkcyjne.
W moim przypadku mam dwie wersje tego samego oprogramowania, w których podstawy są takie same, ale każda wersja ma inne funkcje.
Więc tworzę dwie, worktreeco oznacza, tworzę dwie odpowiednie, długo działające gałęzie obok wzorca.
$git worktree add -b version-silver ..\version-silver master
$git worktree add -b version-gold ..\version-gold master
Wtedy ja mam:
$git branch
master # base stuff here
version-silver # some normal features
version-gold # some better features
Jest jedno repozytorium, ale mam 3 oddzielne foldery obok siebie dla każdej gałęzi powyżej. I wprowadź wspólne zmiany w master. następnie połącz go z obiema innymi wersjami.
cd master
vim basic.cpp
git add .
git commit -m "my common edit on basic.cpp"
cd ..\version-silver
vim silver.cpp
git add .
git commit -m "my specific edit on silver.cpp"
git merge master # here i get the basic.cpp latest changes for silver project
cd ..\version-gold
git merge master # here i get the basic.cpp latest changes for gold project
Konkretne zmiany każdej wersji zostaną również umieszczone w odpowiednim folderze, a prace nad każdym projektem są izolowane i nie można pomylić IDE.
Mam nadzieję, że to pomoże.
Całkowicie zgadzam się z @Mot.
Miło słyszeć te same pytania.
Nasz zespół był również poszukiwany na bardziej uniwersalny model rozgałęziania niż Successfull . To znaczy, jak wspomniano powyżej @Mot - głównym pomysłem jest uniknięcie wprowadzania dodatkowych repozytoriów do obsługi gałęzi release- * w oddzielnym repozytorium * .git, jak na przykład robi to kernel.org dla stabilnych wydań. Ale kernel.org robi to w celu zminimalizowania pobieranych rozmiarów, jak sądzę.
Wydaje mi się, że łatwiej jest mieć mistrza jako główną linię rozwoju .
Istnieją również pewne konflikty w łączeniu modelu wydania * do mastera i oznaczaniu go później pomysłem
użyj skryptu przechwytującego Git, aby automatycznie budować i wdrażać nasze oprogramowanie na nasze serwery produkcyjne za każdym razem, gdy nastąpiło zatwierdzenie na serwerze głównym
ponieważ zakończenie (scalanie i tagowanie) nie jest transakcją atomową:
$ git checkout master
Switched to branch 'master'
$ git merge --no-ff release-1.2
Merge made by recursive.
(Summary of changes)
$ git tag -a 1.2
a jeśli git hook rozpocznie kompilację z automatyczną obsługą wersji:
$git describe --tags --long >.ver
wtedy można zbudować błędną wersję dla:
$ git merge --no-ff release-1.2
Wiem, że wersjonowanie w wersji Successfull wprowadza jakiś proces wersji bump, ale nie jest to automatyczne.
Podsumowując - kluczowe różnice, które wprowadzamy do modelu gałęzi dla wydań - * scalanie i tagowanie to: - oznaczanie wydania podczas tworzenia gałęzi - zachowanie gałęzi wydania, aby umożliwić jej utrzymanie w przyszłości
Gałąź główna powinna ZAWSZE reprezentować bazę kodu produkcyjnego, dlatego zawsze scalasz kod z powrotem do mastera zaraz po wydaniu produkcyjnym.
Tagowanie służy do „zapamiętywania” dokładnego kodu, który trafił do wydania produkcyjnego, dzięki czemu można wrócić później i przeanalizować kod, jeśli coś poszło nie tak.
Z tego teoretycznie nie powinno mieć znaczenia, czy otagujesz swój kod w gałęzi wydania, czy w gałęzi głównej po ponownym scaleniu z głównym. Osobiście wolę otagować kod w gałęzi wydania, ponieważ jest to dokładnie kod, który trafił do kompilacji / wydania (zakładając, że coś może pójść nie tak podczas scalania).
Problem z koncepcją gałęzi rozwoju polega na tym, że jest ona jednowątkowa. Brendan w tym wątku wspomniał o strategii, którą można by zastosować, obejmując koncepcję branży rozwojowej.