Elastyczne i statyczne rozgałęzianie (Git vs Clearcase/Accurev)

Wygląda na to, że to, czego szukasz, może być git rebase. Zmiana rozmiaru gałęzi koncepcyjnie odłącza ją od pierwotnego punktu gałęzi i ponownie dołącza w innym punkcie. (W rzeczywistości rebase jest zaimplementowany poprzez nałożenie każdej łaty gałęzi w kolejności do nowego punktu gałęzi, tworząc nowy zestaw łat.) W twoim przykładzie, możesz zmienić nazwę gałęzi na bieżącą końcówkę górnej gałęzi, która zasadniczo "odziedziczy" wszystkie zmiany wprowadzone do drugiej gałęzi.

Nie do końca rozumiem, o co prosisz, ale brzmi to jak git ' s śledzenie semantyki jest tym, czego chcesz. Kiedy oddzielisz się od am origin możesz zrobić coś takiego:

Git - T-b my_branch origin / master

I wtedy przyszłe "git pull" s automatycznie Scali origin / master do twojego oddział roboczy. Możesz użyć "Git cherry-V origin / master", aby zobaczyć co za różnica. Możesz użyć "Git rebase" przed opublikowaniem swojego zmiany w celu oczyszczenia historii, ale nie należy używać rebase once Twoja historia jest publiczna(tzn. inne osoby podążają za tą gałęzią).

Jeśli chodzi o schemat dziedziczenia używany przez accurev: użytkownicy GIT prawdopodobnie "dostaną" całość, gdy spojrzysz na git-flow (Zobacz także: http://github.com/nvie/gitflow i http://jeffkreeftmeijer.com/2010/why-arent-you-using-git-flow/)

Więc wydaje się GIT może rób to, co robi accurev. Ponieważ nigdy nie korzystałem z git/git-flow na co dzień, nie mogę powiedzieć, jak to działa, ale wygląda obiecująco. (Minus odpowiednia obsługa GUI: -)

Postaram się odpowiedzieć na pytanie. (Muszę tu powiedzieć, że nie używałem GIT tylko przeczytać o tym, więc jeśli coś, o czym wspomniałem poniżej jest źle, proszę mnie poprawić)

"Czy możesz wyliczyć scenariusze, w których to dziedziczenie jest koniecznością?"

Nie powiem, że jest to konieczne, ponieważ możesz rozwiązać problem z narzędziem, które posiadasz, i może być poprawnym rozwiązaniem dla Twojego środowiska. Myślę, że to bardziej kwestia procesów niż samego narzędzia. Upewnienie się, że proces jest spójny, a także pozwala cofnąć się w czasie, aby odtworzyć każdy pośredni krok / stan jest celem, a plusem jest to, że narzędzie pozwala uruchomić proces i SCMP tak bezbolesnie, jak to możliwe

Jedyny scenariusz, jaki widzę, jest przydatny, aby mieć to 'dziedziczenie' zachowanie i używać mocy specyfikacji konfiguracyjnej, jest wtedy, gdy chcesz, aby twój zestaw zmian "izolowany " zmapowany do zadania (devtask, CR, SR, lub cokolwiek definiuje cel/zakres Twojego zestawu zmian)

Za pomocą ta kompozycja pozwala na to, aby Twoja gałąź programistyczna była czysta i nadal używała innej kombinacji (używając kompozycji) reszty kodu, i nadal tylko to, co jest istotne dla zadania izolowane w gałęzi podczas całego cyklu życia zadania, aż do fazy integracji.

Będąc purystą, musisz commit/merge/rebase tylko po to, aby mieć "zdefiniowany punkt początkowy", myślę, że 'zanieczyszczą ' Twoją gałąź i skończysz z Twoim zmiany + inne zmiany w Twojej gałęzi / zestawie zmian.

Kiedy / gdzie ta izolacja jest przydatna? Poniższe punkty mogą mieć sens tylko w kontekście firm realizujących CMM i niektórych certyfikatów ISO, i mogą nie być interesujące dla innych rodzajów firm lub OSS

• Będąc naprawdę wybrednym, możesz chcieć dokładnie policzyć wiersze kodu (dodane/zmodyfikowane/usunięte) zestawu zmian odpowiadającego pojedynczemu programiście, później używanemu jako jedno wejście dla kodu i wysiłku szacunki.

• Kod może być łatwiejszy do przejrzenia na różnych etapach, mając tylko kod w jednej gałęzi (nie przyklejony z innymi zmianami)

W dużych projektach z kilkoma zespołami i + 500 deweloperów aktywnie pracujących jednocześnie na tym samym kodzie bazowym, (gdzie graficzne pojedyncze drzewa wersji elementów wygląda jak bałagan splątane sieci z kilku linii obciążenia, jeden dla każdego dużego klienta, lub po jednym dla każdej technologii) kilka stopni głębokości sprawiło, że ta ilość ludzi pracuje płynnie, aby dostosować ten sam produkt / system (kod podstawowy) do różnych celów. Korzystając z tej specyfikacji konfiguracyjnej, dynamicznie dało każdemu zespołowi lub zespołowi podrzędnemu inny widok na to, czego potrzebują i skąd muszą się rozgałęziać (kaskadowo w kilku przypadkach) bez potrzeby tworzenia pośrednich gałęzi integracyjnych lub ciągłego łączenia i rebasowania wszystkich bitów, od których musisz zacząć. Kod z tego samego zadania/celu był rozgałęzieniem różne etykiety, ale miały sens. (Można tu argumentować "znaną linię bazową" jako zasadę SCM, ale proste etykiety rozważane w pisemnym planie SCM wykonały pracę) Musi być możliwe rozwiązanie tego za pomocą Gita (chyba w sposób nie dynamiczny), ale naprawdę trudno mi sobie wyobrazić bez tego zachowania 'dziedziczenia'. Myślę, że punkt wspomniany przez VonC "jeśli rozgałęziony, wszystkie jego pliki będą rozgałęziać się z tego samego unikalnego punktu początkowego" został tutaj złamany, ale poza tym był dobrze udokumentowany na SCMP, I pamiętaj, że były mocne powody biznesowe, aby to zrobić w ten sposób.

Tak budowanie tych specyfikacji config, o których wspomniałem powyżej, nie było darmowe, na początku tam, gdzie 4-5 dobrze płatnych ludzi za SCM, ale zostały później zredukowane przez zautomatyzowane skrypty, które zapytały Cię, co chcesz na warunkach etykiet / gałęzi / funkcji i napisze CS dla Ciebie.

Odtwarzalność tutaj została osiągnięta poprzez zapisanie specyfikacji Config wraz z zadaniem w systemie devTask, więc każde zadanie przed mapowane do wymagań, a następnie mapowane do specyfikacji config, zestawu zmian (pliki kodu, dokumenty projektowe, dokumenty testowe itp.)

Więc do tego tutaj jeden wniosek może być, tylko jeśli twój projekt jest wystarczająco duży/skomplikowany (i możesz sobie pozwolić na SC Managerów przez całe życie projektu:)) wtedy dopiero zaczniesz myśleć, czy potrzebujesz zachowania "dziedziczenia" lub naprawdę wszechstronnego narzędzia, w przeciwnym razie przejdziesz bezpośrednio do narzędzia, które jest darmowe i już dbasz o spójność of you SCM ... ale mogą być inne czynniki na narzędziu SCM, które mogą sprawić, że będziesz trzymać się jednego lub drugiego ...Czytaj dalej..

