Jak korzystać z github, gałęzi i automatycznych wydań do zarządzania wersjami? [Zamknięte]

Rozumiem już większość podstawowych koncepcji Git / Github, ale nadal mam problem ze zrozumieniem szerszego obrazu.

Oto niektóre rzeczy, które udało mi się dotychczas uruchomić:

• Push commits
• Praca z oddziałami
• Zintegruj Github z Travis CI, systemem ciągłej integracji
• Poprzez Travis CI, automatycznie buduj na każdym zatwierdzeniu do masterowania i umieść wydanie jako ZIP na Github w ramach wydań.

Jednak do tej pory pracowałem tylko nad wersjami alfa / beta projektów, więc nigdy nie widziałem wersji z wersjami w praktyce.

Dlatego chcę dowiedzieć się więcej o wersjonowaniu, utrzymywaniu osobnych wersji, poprawianiu wersji itp.

Jak mogę się upewnić, że następujące rzeczy się zdarzają:

• Posiadaj różne wersje mojego projektu, na przykład wersje 1.1.0 i 2.0.0
• Masz możliwość wypychania poprawek do wersji, niejako sprowadzania wersji do 1.1.1 lub 2.0.1 itp.
• Spraw, aby system ciągłej integracji budował tę wersję automatycznie po zatwierdzeniu, a jeśli się powiedzie, opublikuj wydanie dla tej konkretnej wersji.

Wątpię między następującymi opcjami:

• Czy muszę używać tagów do każdej wersji? Jeśli tak, to w jaki sposób system ciągłej integracji może budować wersje automatycznie?
• Czy powinienem tworzyć gałęzie dla każdej wersji? Jeśli tak, czy nie stworzyłoby to całej tony gałęzi (jak gałąź 1.1 i 2.0, poprawki trafiają oczywiście na tę gałąź)
• Jak określić numer wersji? Czy plik konfiguracyjny, który określa numer wersji, jest w porządku, czy można to zrobić lepiej? W tym przypadku byłby to projekt Java, jeśli to ma znaczenie.

Powinieneś spojrzeć na git-flow . To doskonały (i popularny) model rozgałęziania.

Podsumowanie Git Flow

Rozgałęzienie

Główne pnie, które pozostają na zawsze, to developi master. masterzawiera najnowszą wersję i developnajnowszą „stabilną” kopię rozwojową.

Współpracownicy tworzą featureoddziały (poprzedzone feature/konwencją) z develop :

$ git checkout -b feature/my-feature develop

i hotfixgałęzie (poprzedzone hotfix/konwencją) z master:

# hotfix the latest version of master
$ git checkout -b hotfix/hotfix-version-number master

# or hotfix from a specific version
$ git checkout -b hotfix/hotfix-version-number <starting-tag-name>

Gałęzie te są „jednorazowe”, co oznacza, że ​​mają krótką żywotność, zanim zostaną ponownie połączone z głównymi pniami. Mają one obejmować małe elementy funkcjonalności.

Wykończenie oddziałów

Kiedy współautor zakończy działanie z featureoddziałem, łączy go z powrotem w develop:

$ git checkout develop
$ git merge --no-ff feature/my-feature
$ git branch -d feature/my-feature

Kiedy skończysz z hotfixoddziału, oni połączyć go z powrotem do obu master, a developwięc poprawka przenosi:

$ git checkout master
$ git merge --no-ff hotfix/hotfix-version-number
$ git checkout develop
$ git merge --no-ff hotfix/hotfix-version-number
$ git branch -d hotfix/hotfix-version-number

Jest to aspekt ciągłej integracji.

Prasowe

Kiedy jesteś gotowy, aby rozpocząć pakowanie wersji, tworzysz releasegałąź ze swojej gałęzi „stabilnej” develop(tak samo jak tworzenie featuregałęzi). Następnie podbijasz numer wersji w znaczniku (opisanym poniżej).

Korzystanie z oddzielnych releasegałęzi pozwala kontynuować rozwijanie nowych funkcji developpodczas usuwania błędów i dodawania ostatnich poprawek do releasegałęzi.

Kiedy jesteś gotowy, aby zakończyć wydanie, scalasz releasegałąź w jedno masteri drugie develop(tak jak a hotfix), aby wszystkie zmiany były kontynuowane.

