Czy możliwe jest użycie modelu git-flow z Subversion?

Używamy Subversion i oprócz kilku osób, takich jak ja, nie ma zbyt wiele doświadczenia z rozgałęzianiem się i scalaniem w Subversion. Moje doświadczenie w Subversion jest ograniczone do prostych gałęzi Fabularnych, w których łączenie się i konflikty drzew, choć nie są rzadkością, nie są zbyt trudne do rozwiązania.

Biorąc to pod uwagę, pomagam zarządzać projektem, w którym nasza obecna metoda commit to trunk jest po prostu niezrównoważona dla naszych potrzeb. Wprowadziłem funkcję rozgałęziania i scalania do mojego zlokalizowanego zespołu i odnieśliśmy pewne sukcesy. Jednak proste rozgałęzianie funkcji nadal nie było w stanie odpowiedzieć na wszystkie nasze pytania, takie jak:

  1. jak rozwijamy kod równolegle dla tego wydania i kolejnych wydań?
  2. jaki kod jest uważany za stabilny?
  3. Jaki (w fazie rozwoju) kod pojawi się w następnym wydaniu?
  4. Jaki (w fazie rozwoju) kod pojawi się w kolejnym wydaniu?
  5. Jaka wersja kodu jest naszym testem, akceptacją lub produkcją środowiska?
  6. jak zintegrować współbieżne działania programistyczne ze znanym wydaniem stabilnym, aby ograniczyć wprowadzanie błędów i niekompletną pracę?
  7. Jak dostarczamy poprawki do opublikowanego kodu?
  8. skąd wiemy, z naszej kontroli źródła, jakie działania rozwojowe są obecnie w toku?
  9. Jak eksperymentować lub prowadzić badania i rozwój bez zakłócania obecnej bazy kodu podczas wykorzystywania?

Wygląda na to, że git-flow jak tu zdefiniowano pójdzie długą drogą do odpowiedz na wiele z tych pytań. Eksperymentowałem z tą metodą w Mercurial i wydaje się, że można ją również tam wdrożyć. Niestety migracja do DVCS nie wchodzi w grę.

Jednak moja krótka próba naśladowania tej metody w Subversion nie powiodła się z wieloma konfliktami merge i tree. Opcje łączenia i przypadki brzegowe są liczne i zaskakujące.

Czy Subversion może być użyty do implementacji git-flow a jeśli tak, to jaki jest poziom bólu?

Author: Montag451, 2012-11-12
Source

3 answers

Stosujemy tzw. metodę unstable trunk development. Taką metodologię rozwoju mieli na myśli twórcy Subversion, tworząc Subversion. Jest prosty i łatwy do wdrożenia.

  • cały swój rozwój wykonujesz na bagażniku . Tak zwany niestabilny tułów .
  • kiedy zbliżysz się do wydania, tworzysz dla niego gałąź. Chodzi o to, aby gałąź była na tyle późna, aby równoległy rozwój był tak krótki, jak możliwe, ale nie tak później, że niektórzy deweloperzy nie mogą wykonywać swojej pracy, ponieważ nie muszą już pracować nad bieżącym wydaniem, ale muszą zacząć pracować nad następnym wydaniem. W Agile zwykle robi się to tuż przed sprintem ujędrniającym . Zwykle robi się to po zakończeniu wersji, a teraz naprawiasz błędy.
  • uwolnienie odbywa się poza gałęzią. Odczep się od gałęzi. Jeśli są potrzebne łatki, są usuwane z branch.