Niektóre uwagi poboczne, które mogą być Poza tematem, ale myślę, że w niektórych przypadkach, takich jak mój, należy wziąć pod uwagę.

Muszę tu dodać, że używamy "good-ol CC", a nie UCM. Całkowicie zgadzam się z VonC w sprawie dobra metodologia pozwala "kierować" elastyczność w kierunku bardziej spójnej konfiguracji. Dobrą rzeczą jest to, że CC jest dość elastyczny i można znajdź (nie bez wysiłku) dobry sposób, aby mieć coś spójnego, podczas gdy w innych SCM możesz mieć to za darmo. Ale na przykład tutaj (i w innych miejscach, w których pracowałem z CC) dla projektów C/C++ nie możemy sobie pozwolić na cenę braku funkcji winkin (ponownego użycia obiektów Derive), które skracają kilka X razy czas kompilacji. Można argumentować, że posiadanie lepszego projektu, bardziej odsprzęgniętego kodu i optymalizacja plików Makefile może zmniejszyć potrzebę kompilacji całości, ale są przypadki, które trzeba skompilować całą bestię wiele razy dziennie,a dzielenie się DO oszczędza mnóstwo czasu / pieniędzy. Gdzie teraz jestem staramy się używać jak najwięcej darmowych narzędzi, jak to tylko możliwe, i myślę, że pozbędziemy się CC, jeśli znajdziemy tańsze lub darmowe narzędzie, które implementuje funkcję winkin .

Skończę z czymś, o czym wspomina Paweł, różne narzędzia są lepsze niż inne do różnych celów ale dodam, że można uciec od pewnych ograniczeń narzędzia, mając spójny proces i bez bliznowacenia powtarzalności, kluczowe punkty poza SCM W końcu chyba odpowiedź na jest warta? zależy od Twojego "problemu", używanego SDLC, procesów SCM i czy jest jakaś dodatkowa funkcja (jak winkin), która może być przydatna w Twoim środowisku.

Moje 2 centy