Tagowanie

Kiedy tworzysz releasegałąź lub hotfixgałąź, odpowiednio podbijasz numer wersji w znaczniku. W przypadku waniliowego git wygląda to tak:

$ git tag -a <tag-name> -m <tag-description>

Będziesz także musiał wypchnąć tagi (osobno) do zdalnego repozytorium:

$ git push --tags

Zazwyczaj najlepiej jest używać wersji semantycznej, w której twoje wersje mają formę major.minor.hotfix. Poważne wypukłości są niezgodne wstecz, natomiast drobne wypukłości i poprawki nie są niezgodne wstecz (chyba że jesteś w fazie beta 0.x.x).

Scalanie

Jak widać powyżej, git-flow zachęca do łączenia gałęzi za pomocą następującego polecenia:

$ git merge --no-ff <branch-name>

Ta --no-ffopcja pozwala zachować całą historię gałęzi bez pozostawiania wiązki gałęzi leżącej w bieżącym zatwierdzeniu repozytorium (więc nie martw się, nie będziesz miał gałęzi dla każdej wersji).

Zachęcamy również do ciągnięcia

$ git pull --rebase

Więc nie dodajesz wielu bezużytecznych zatwierdzeń scalania.

Możesz skonfigurować git, aby domyślnie robił obie te rzeczy w twoim .gitconfig. Pozwolę ci jednak spojrzeć na to;)

Przeglądanie wersji

Gdy ktoś szuka konkretnej wersji bazy kodu, może pobrać tag według nazwy:

# checkout in detached HEAD to browse
$ git checkout <tag-name>

# OR checkout and create a new local branch (as you might for a hotfix)
$ git checkout -b <new-branch-name> <tag-name>

Lub, jeśli ktoś przegląda na githubie, w rozwijanym menu „oddziałów” znajduje się także zakładka „tagi”.

Korzystanie z rozszerzenia git-flow (zalecane)

Moim ulubionym sposobem użycia tego modelu jest rozszerzenie git flow dla git.

( Edycja: Louis zalecił widelec AVH, który działa lepiej git describei może być teraz bardziej aktywny. Dzięki Louis.)

Rozszerzenie automatyzuje wszystkie niechlujne części (takie jak używanie merge --no-ffi usuwanie gałęzi po scaleniu), abyś mógł zacząć życie.

Na przykład za pomocą rozszerzenia możesz utworzyć gałąź funkcji w następujący sposób:

$ git flow feature start my-feature-name

i dokończ tak

$ git flow feature finish my-feature-name

Polecenia dotyczące poprawek i wydań są podobne, chociaż używają numeru wersji zamiast nazwy oddziału, na przykład:

# Create hotfix number 14 for this minor version.
$ git flow hotfix start 2.4.14

# Create the next release
$ git flow release start 2.5.0

Następnie Git flow tworzy dla Ciebie znacznik wersji i uprzejmie przypomina, aby podnieść wersję w dowolnym pliku konfiguracji lub pliku manifestu (co można zrobić za pomocą menedżera zadań, takiego jak chrząknięcie).

Mam nadzieję, że to pomoże :) Nie jestem pewien, jak dokładnie zintegrowałbyś to wszystko z konfiguracją Travis CI, ale zgaduję, że dostaną się tam githooki.

Czy muszę używać znacznika do każdej wersji?

Nie, wcale nie musisz używać tagów. Jeśli chcesz otagować każdą wersję, to dobrze, lub jeśli chcesz otagować za każdym razem, gdy budujesz system CI, możesz to zrobić. Znaczniki w zasadzie nadają jedynie zatwierdzoną nazwę zatwierdzeniu, dzięki czemu można łatwo wyciągnąć ją i wyświetlić później.

Czy powinienem tworzyć gałęzie dla każdej wersji?

Pewnie! Rozgałęzianie jest tanie / darmowe w Git, więc korzystam z niego przy każdej okazji. Możesz także dość szybko łączyć i usuwać gałęzie. Jeśli czujesz, że masz wiele oddziałów, zawsze możesz je później zredukować, dokonując selektywnego łączenia. Istnieje wiele schematów rozgałęzień Git, jeśli chcesz użyć wypróbowanego i prawdziwego schematu.

Jak określić numer wersji?

