2013-01-07 13 views
5

W naszej firmie przeprowadzamy się z SvN do Git (tak, lepiej późno niż wcale). Dzięki temu staramy się również usprawnić proces wersjonowania. Aby to zrobić, znalazłem interesujący artykuł: Udany model rozgałęzień Git autorstwa Vincenta Driessena.Obsługa wielu wersji z pomyślnym odgałęzieniem Git Model

O ile mogę przeczytać z artykułu, programista zakłada wydania liniowe. Dla jasności:

v1.0.0 --> v1.0.1 --> v1.0.2 --> v1.1.0 --> v1.1.1 etc 

Obsługa starszych wersji nie jest wymieniona. Na przykład: obsługujemy do trzech głównych wersji z powrotem, ponieważ niektórzy klienci nie chcą aktualizacji. Więc sobie wyobrazić mamy następujących wersjach:

v7.0.0 --> v8.0.0 --> v9.0.0 --> v10.0.0 

Kiedy jest krytyczny bug znaleźć w v8.0.0po uwolnienie v9.0.0, mamy kasy tag v8.0.0, naprawić błąd, i połączyć go z powrotem do develop i master oddziałów. Połącz z master pobiera tag v8.0.1.

Wydaje mi się jakoś dziwnie, bo od dwóch rzeczy:

  1. master timeline będzie wyglądać v7.0.0 --> v8.0.0 --> v9.0.0 --> v8.0.1 --> v10.0.0. W pełni zdaję sobie sprawę, że jest to możliwe, ale czy jest również dopuszczalne?
  2. Kiedy łączyć z hotfix do mastermaster (i jest w tej chwili w v9.0.0) oraz oznaczyć je v8.0.1, mogę również uzyskać funkcje wprowadzone między v8.0.0 i v9.0.0?

Z góry dziękuję!

Odpowiedz

4

Dla mnie tag v8.0.1 powinien być zatwierdzeniem przed scaleniem master. Jeśli chcesz załączyć nowe wersje, scalisz tam również inne znaczniki.

v8.0.0 --> v9.0.0 --> v10.0.0 
    \   \   \ 
    v8.0.1 --> v9.0.1 --> v10.0.1/master 
+0

Dzięki! Prawdopodobnie źle zrozumiałem pojęcia oznaczania w Git na pierwszym miejscu :) Nie zdawałem sobie sprawy, że mogę oznaczyć samą poprawkę, w przeciwieństwie do łączenia się w develop/master, a następnie tagowania. Dzięki! – Ivan

Powiązane problemy