Pomijając teorię, oto rodzaj oczywistego praktycznego podejścia do tego, z mojego punktu widzenia przy użyciu AccuRev w komercyjnym środowisku produkcyjnym przez wiele lat: model dziedziczenia działa bardzo dobrze, dopóki strumienie dzieci nie odbiegają zbytnio od przodków, które są nadal w rozwoju. Rozkłada się, gdy dziedziczące strumienie są zbyt różne.

Dziedziczenie (późniejsze wersje jako Dzieci wcześniejszych) pozwala na aktywację zmian w strumieniach przodków w strumieniach potomnych nikt nie robi nic (chyba że połączenie jest wymagane, w którym to przypadku pokazuje się jako głębokie nakładanie, co jest dobre, aby móc zobaczyć).

To brzmi świetnie, a w praktyce tak jest, gdy wszystkie strumienie są stosunkowo podobne. Używamy tego modelu dla strumieni z poprawkami i service pack poniżej danej wersji produkcyjnej. (Jest to dla nas trochę bardziej skomplikowane, ale taka jest ogólna idea.)

Wydania produkcyjne są równolegle, bez dziedziczenia, z tymi hotfix i service pack poniżej każdego z nich. Uruchomienie nowej wersji oznacza utworzenie nowego strumienia na poziomie wydania i ręczne przepchnięcie do niego wszystkiego z najnowszego strumienia konserwacji dla poprzedniego wydania. Następnie zmiany we wcześniejszych wydaniach, które odnoszą się do późniejszych, muszą być ręcznie wepchnięte do każdej z nich, wymagając więcej pracy, ale pozwalając na znacznie większą kontrolę.

Początkowo używaliśmy modelu dziedziczenia we wszystkich wydaniach, gdzie późniejsze były dziećmi wcześniejsze. To działało dobrze przez jakiś czas, ale z czasem stało się niewykonalne. Duże różnice architektoniczne między wydaniami sprawiły, że nieuniknione dziedziczenie zmian było złym pomysłem. Tak, możesz wstawić migawkę pomiędzy, aby zablokować dziedziczenie, ale wtedy wszystkie zmiany muszą być popychane ręcznie, a jedyną rzeczywistą różnicą między strumieniem rodzic-migawka-dziecko a równoległymi, nie dziedziczącymi strumieniami jest to, że cały graficzny widok strumienia nieustannie przesuwa się w dół i w prawo, co jest PITA.

One really dobrą rzeczą w AccuRev jest to, że masz ten wybór, cały czas. Nie jest to nieodłączne ograniczenie architektury Twojego programu SCM.

Czy zauważyłeś, że możesz również zamawiać specfific file version z GIT?

Po prostu użyj tego:

git checkout [< tree-ish >] [--] < paths >

Jak w specyfikacji config każda istniejąca Wersja pliku (ścieżki) może być załadowana do obszaru roboczego. Cytat z git-checkout docs:

Następująca sekwencja sprawdza gałąź master, zwraca plik Makefile do dwóch wersji z powrotem, usuwa hello.c przez pomyłkę i pobiera go z indeksu:

$ git checkout master             
$ git checkout master~2 Makefile             
$ rm -f hello.c            
$ git checkout hello.c            

ClearCase, bez MultiSite, jest pojedynczym repozytorium, ale Git jest rozproszony. ClearCase zatwierdza na poziomie pliku, ale Git zatwierdza na poziomie repozytorium. (Ta ostatnia różnica oznacza, że pierwotne pytanie jest oparte na nieporozumieniu, jak wskazano w innych postach tutaj.)

Jeśli są to różnice, o których mówimy, to myślę, że 'linear' versus ' DAG ' jest mylącym sposobem odróżnienia tych systemów SCM. W ClearCase wszystkie wersje pliku są określane jako Wersja pliku "drzewo", ale tak naprawdę jest to Graf acykliczny! Prawdziwa różnica w stosunku do Gita polega na tym, że Dagi ClearCase istnieją na każdy plik. Więc myślę, że jest mylące odwoływanie się do ClearCase jako non-DAG i Git jako DAG.

(BTW ClearCase wersje swoich katalogów w podobny sposób do swoich plików-ale to już inna historia.)

Nie jestem pewien, czy o coś pytasz, ale demonstrujesz, że strumienie Accurev są innymi narzędziami niż gałęzie Git (lub SVN). (Nie znam Clearcase.)

Na przykład, w Accurev jesteś zmuszony , jak mówisz, do korzystania z pewnych przepływów pracy, co daje historię zmian, która nie jest obsługiwana w Git. Dziedziczenie Accurev sprawia, że niektóre przepływy pracy są bardziej wydajne, a inne niemożliwe.

Z Git możesz mieć kodowanie rozpoznawcze w lokalnych reposach lub w gałęziach funkcji, które nie byłyby dobrze obsługiwane przez Accurev.

Różne narzędzia są dobre do różnych celów; warto zapytać, do czego każdy z nich jest dobry dla.