Tagi są zwykle sposobem, w jaki podajesz numer wersji, ponieważ dotyczy git. Jeśli mówisz o tym, jak wykonać wersję projektu lub jak to zrobić najlepiej, będziesz musiał kopać, ponieważ jest to pytanie oparte na dość opiniach. Niektóre projekty pozostają w wersji Beta na zawsze, inne zwiększają wersje liczbowe, jakby wychodziły z mody (Patrząc na ciebie, chrom)

Czy muszę używać tagów do każdej wersji?

Jeśli przez „wersję” rozumiesz zestaw plików, które składają się na wydanie lub kandydata do wydania, zdecydowanie zalecamy oznaczenie każdej wersji tagiem. Jeśli chcesz odwołać się do wersji 1.2.7, czy chcesz poszukać skrótu zatwierdzenia, czy po prostu użyć numeru wersji?

Także jeśli użyjesz git describedo zapisania gdzieś informacji o kompilacji (tak jak ja), to użycie tagów pozwala uzyskać znacznie ładniejszy wynik.

Jeśli tak, to w jaki sposób system ciągłej integracji może budować wersje automatycznie?

System ciągłej integracji może budować wersje bez względu na sposób używania tagów. Można powiedzieć, aby zbudował wydanie na podstawie skrótu zatwierdzenia. Tagi ułatwiają Ci życie.

Czy powinienem tworzyć gałęzie dla każdej wersji? Jeśli tak, czy nie stworzyłoby to całej tony gałęzi (jak gałąź 1.1 i 2.0, poprawki trafiają oczywiście na tę gałąź)

Nie uważam rozgałęziania za coś „na wersję”. Mam kilka projektów, w których wszystkie moje wersje są zatwierdzone w masteroddziale. Nie muszę nic bardziej skomplikowane niż to teraz , bo ani projekt jest na etapie stabilny i nie ma potrzeby, aby wspierać starsze wersje długoterminowo. Ale powiedzmy, że wypuszczam wersje 1.0, 1.1, 1.2, a następnie wypuszczam wersję 2.0 i nadal muszę obsługiwać serię 1.0 poprawkami bezpieczeństwa itp. W takim razie z pewnością miałbym oddział, w którym można by zainstalować wersje konserwacyjne serii 1.x .

Jak określić numer wersji? Czy plik konfiguracyjny, który określa numer wersji, jest w porządku, czy można to zrobić lepiej? W tym przypadku byłby to projekt Java, jeśli to ma znaczenie.

Posiadanie jednego źródła numeru wersji, takiego jak plik konfiguracyjny, jest najlepszym sposobem, ponieważ zapobiega błędom grubego palca, które mogłyby wystąpić, gdybyś musiał zaktualizować numery w wielu miejscach. Mówię z ... hmm ... żenującego doświadczenia. W wersji 1.3 okazuje się, że oprogramowanie nadal zgłasza, że ​​jest w wersji 1.2. Ups!

W innej odpowiedzi mxdubois polecił ci gitflow. Jeśli zdecydujesz się użyć gitflow, polecam korzystanie z edycji AVH . Oryginalna wersja nie jest już aktywnie utrzymywana. Istotną różnicą jest to, że edycja AVH wykonuje scalenia wersji, które pozwalają git describena inteligentną pracę. Oryginalna wersja wykonuje scalanie w sposób, który się uruchamiagit describe .

Skanuję listę Widzę wersję jako główny cel, więc ...

Jednym ze sposobów utrzymania wersji jest rozgałęzienie i scalenie (lub zmiana wersji).

Więc masz:

master

następnie tworzysz gałąź

v1

następnie dodajesz więcej zmian do

master(diff1)

następnie tworzysz gałąź

v3

następnie dodajesz więcej zmian do

master(diff2)

Teraz:

Aby zaktualizować wersję 2, teraz robisz

git checkout v2
git merge master  # for the changes you want to bring into version 2
# rebasing is also an option
# resolve any merge conflicts
# Done.

Aby zaktualizować wersję 3

git checkout v3
git merge master

Powyższe dotyczy aktualizacji hurtowych.

Prawdopodobnie bardziej prawdopodobne jest, że będziesz chciał wybrać konkretne zmiany

git cherry-pick

Więcej na temat zbierania wiśni na http://git-scm.com/docs/git-cherry-pick