Jestem w trakcie sprzedawania GIT w pracy. Pierwszą rzeczą, której potrzebuję, jest przekonanie wszystkich, że GIT jest lepszy w tym, do czego są przyzwyczajeni. Obecnie używamy Perforce. Czy ktoś jeszcze przechodził podobną wyprzedaż? Jakieś dobre linki / porady?
Jedną z wielkich korzyści jest to, że możemy z nim pracować bez połączenia z siecią. Kolejną wygraną IMO jest sposób obsługi dodawania / kasowania. Więcej punktów jest mile widzianych! Mamy też łącznie około 10-20 programistów.
Odpowiedzi:
Kod źródłowy interpretera Perl 5 przechodzi obecnie proces konwersji z Perforce na git. Może git-p4rawinteresuje importera Sama Vilaina .
W każdym razie jednym z głównych zwycięstw, jakie odniesiesz nad każdym scentralizowanym systemem VCS i najbardziej rozproszonym, jest również niesamowita szybkość . Nie możesz sobie wyobrazić, jak wyzwalające jest posiadanie pod ręką całej historii projektu, zaledwie ułamków ułamków sekundy, dopóki tego nie doświadczysz. Nawet generowanie dziennika zatwierdzeń całej historii projektu, który zawiera pełne różnice dla każdego zatwierdzenia, można zmierzyć w ułamkach sekundy. Git jest tak szybki, że twój kapelusz odleci. Systemy VCS, które muszą podróżować w obie strony przez sieć, po prostu nie mają szans na konkurowanie, nawet jeśli chodzi o łącze Gigabit Ethernet.
Ponadto git bardzo ułatwia ostrożną selekcję podczas wykonywania zatwierdzeń, umożliwiając w ten sposób rozłożenie zmian w kopii roboczej (lub nawet w jednym pliku) na wiele zatwierdzeń - i na różne gałęzie, jeśli tego potrzebujesz. Dzięki temu możesz robić mniej notatek w pamięci podczas pracy - nie musisz tak uważnie planować swojej pracy, decydując z góry, jaki zestaw zmian wprowadzisz, i pamiętaj, aby odłożyć cokolwiek innego. Możesz po prostu wprowadzić dowolne zmiany, gdy przyjdą Ci do głowy, i nadal je rozplątywać - prawie zawsze całkiem łatwo - kiedy nadejdzie czas na zatwierdzenie. Skrytka może być tutaj bardzo pomocna.
Odkryłem, że razem te fakty powodują, że w naturalny sposób wykonuję o wiele więcej i dużo bardziej skoncentrowanych zatwierdzeń niż przed użyciem git. To z kolei nie tylko sprawia, że Twoja historia jest ogólnie bardziej użyteczna, ale jest szczególnie korzystna w przypadku narzędzi wartości dodanej, takich jak git bisect.
Jestem pewien, że jest więcej rzeczy, o których nie mogę teraz myśleć. Jednym z problemów z propozycją sprzedaży swojego zespołu na git jest to, że wiele korzyści jest ze sobą powiązanych i współgra ze sobą, jak zasugerowałem powyżej, tak że trudno jest po prostu spojrzeć na listę funkcji i zalet gita i wywnioskować, jak one zmienią twój przepływ pracy, a które zmiany będą prawdziwymi ulepszeniami. Musisz wziąć to pod uwagę, a także wyraźnie to wskazać.
Używam Perforce w pracy. Używam również Gita, ponieważ nadal chciałbym mieć jakąś formę kontroli wersji, gdy pracuję nad kodem i nie mogę połączyć się z serwerem. Nie, pogodzenie pracy w trybie offline to nie to samo. Oto, gdzie odkryłem, że git jest wielką korzyścią:
Cóż, to moje 2 centy. W obronie Perforce muszę powiedzieć zasady obsługi klienta, podobnie jak narzędzie Time Lapse View. Nie wiem, jak uzyskać widok poklatkowy za pomocą gita. Ale ze względu na wygodę i oszczędność czasu, każdego dnia pójdę z gitem.
Odejście od konieczności wymagałoby wiele przekonywania. W dwóch firmach, z których korzystałem, było więcej niż wystarczające. Były to obie firmy z różnymi biurami, ale biura były wyposażone w dużą infrastrukturę, więc nie było potrzeby stosowania funkcji rozłącznych / niepowiązanych.
Ilu programistów chcesz zmienić?
Prawdziwe pytanie brzmi - co takiego jest w konieczności, co nie spełnia potrzeb Twojej organizacji, które może zapewnić git? I podobnie, jakie słabości ma git w porównaniu z koniecznością? Jeśli nie możesz sobie na to odpowiedzieć, pytanie tutaj nie pomoże. Musisz znaleźć uzasadnienie biznesowe dla swojej firmy. (np. być może wiąże się to z niższym całkowitym kosztem posiadania (obejmującym utratę produktywności na etapie tymczasowego uczenia się, wyższe koszty administracyjne (przynajmniej początkowo) itp.)
Myślę, że czeka cię ciężka sprzedaż - przymus jest całkiem niezły, aby spróbować go zastąpić. Nie ma problemu, jeśli próbujesz wyrzucić pvcs lub ssafe.
Myślę, że jeśli chodzi o dbanie o zadowolenie ludzi podczas przełączania / po zmianie, jedną z rzeczy, o których należy wcześnie się przekonać, jest to, jak prywatna może być lokalna gałąź w Git i jaka wolność daje im możliwość popełniania błędów. Niech wszyscy sklonują kilka gałęzi prywatnych z obecnego kodu, a następnie zaczną eksperymentować. Zmieniaj nazwy niektórych plików, wpisuj rzeczy, scalaj rzeczy z innej gałęzi, przewijaj historię, przebudowuj jeden zestaw zmian na inny i tak dalej. Pokaż, że nawet najgorsze lokalne wypadki nie mają konsekwencji dla kolegów. To, czego chcesz, to sytuacja, w której programiści czują się bezpiecznie, aby mogli uczyć się szybciej (ponieważ Git ma stromą krzywą uczenia się, co jest ważne), a ostatecznie, aby byli bardziej skuteczni jako programiści.
Kiedy próbujesz nauczyć się scentralizowanego narzędzia, oczywiście będziesz się martwić, że popełnisz błąd, który spowoduje problemy dla innych użytkowników repozytorium. Sam strach przed zakłopotaniem wystarczy, aby zniechęcić ludzi do eksperymentowania. Nawet posiadanie specjalnego repozytorium „szkoleniowego” nie pomaga, ponieważ nieuchronnie programiści napotkają w systemie produkcyjnym sytuację, której nigdy nie widzieli podczas szkolenia, więc wracają do zmartwień.
Ale rozproszona natura Gita eliminuje to. Możesz spróbować dowolnego eksperymentu w lokalnym oddziale, a jeśli pójdzie źle, po prostu wyrzuć gałąź i nikt nie musi o tym wiedzieć. Ponieważ możesz stworzyć lokalną gałąź czegokolwiek, możesz odtworzyć problem, który widzisz w prawdziwym repozytorium na żywo, ale nie masz niebezpieczeństwa „zepsucia kompilacji” lub zrobienia z siebie głupka. Możesz sprawdzić absolutnie wszystko, jak tylko to zrobisz, bez próbowania grupowania w zgrabne małe paczki. Więc nie tylko dwie główne zmiany w kodzie, nad którymi spędziłeś dziś cztery godziny, ale także poprawka kompilacji, którą zapamiętałeś w połowie, oraz błąd w pisowni w dokumentacji, którą zauważyłeś, wyjaśniając coś koledze i tak dalej. A jeśli zrezygnujemy z głównych zmian, ponieważ projekt zmienia kierunek,
Polecenie, które sprzedało mi osobiście gita, było przepołowione . Nie sądzę, aby ta funkcja była obecnie dostępna w jakimkolwiek innym systemie kontroli wersji.
Biorąc to pod uwagę, jeśli ludzie są przyzwyczajeni do klienta GUI do kontroli źródła, git nie będzie pod wrażeniem. Obecnie jedynym w pełni funkcjonalnym klientem jest wiersz poleceń.
git log --graph), ponieważ historie wersji Git mają tendencję do nieliniowości i są trudne do wizualizacji bez obrazu. Używam GitX i SourceTree jako GUI, chociaż gitk (który jest teraz dostarczany z Gitem) jest znośny w mgnieniu oka.
Z jakich funkcji Perforce korzystają ludzie?
Pytam, ponieważ jeśli wszyscy ludzie robią to pobierać i wstawiać z wiersza poleceń, git ma to na uwadze, podobnie jak wszystkie inne RTS.
Najwyraźniej GitHub oferuje teraz kursy szkoleniowe git dla firm . Cytuj ich post na blogu na ten temat :
W ciągu ostatnich kilku tygodni byłem kilka razy w kampusie Google, pomagając trenować tam androidy w Git. Shawn Pearce poprosił mnie o pomoc w przeszkoleniu inżynierów Google pracujących na Andriodzie w procesie przenoszenia od Perforce do Git , aby można było udostępniać Androida masom. Mogę powiedzieć, że byłam bardziej niż szczęśliwa, mogąc to zrobić.
[…]
Firma Logical Awesome oficjalnie oferuje ten rodzaj niestandardowych usług szkoleniowych wszystkim firmom, w których możemy pomóc Twojej organizacji w szkoleniu i planowaniu, jeśli myślisz również o przejściu na Git.
Podkreśl moje.
Używam Perforce od dłuższego czasu, a ostatnio zacząłem też korzystać z GIT. Oto moja „obiektywna” opinia:
Funkcje Perforce:
Funkcje GIT:
Ogólnie w przypadku projektów OpenSource / Distributed zawsze polecałbym GIT, ponieważ bardziej przypomina aplikację P2P i każdy może uczestniczyć w rozwoju. Na przykład, pamiętam, że kiedy robiłem zdalne programowanie z Perforce, synchronizowałem projekty 4 GB przez łącze 1Mbps raz w tygodniu. Z tego powodu zmarnowano mnóstwo czasu. Musieliśmy również skonfigurować VPN, aby to zrobić.
Jeśli masz małą firmę i serwer P4 będzie zawsze działał, to powiedziałbym, że Perforce jest również bardzo dobrą opcją.
Używamy Gita od jakiegoś czasu, ostatnio dysk twardy naszego serwera Git uległ awarii i nie mogliśmy wrócić do najnowszego stanu. Udało nam się wrócić do kilkudniowego stanu. Kiedy serwer został utworzony. Wszyscy w zespole wyciągnęli / wypchnęli swoje zmiany i voila, serwer wrócił do obecnego stanu.
Jedną ważną różnicą między Perforce i git (i jedną z najczęściej wymienianych) jest ich obsługa dużych plików binarnych.
Na przykład na tym blogu pracownika firmy tworzącej gry wideo: http://corearchitecture.blogspot.com/2011/09/git-vs-perforce-from-game-development.html
Jednak ważne jest to, że różnica w szybkości między git i perforce, gdy masz ogromne repozytorium 6 GB, zawierające wszystko, od dokumentacji po każdy plik binarny, jaki kiedykolwiek zbudowano (i wreszcie, o tak! Rzeczywista historia źródła) fakt, że ogromne firmy zwykle używają Perforce, więc ustawiły go tak, aby przeładować wszystkie istotne operacje do ogromnego banku serwerów w piwnicy.
Ta ważna zaleta ze strony Perforce wynika jedynie z czynnika, który nie ma nic wspólnego z Perforce, czyli z faktu, że firma, która ją obsługuje, może sobie pozwolić na wspomniany bank serwerów.
Ostatecznie Perforce i git to różne produkty. Git został zaprojektowany wyłącznie jako VCS i robi to o wiele lepiej niż Perforce (ponieważ ma więcej funkcji, które są ogólnie łatwiejsze w użyciu, w szczególności, mówiąc słowami innego, rozgałęzienie w Perforce jest jak wykonywanie otwartego serca operacja powinna być wykonana tylko przez ekspertów: P) ( http://stevehanov.ca/blog/index.php?id=50 )
Wszelkie inne korzyści, które zyskują firmy korzystające z Perforce, wynikają tylko z tego, że Perforce to nie tylko VCS, ale także serwer plików, a także wiele innych funkcji do testowania wydajności kompilacji itp.
Wreszcie: Git jest open source i znacznie bardziej elastyczny w rozruchu, nie byłoby tak trudno załatać git, aby przenieść ważne operacje na centralny serwer, obsługujący mnóstwo drogiego sprzętu.
Myślę, że jedyną rzeczą, na której wiem, że wygrywa GIT, jest możliwość „zachowania końcówek linii” we wszystkich plikach, podczas gdy forforce wydaje się nalegać na przetłumaczenie ich na format Unix, Dos / Windows lub MacOS9 ("\ n", "\ r \ n "lub" \ r).
To jest prawdziwy problem, jeśli piszesz skrypty Unix w środowisku Windows lub mieszanym środowisku OS. Nie można nawet ustawić reguły na podstawie rozszerzenia pliku. Na przykład konwertuje pliki .sh, .bash, .unix do formatu Unix i konwertuje pliki .ccp, .bat lub .com do formatu Dos / Windows.
W GIT (nie jestem pewien, czy jest to opcja domyślna, opcja czy jedyna) możesz ustawić to na „zachowaj zakończenia linii”. Oznacza to, że możesz ręcznie zmienić zakończenia linii pliku, a następnie GIT pozostawi ten format takim, jaki jest. Wydaje mi się, że jest to idealny sposób na robienie rzeczy i nie rozumiem, dlaczego nie jest to opcja w Perforce.
Jedynym sposobem osiągnięcia tego zachowania jest oznaczenie plików jako binarnych. Jak widzę, byłby to paskudny sposób na obejście brakującej funkcji. Oprócz tego, że byłoby to nudne we wszystkich skryptach itp., Prawdopodobnie zepsułoby to również większość różnic itp.
„Rozwiązaniem”, na które w tej chwili się zdecydowaliśmy, jest uruchomienie polecenia sed, aby usunąć wszystkie znaki powrotu karetki ze skryptów za każdym razem, gdy są one wdrażane w środowisku Unix. To też nie jest idealne, zwłaszcza, że niektóre z nich są rozmieszczone w plikach WAR, a linia sed musi zostać ponownie uruchomiona po rozpakowaniu.
Myślę, że jest to po prostu coś, co daje GIT wielką przewagę i nie sądzę, aby zostało to wspomniane powyżej.
EDYCJA: Po dłuższym używaniu Perforce chciałbym dodać kilka kolejnych komentarzy:
A) Coś, czego naprawdę brakuje mi w Perforce, to przejrzysta i instancyjna różnica, w tym zmienione, usunięte i dodane pliki. Jest to dostępne w GIT z rozszerzeniemgit diff polecenia, ale w Perforce pliki muszą zostać wyewidencjonowane przed zapisaniem ich zmian, i chociaż możesz ustawić swoje główne edytory (takie jak Eclipse), aby automatycznie wypisywać pliki podczas ich edycji, możesz może czasami edytować pliki w inny sposób (notatnik, polecenia unixowe itp.). Wydaje się, że nowe pliki nie są w ogóle dodawane automatycznie, nawet przy użyciu Eclipse i p4eclipse, co może być dość denerwujące. Aby znaleźć wszystkie zmiany, musisz uruchomić funkcję „Porównaj z ...” na całym obszarze roboczym, co po pierwsze zajmuje trochę czasu, a po drugie obejmuje wszystkie nieistotne rzeczy, chyba że utworzysz bardzo skomplikowane listy wykluczeń, co prowadzi mnie do następnego punktu.
B) W GIT uważam, że .gitignore jest bardzo proste i łatwe w zarządzaniu, czytaniu i zrozumieniu. Jednak lista ignorowania / wykluczania obszaru roboczego, którą można skonfigurować w Perforce, wydaje się nieporęczna i niepotrzebnie złożona. Nie udało mi się uzyskać żadnych wykluczeń, gdy działają symbole wieloznaczne. Chciałbym zrobić coś takiego
-//Server/mainline/.../target/... //Svend_Hansen_Server/.../target/...
Aby wykluczyć wszystkie foldery docelowe we wszystkich projektach na serwerze / głównej linii. Jednak wydaje się, że to nie działa tak, jak bym się spodziewał, i ostatecznie dodałem wiersz dla każdego projektu, taki jak:
-//Server/mainline/projectA/target/... //Svend_Hansen_Server/projectA/target/...
-//Server/mainline/projectB/target/... //Svend_Hansen_Server/projectB/target/...
...
I podobne wiersze dla folderów bin, plików .classpath i .projet i nie tylko.
C) W Perforce są dość przydatne listy zmian. Załóżmy jednak, że wprowadzam grupę zmian, sprawdzam je wszystkie i umieszczam na liście zmian, aby następnie popracować nad czymś innym przed przesłaniem listy zmian. Jeśli później dokonam zmiany w jednym z plików zawartych na pierwszej liście zmian, ten plik nadal będzie na tej liście zmian i nie mogę później przesłać listy zmian zakładając, że zawiera ona tylko zmiany, które pierwotnie dodałem (chociaż będą tymi samymi plikami). W GIT, jeśli dodasz plik i wprowadzisz w nim dalsze zmiany, te zmiany nie zostaną dodane (i nadal będą wyświetlane wgit diffi nie byłbyś w stanie zatwierdzić pliku bez wcześniejszego dodania nowych zmian. Oczywiście nie jest to przydatne w taki sam sposób, jak lista zmian może być, ponieważ masz tylko jeden zestaw dodanych plików, ale w GIT możesz po prostu zatwierdzić zmiany, ponieważ tak naprawdę ich nie wypycha. Mógłbyś popracować nad innymi zmianami przed ich wypchnięciem, ale nie byłbyś w stanie wypchnąć niczego innego, co dodasz później, bez przesunięcia również poprzednich zmian.
Nie mam doświadczenia z Gitem, ale mam Mercurial, który jest również rozproszonym VCS. To naprawdę zależy od projektu, ale w naszym przypadku rozproszony VCS pasował do projektu, ponieważ w zasadzie wyeliminował częste zepsute kompilacje.
Myślę, że tak naprawdę zależy to od projektu, ponieważ niektóre są lepiej dostosowane do VCS typu klient-serwer, a inne do rozproszonego.
Oto, czego nie lubię w git:
Po pierwsze, myślę, że rozproszona idea leci w obliczu rzeczywistości. Każdy, kto faktycznie używa git, robi to w sposób scentralizowany, nawet Linus Torvalds. Gdyby jądro było zarządzane w sposób rozproszony, oznaczałoby to, że nie mógłbym faktycznie pobrać "oficjalnych" źródeł jądra - nie byłoby takiego - musiałbym zdecydować, czy chcę wersję Linusa, czy wersję Joe, lub wersja Billa. To byłoby oczywiście śmieszne i dlatego istnieje oficjalna definicja, którą Linus kontroluje za pomocą scentralizowanego przepływu pracy.
Jeśli zaakceptujesz, że chcesz scentralizowanej definicji swoich rzeczy, stanie się jasne, że role serwera i klienta są zupełnie inne, więc dogmat, że oprogramowanie klienta i serwera powinno być takie samo, staje się czysto ograniczający. Dogmat, że klient i serwer danych powinna być taka sama staje się jawnie niedorzeczne, szczególnie w kodzie, który dostał piętnaście lat historii, że nikt nie dba o ale każdy musiałby klonu.
To, co naprawdę chcemy zrobić ze wszystkimi starymi rzeczami, to wrzucić je do szafki i zapomnieć, że tam są, tak jak robi to każdy normalny VCS. Fakt, że git codziennie przenosi to wszystko tam iz powrotem przez sieć, jest bardzo niebezpieczny, ponieważ nęka cię przycinanie. To przycinanie wiąże się z wieloma żmudnymi decyzjami i może się nie udać. Więc ludzie prawdopodobnie będą przechowywać całą serię repozytoriów migawek z różnych punktów w historii, ale czy nie po to była przede wszystkim kontrola źródła? Ten problem nie istniał, dopóki ktoś nie wymyślił modelu rozproszonego.
Git aktywnie zachęca ludzi do przepisywania historii, a powyższe jest prawdopodobnie jednym z powodów. Każdy normalny system VCS sprawia, że przepisywanie historii jest niemożliwe dla wszystkich oprócz administratorów i zapewnia, że administratorzy nie mają powodu, aby to rozważać. Popraw mnie, jeśli się mylę, ale o ile wiem, git nie zapewnia możliwości przyznania zwykłym użytkownikom prawa do zapisu, ale zakazuje im przepisywania historii. Oznacza to, że każdy programista mający urazę (lub wciąż borykający się z krzywą uczenia się) może zniszczyć całą bazę kodu. Jak to dokręcamy? Cóż, albo robisz regularne kopie zapasowe całej historii, tj. Utrzymujesz historię do kwadratu, albo blokujesz dostęp do zapisu wszystkim z wyjątkiem jakiegoś biednego drania, który otrzymywałby wszystkie różnice pocztą e-mail i łączył je ręcznie.
Weźmy przykład dobrze finansowanego, dużego projektu i zobaczmy, jak działa dla nich git: Android. Kiedyś postanowiłem pobawić się samym systemem Android. Dowiedziałem się, że powinienem użyć kilku skryptów zwanych repo, aby dostać się do ich gita. Część repozytoriów działa na kliencie, a część na serwerze, ale oba, przez samo ich istnienie, ilustrują fakt, że git jest niekompletny w obu przypadkach. Stało się tak, że nie byłem w stanie wyciągnąć źródeł przez około tydzień, a potem całkowicie się poddałem. Musiałbym pobrać naprawdę ogromną ilość danych z kilku różnych repozytoriów, ale serwer był całkowicie przeładowany ludźmi takimi jak ja. Upłynął limit czasu repozytorium i nie można go było wznowić od momentu, w którym upłynął limit czasu. Jeśli git jest tak rozpowszechnialny, można by pomyśleć, że Zrobiłem coś w rodzaju peer-to-peer, aby odciążyć ten jeden serwer. Git można rozpowszechniać, ale nie jest to serwer. Repozytorium Git + to serwer, ale repozytorium nie można rozpowszechniać, ponieważ jest to po prostu zbiór hacków ad hoc.
Podobną ilustracją nieadekwatności git jest gitolite (i jego przodek, który najwyraźniej nie działał tak dobrze). Gitolite opisuje swoją pracę jako ułatwianie wdrażania serwera git. Ponownie, samo istnienie tego czegoś dowodzi, że git nie jest serwerem, tak samo jak klientem. Co więcej, nigdy nie będzie, ponieważ gdyby wyrósł na jedno z nich, zdradziłoby jego podstawowe zasady.
Nawet gdybyś wierzył w to, co jest rozpowszechniane, git nadal byłby bałaganem. Czym jest na przykład oddział? Mówią, że niejawnie tworzysz gałąź za każdym razem, gdy klonujesz repozytorium, ale to nie może być to samo, co gałąź w pojedynczym repozytorium. Więc to co najmniej dwie różne rzeczy nazywane są gałęziami. Ale możesz też przewinąć do tyłu w repozytorium i po prostu rozpocząć edycję. Czy to jak drugi rodzaj gałęzi, czy znowu coś innego? Może to zależy od tego, jaki masz typ repozytorium - o tak - najwyraźniej repozytorium też nie jest zbyt jasną koncepcją. Są normalne i nagie. Nie możesz przejść do normalnego, ponieważ nieosłonięta część może stracić synchronizację ze swoim drzewem źródłowym. Ale nie możesz importować do gołego, bo oni o tym nie pomyśleli. Więc musisz cvsimportować do normalnego, sklonuj to do nagiego pliku, który trafił programiści, i przenieś to do kopii roboczej cvs, która nadal musi zostać sprawdzona w cvs. Kto może się niepokoić? Skąd się wzięły te wszystkie komplikacje? Z samego rozproszonego pomysłu. W końcu porzuciłem gitolite, ponieważ narzucał mi jeszcze więcej tych ograniczeń.
Git mówi, że rozgałęzianie powinno być lekkie, ale wiele firm ma już poważny problem z nieuczciwymi gałęziami, więc pomyślałbym, że rozgałęzianie powinno być doniosłą decyzją ze ścisłą kontrolą policji. To właśnie tam perforce naprawdę błyszczy ...
Z konieczności rzadko potrzebujesz gałęzi, ponieważ możesz żonglować zestawami zmian w bardzo zwinny sposób. Na przykład, typowy przepływ pracy polega na synchronizacji z ostatnią znaną dobrą wersją w sieci głównej, a następnie napisaniu funkcji. Za każdym razem, gdy spróbujesz zmodyfikować plik, różnica tego pliku zostanie dodana do twojego „domyślnego zestawu zmian”. Kiedy próbujesz sprawdzić zestaw zmian, automatycznie próbuje scalić wiadomości z linii głównej z zestawem zmian (skutecznie zmieniając bazę), a następnie zatwierdza. Ten przepływ pracy jest wymuszany bez konieczności jego zrozumienia. W ten sposób Mainline gromadzi historię zmian, przez które możesz łatwo przejść później. Na przykład załóżmy, że chcesz przywrócić stary, powiedzmy, ten przed ostatnim. Synchronizujesz się z momentem przed szkodliwą zmianą, zaznaczasz pliki, których to dotyczy, jako część zestawu zmian, zsynchronizuj się z chwilą później i połącz z „zawsze moje”. (Było tam coś bardzo interesującego: synchronizacja nie oznacza tego samego - jeśli plik jest edytowalny (tj. W aktywnym zbiorze zmian), nie zostanie on zbity przez synchronizację, ale oznaczony jako przeznaczony do rozwiązania.) Teraz masz lista zmian, która unieważnia jedną z nich. Połącz kolejne wiadomości, a otrzymasz listę zmian, którą możesz umieścić na głównej linii, aby uzyskać pożądany efekt. W żadnym momencie nie przepisaliśmy żadnej historii na nowo. Połącz kolejne wiadomości, a otrzymasz listę zmian, którą możesz umieścić na głównej linii, aby uzyskać pożądany efekt. W żadnym momencie nie przepisaliśmy żadnej historii na nowo. Połącz kolejne wiadomości, a otrzymasz listę zmian, którą możesz umieścić na głównej linii, aby uzyskać pożądany efekt. W żadnym momencie nie przepisaliśmy żadnej historii na nowo.
Teraz, przypuśćmy, że w połowie tego procesu ktoś podbiega do ciebie i każe ci rzucić wszystko i naprawić jakiś błąd. Po prostu nadajesz swojej domyślnej liście zmian nazwę (a właściwie numer), a następnie "zawieszasz" ją, naprawiasz błąd w pustej domyślnej liście zmian, zatwierdzasz ją i wznawiasz nazwaną listę zmian. Typowe jest zawieszenie kilku list zmian naraz, podczas których próbujesz różnych rzeczy. To łatwe i prywatne. Dostajesz to, czego naprawdę chcesz, od reżimu oddziału bez pokusy zwlekania lub powstrzymywania się przed włączeniem się do głównej linii.
Przypuszczam, że teoretycznie byłoby możliwe zrobienie czegoś podobnego w git, ale git praktycznie wszystko umożliwia, zamiast zapewniać przepływ pracy, który akceptujemy. Model scentralizowany to zbiór ważnych uproszczeń w stosunku do modelu rozproszonego, który jest nieprawidłowym uogólnieniem. Jest tak uogólniony, że zasadniczo oczekuje, że zaimplementujesz kontrolę źródła, tak jak robi to repozytorium.
Druga sprawa to replikacja. W git wszystko jest możliwe, więc musisz sam to rozgryźć. W efekcie otrzymujesz efektywnie bezstanową pamięć podręczną. Jedyną konfiguracją, którą musi znać, jest lokalizacja mastera, a klienci mogą wskazać serwer główny lub pamięć podręczną według własnego uznania. To pięć minut pracy i nie może pójść źle.
Masz również wyzwalacze i konfigurowalne formularze do potwierdzania recenzji kodu, odniesień do bugzilli itp. I oczywiście masz gałęzie, które są używane wtedy, gdy ich potrzebujesz. To nie jest jasne, ale jest blisko i jest bardzo łatwe w konfiguracji i utrzymaniu.
Podsumowując, myślę, że jeśli wiesz, że będziesz pracować w sposób scentralizowany, co robi każdy, równie dobrze możesz użyć narzędzia, które zostało zaprojektowane z myślą o tym. Git jest przereklamowany z powodu przerażającego dowcipu Linusa i skłonności ludzi do podążania za sobą jak owce, ale jego główna racja bytu nie stoi w sprzeczności ze zdrowym rozsądkiem, a idąc za nim, wiąże swoje ręce z dwa ogromne dogmaty, że (a) oprogramowanie i (b) dane muszą być takie same zarówno na kliencie, jak i na serwerze, a to zawsze komplikuje i komplikuje scentralizowaną pracę.
Używanie GIT jako substytutu zarządzania złymi liniami kodu jest powszechne. Wiele wad Perforce wynika ze złych strategii rozgałęziania. To samo dotyczy każdego innego scentralizowanego narzędzia. Jeśli musisz stworzyć mnóstwo gałęzi, robisz coś złego. Dlaczego programiści muszą tworzyć tak wiele oddziałów?
Poza tym, dlaczego praca bez połączenia jest tak ważna? Tylko po to, żeby ktoś mógł pracować w pociągu? To chyba jedyne miejsce w dzisiejszych czasach, w którym nie można uzyskać połączenia bezprzewodowego. A nawet większość pociągów ma przyzwoite WiFi.