Oto pomysł, jak to działa:

  • wyobraź sobie, że pracujesz nad wydaniem 1.2. Pracujesz nad bagażnikiem. Teraz zbliżasz się do czasu, kiedy Wersja 1.2 ma się ukazać, a nad wydaniem 1.2 nie ma wystarczająco dużo pracy, aby zająć programistów. Tworzysz gałąź 1.2 dla swojego wydania.
  • teraz ludzie wciąż pracujący nad wydaniem 1.2 przechodzą na gałąź Wydania 1.2. Tymczasem developerzy pracujący nad 1.3 zostają na bagażnik .
  • jesteś już gotowy do wydania 1.2. Oznaczasz Wydanie 1.2 bezpośrednio na gałęzi. Gałąź nie jest połączona z powrotem do pnia. Bagażnik jest do wydania 1.3.
  • błędy są zgłaszane i chcesz je naprawić w wersji 1.2.1. Kontynuujesz pracę z gałęzią 1.2. Dla wersji 1.2.1 nie jest potrzebna nowa gałąź. (Możesz zablokować gałęzie między wydaniami, aby zachować je w czystości .
  • Kiedy masz zamiar zrobić Wydanie 1.3, powtarzasz proces -- branch 1.3 i pracujesz dla 1.4 / align = "left" /

Nastąpi połączenie. Polega głównie na łączeniu wad zamocowanych na odgałęzieniu zwalniającym z powrotem do tułowia. Istnieją trzy możliwości zrobienia tego:

  • po wydaniu, łączysz wszystkie zmiany na gałęzi z powrotem do tułowia. Niewiele namierzamy. Zakładasz tylko, że wszystkie poprawki błędów na gałęzi dotyczą również pnia.
  • używasz systemu śledzenia, który rozumie problemy mogą żyć na więcej niż jednym wydaniu. W tym case, po prostu zaznaczasz błąd znaleziony na gałęzi do pnia. Możesz wybrać zmiany, które dotyczą bagażnika dzięki systemowi śledzenia problemów.
  • Niektóre strony po prostu się nie łączą. Śledzą również za pośrednictwem systemu śledzenia defektów zmiany, które muszą być zastosowane do pnia, które zostały zastosowane na gałęzi, i po prostu ponownie je wdrożyć. Mogą kopiować zmiany z gałęzi do pnia, ale nigdy nie dokonują formalnego połączenia. Jednak, gdy to zrobisz, nigdy nie będziesz mógł się połączyć (chyba że merge with the --record-only flag).

Oczywiście zdajesz sobie sprawę, że ta metoda wymaga czegoś, co nazywa się planowaniem . Musisz nadać priorytet swojej pracy, więc deweloperzy wykonują pracę nad nadchodzącym wydaniem przed pracami nad przyszłym wydaniem. Rozgałęziasz się tylko wtedy, gdy nie masz już wystarczająco dużo pracy nad nadchodzącym wydaniem, aby zająć wszystkich programistów.

Możesz zaimplementować standardowy workflow Git, który używa oddzielnych gałęzi programistycznych dla każdego dewelopera lub Wydanie, a następnie dostarczenie tych zmian do bagażnika. Wymagałoby to wielu gałęzi, po jednej dla każdego dewelopera/funkcji.

Najpierw łączysz się z pnia do gałęzi do rebase Twojego kodu. Gdy wykonasz rebase, łączysz się z gałęzi z powrotem do pnia za pomocą przełącznika --reintegrate. Pre-1.6, powinieneś usunąć gałąź i odtworzyć ją od --reintegrate trochę namieszanego śledzenia scalania. Zostało to jednak naprawione w wersji 1.6.x i wyżej.

 28
Author: David W.,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2012-11-12 19:29:57

To ważne pytanie. Mam tylko pomysły jak rozwiązać niektóre problemy:

  1. nie wydaje mi się, aby można było to łatwo rozwiązać bez częstego używania gałęzi. Nie jestem pewien, czy da się to łatwo rozwiązać używając Gita. Gałęzie funkcji mają długą drogę w rozwiązywaniu tego problemu, ale ogólnie powinieneś raczej spróbować skoncentrować się na funkcjach tylko w następnym wydaniu.
  2. trunk - uważam to za gałąź master.
  3. powiedziałbym, że development gałąź jest kodem do następnego release
    4. Wydaje się trudne bez użycia wielu gałęzi, nie ma pojęcia, jak to właściwie rozwiązać.
  4. Możesz użyć gałęzi lub zwrócić uwagę na numer wersji w teście i ACC. PROD powinien być umieszczony w metce chyba.
  5. powiedziałbym, że za pomocą zautomatyzowanych testów regresyjnych i ciągłej integracji. Również korzystanie z peer reviews może tutaj pomóc, w najlepszym razie używasz jakiegoś narzędzia do oznaczania pliku jako recenzowanego. W ten sposób możesz upewnić się, że łączysz tylko pliki, które zostały przejrzane. Może również warto powiązać komunikaty o zatwierdzeniach z bugtrackerem, aby automatycznie dowiedzieć się, które pliki zostały dotknięte w związku z którymi problemami, a następnie upewnić się, że wszystkie problemy są rzeczywiście zamknięte dla plików, które chcesz scalić. Jest to nietrywialne zadanie, zwłaszcza jeśli myślisz o łączeniu tylko części gałęzi. W ten sposób, jakby, robi funkcję scalania.
  6. użyj znacznika dla wydania. Możesz to sprawdzić tak jak gałąź i w razie potrzeby dodać łatki
  7. Wymień wszystkie svn commity dla całego repozytorium na jednej stronie (np. Trac/redmine/jira overview)
  8. użyj lokalnej kopii, obawiam się / lub ponownie oddziału. Albo niech R & D użyje Git svn lokalnie do badań.

Niektóre z tych problemów można, przynajmniej częściowo, rozwiązać za pomocą git svn. Używając go możesz na przykład eksperymentować lokalnie używając funkcji gits branch, bez przechowywania ich w globalnym repozytorium. Oczywiście nie jest to interesujące, jeśli odkrywasz nową funkcję z wieloma członkami w zespole, chyba że wszyscy są zadowoleni z używania Gita i ciągnięcia się od siebie przez sieć. Używając git svn Możesz również użyć git cherrypick, aby ręcznie wybrać pojedyncze commity, aby zastosować je z jednej gałęzi do drugiej(np. rozwój na released-x. X-tag).

To wszystko, co na razie wymyśliłem, mam nadzieję, że to pomoże.
 2
Author: Nihathrael,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2012-11-12 15:09:15

W moich działaniach używam SVN z następującym podejściem.

  1. Pień jest gałęzią "master". Nigdy nie powinieneś popełniać niczego bezpośrednio w bagażniku. Bagażnik zawsze musi pasować do najnowszej wydanej wersji w produkcji. Tak więc pień zawsze reprezentuje stabilną gałąź. Pień jest aktualizowany tylko z reintegracją gałęzi.

  2. Potrzebujesz gałęzi do swojej pracy. Każda nowa gałąź musi być utworzona z pnia, więc każda nowa gałąź pasuje dokładnie do wersja produkcyjna w czasie tworzenia. Zmiany i poprawki są wprowadzane w gałęziach.

  3. Powinieneś mieć co najmniej 2 główne gałęzie:

    • develop: przeznaczony do przyszłych prac, które nie są jeszcze planowane do wydania.
    • poprawka: używana do zatwierdzania wszystkich poprawek i tylko poprawek. W przypadku częstego użytkowania należy go zaktualizować za pomocą wersji trunk, gdy bagażnik jest aktualizowany.

  4. Tworzenie gałęzi dla każdego głównego strumienia pracy: projektu, podprojektu, Prośba o zmianę. Możesz pracować z równoległym rozwojem.

  5. Utwórz gałęzie "integracji", aby dołączyć do gałęzi, które musisz zwolnić. Musisz scalić do gałęzi integration każdą gałąź zgłoszoną do wydania. Tak więc Branch integration może na przykład dołączyć zarówno poprawkę, jak i projekt.

  6. Twórz artefakty z gałęzi integracyjnych lub z gałęzi siebie.

  7. Po wydaniu gałęzi Utwórz znacznik dla tego wydania, aby móc masz kopię wydanej wersji i nadal możesz pracować z tą gałęzią. W tagach powinieneś mieć tylko wydaną wersję. Nie zatwierdzaj zmian w tagu!

  8. Po wydaniu gałęzi musisz zaktualizować bagażnik. / Align = "left" / Możesz reintegrować gałąź integracji lub gałąź bezpośrednio(jeśli nie przeszedłeś z integracji).

  9. Gdy bagażnik zostanie ponownie dopasowany do wersji produkcyjnej, zgłoś go we wszystkich aktywnych gałęzie.

Ta metoda nie jest tak naprawdę repliką koncepcji git-flow, ale spełnia niektóre z jej wymagań.

Dzięki takiemu podejściu możesz mieć następujące zalety:

  • Bagażnik stabilny. Zawsze wiesz, co w tym momencie reprezentuje kufer.

  • Każda gałąź zawiera tylko własne zmiany.

  • Dzięki gałęziom integracji możesz zarządzać gałęziami równoległymi w jednym wydaniu

  • Z tagami ty Zawsze miej kopię wydanej wersji

Wady to:

  • Wiele oddziałów do zarządzania.

  • Musisz często łączyć i przełączać się, szczególnie w celu zgłaszania zmian w gałęziach integracji

  • Wiele konfliktów do rozwiązania za każdym razem

Przy okazji, jest to najlepsze podejście, z jakim kiedykolwiek pracowałem, ponieważ pozwala zachować kontrolę nad wersjami.

 0
Author: Alessandro C,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2018-05-26 00:13:13