Pracujemy w naszym zespole w następujący sposób:

mamy tylkomaster gałąź w naszym repozytorium GitHub, nie jest stabilna - myśli, że każdego dnia zostaje tam popchnięta; dla stabilnych wersji używamy tagów (do rozwoju używamy prywatnych wideł na GitHub)wydajemy nową wersję mniejszą co 3 tygodnie, która zawiera poprawki błędów i nowe funkcje (powiedzmy 1.2.4, 1.2.5, 1.2.6 ...)musimy też utrzymywać każdą starszą wersję przez ograniczony czas (kilka miesięcy), więc gdy ktoś używa 1.2.4, podczas gdy najnowsza wersja to 1.2.7, a oni znajdą błąd, mogą poprosić nas o naprawienie błędu na gałęzi, z której korzystają. Następnie wydajemy awersja łaty, 1.2.4A.łaty są raczej wyjątkowe. Zwykle robimy nie więcej niż 1-2 łaty dla mniejszej wersji. Dla większości wydań nie robimy poprawek.

Pytanie brzmi: jaka jest najlepsza strategia, aby naprawić błąd w master i starej gałęzi w tym samym czasie?

Mogę pomyśleć o dwóch głównych strategiach:

Napraw błądmaster, a następnie kasyv1.2.4, następniecherry-pick odpowiednie zatwierdzenie (załóżmy, że poprawka jest jednym zatwierdzeniem, które zawsze zatrzymuje) i oznacz znacznik zatwierdzenia jakov1.2.4A.

Sprawdzićv1.2.4, napraw błąd i zatwierdzaj, oznaczaj zatwierdzenie jakov1.2.4Ai włączyć go domaster, zróbłączyć.

Jestem raczej za pierwszą wersją (wybiórcze), ale chciałbym usłyszeć komentarze drugiej osoby na temat zalet i wad.

Oczywiście sprawy mogą się komplikować, gdy zatwierdzenia w środku wprowadzą kilka poważnych zmian, które mogą spowodować, że nie można utworzyć zatwierdzenia, które będzie działać zarówno w wersji 1.2.4, jak i master (na przykład, gdy zmieniła się nazwa funkcji lub rzeczy bardziej skomplikowane). Ale częstszą sytuacją jest to, że poprawkę można przenieść bez problemów.

Zalety wybierania wiśni przez mistrza:

Myślę, że historia jest bardziej „jadalna” dzięki czereśniom. Rozważ to:

| <- bugfix done on master
|
|
| <- v1.2.7
...
|
|
|
|
|
|
|
|
|
|  - <- v.1.2.4A (cherry-picked from master)
| / 
| <- v1.2.4

vs to:

| <- bugfix merged to master
|\ 
| \
|  |
|  |   <- v1.2.7
...
|  |
|  |
|  |
|  |
|  |
|  |
|  |
|  |
|  |
|  - <- v.1.2.4A (direct bugfix)
| / 
| <- v1.2.4

Pomyśl o tym, że masz między sobą dziesiątki zobowiązań. Rozważ, aby równolegle zastosowano wiele poprawek. Połowa ekranu będzie zanieczyszczona.

Powiedzmy, że naprawiłem problemv1.2.4, ale za kilka dni ktoś prosi mnie o łatkęv1.2.3. Cherry-pick to najrozsądniejszy sposób na to.

Czy są jakieś zalety połączenia w naszym przypadku, które przeoczyłem? Rozumiem, że lepiej zachowuje połączenie między dwoma zatwierdzeniami niż wybieranie czereśni, ale przechowujemy dokumentację wydań i wszystko to jest tam również śledzone.