GIT vs. Perforce - wejdą dwa VCS… jeden opuści [zamknięte]

85

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.

Justin Bozonier
źródło

Odpowiedzi:

75

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ć.

Arystoteles Pagaltzis
źródło
Podobno p4sandbox zapewnia pewne możliwości offline dla p4. Niemniej jednak nadal lubię git. :)
Dominic Mitchell
13
Git nie zapewnia „możliwości offline”, jest offline. Jedyne, co przesyłasz przez sieć, to przekazywanie zatwierdzeń do źródła lub pobieranie zmian z innych repozytoriów podrzędnych.
Evan Plaice
2
"Git jest tak szybki, że twój kapelusz odleci" uwielbiam :) Jedyna rzecz, która nie jest prawdziwa, kiedy zaczynasz rejestrować pliki binarne. duże repozytoria są kłopotliwe w git.
v.oddou,
1
Niestety prawda. Sposób działania Gita zależy od odczytywania plików i nieco od ich porównywania, więc muszą one mieć skromne rozmiary i dobrze się porównywać. Wtedy będzie niesamowicie szybki (jak w przykładzie natychmiastowej pełnej historii różnic dla setek zatwierdzeń). Z ogromnymi plamami? Nie tak bardzo…
Arystoteles Pagaltzis
84

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ą:

  1. Szybkość rozgałęziania - git zajmuje najwyżej kilka sekund.
  2. Konflikty - automatyczne rozstrzygnięcie P4Merge zniszczyło raz tygodniową pracę. Od tego czasu wolę rozwiązywać ręcznie podczas łączenia. Kiedy Git podpowiada mi konflikt, w rzeczywistości jest to konflikt. Przez resztę czasu git rozwiązuje problemy poprawnie, a ja oszczędzam mnóstwo czasu.
  3. Śledzenie fuzji - jeśli masz jedną gałąź, która stale otrzymuje połączenia z dwóch innych gałęzi, wiesz, jaki ból głowy może to być z konieczności. Dzięki git ból głowy jest zminimalizowany, ponieważ wynik scalenia w git jest w rzeczywistości nowym zatwierdzeniem, które wie, kim są jego przodkowie.
  4. Uprawnienia - straciłem orientację, ile razy próbowałem pracować nad plikiem, ale nie mogłem, ponieważ nie został on pobrany w Perforce. Jeśli pracowałeś z XCode (lub jakimkolwiek edytorem, który nie ma solidnej wtyczki Perforce SCM) offline, wiesz, jak irytujące może to być. Nie muszę się tym martwić z Gitem. Dokonuję zmian. Git mnie nie zatrzymuje i śledzi je w tle.
  5. Utrzymywanie porządku w głównym drzewie - dzięki git mogę posortować moje zatwierdzenia i uporządkować kod, aby historia wyglądała ładnie i schludnie. Żadnego z tych bzdur "sprawdzania w tym pliku, ponieważ miał być częścią poprzedniego wpisu". Zgniatam takie zobowiązania, bo nikomu nie pomagają.
  6. Przechowywanie - Twój serwer Perforce musi być w wersji 2010.1 lub nowszej, aby można było używać polecenia p4 shelve.
  7. Tworzenie poprawek - łatwe do zrobienia w git. Nie wiem, czy jest to możliwe w Perforce bez użycia wiersza poleceń.
  8. Wysyłanie poprawek z GUI - znowu wygrywa git.
  9. Miejsce na dysku - z konieczności każda gałąź jest kopią. Oznacza to, że jeśli drzewo źródłowe jest ogromne, miejsce na dysku szybko się zużywa. Nie liczy to nawet dodatkowej przestrzeni po rozpoczęciu budowy. Po co w ogóle mieć łącze między gałęziami a przestrzenią dyskową? Dzięki git możesz mieć 100 oddziałów, a jednocześnie istnieje tylko jedna gałąź. Jeśli chcesz pracować na dwóch wersjach jednocześnie, możesz klonować, wykonywać swoją pracę, a następnie pozbyć się jednego klona, ​​jeśli chcesz, nie tracąc niczego.
  10. Jeśli korzystasz z XCode4, obsługa Perforce została usunięta, a obsługa git jest teraz wbudowana. Jeśli pracujesz na różnych platformach, tak jak ja, ma to duże znaczenie. W programie Visual Studio możesz używać rozszerzeń git. Z siłą jest to równie fuj na obu systemach operacyjnych. Cóż, może teraz trochę więcej na Macu z XCode4 na scenie.
  11. Znajdowanie błędnego checkin (lub zasad git bisect) - Czy kiedykolwiek próbowałeś przeprowadzić wyszukiwanie binarne z koniecznością, aby dowiedzieć się, gdzie wprowadzono błąd? Dość kłopotliwe, tak? Jeszcze bardziej kłopotliwe, gdy w środku były integracje z innych gałęzi. Czemu? Ponieważ nie ma automatyzacji dla takich zadań. Musisz napisać własne narzędzie, aby rozmawiać z siłą i zwykle nie masz czasu. Dzięki git dajesz mu punkty początkowe („dobry” i „zły” punkt), a to zautomatyzuje wyszukiwanie. Co więcej, jeśli masz skrypt, który może zautomatyzować proces budowania i testowania, możesz podłączyć git do skryptu, a cały proces znajdowania checkin jest zautomatyzowany. Tak powinno być.
  12. Śledzenie zmian w refaktorach - spróbuj podzielić BigClass na SmallClass1 i SmallClass2. Dla Perforce BigClass przestał już istnieć i dwie nowe klasy (SmallClass1 i SmallClass2 dołączyły do ​​drzewa źródłowego). W przypadku Perforce nie ma związku między BigClass a SmallClass1 i SmallClass2. Z drugiej strony Git jest wystarczająco inteligentny, aby wiedzieć, że x% BigClass jest teraz w SmallClass1, a y% BigClass jest w SmallClass2 i że BigClass przestał istnieć. Teraz, z punktu widzenia osoby, która przegląda zmiany w wielu gałęziach, powiedz mi, które podejście byłoby bardziej przydatne - Git czy Perforce. Osobiście wolę podejście Git, ponieważ dokładniej odzwierciedla rzeczywistą zmianę w kodzie. Git jest w stanie to zrobić, ponieważ śledzi zawartość w pliku, a nie sam plik.
  13. Scentralizowany lub zdecentralizowany: Git to system DVCS , podczas gdy perforce jest scentralizowany. Scentralizowanego VCS nie można później zdecentralizować, ale DVCS (zwłaszcza git) można scentralizować. Istnieje kilka produktów, które dodają bardzo precyzyjną kontrolę dostępu do git, jeśli jest to coś, czego potrzebuje firma. Osobiście wybrałbym system, który w dłuższej perspektywie daje mi większą elastyczność.
  14. Mapowanie gałęzi: Jeśli chcesz wykonywać rozgałęzianie bezpośrednio w Perforce, musisz utworzyć mapowanie gałęzi. Istnieją ku temu powody, ale są one powiązane ze sposobem, w jaki Perforce konceptualizuje gałąź. Dla programisty lub zespołu oznacza to po prostu jeszcze jeden krok w przepływie pracy, którego w ogóle nie uważam za efektywny.
  15. Współdzielenie pracy między zespołami: dzięki Perforce nie można przerywać przesyłania. Zespół A pracuje nad funkcją A. Zespół B nad funkcją B. Zespół C pracuje nad poprawkami błędów. Teraz zespoły A i B muszą naprawić kilka błędów, aby zaimplementować swoje funkcje. Jedyną rzeczą jest to, że nie byli tak zdyscyplinowani podczas zatwierdzania zmian (prawdopodobnie dlatego, że spieszyli się do terminu), więc ich „poprawki błędów” są częścią większych zgłoszeń, które zawierają również nowe rzeczy, jeśli chodzi o kontrolę wersji na ich branże. Jednak zespół C robi teraz wydanie punktowe i chciałby uzyskać poprawki błędów od innych zespołów. Gdyby używali Git, Zespół C mógłby wybrać odpowiednie zmiany innych zespołów, podzielić je i wziąć tylko to, czego potrzebują, bez martwienia się o wprowadzenie jakichkolwiek częściowo zaimplementowanych funkcji. Z Perforce,
  16. Zmiana platformy - jeśli z jakiegoś powodu w przyszłości zdecydujesz się zmienić wybraną platformę, dzięki Perforce jesteś zdany na łaskę Perforce.com i dostępność narzędzi dla wybranej platformy.
  17. Zmiana na przyszły niesamowity silnik kontroli źródła X - Jeśli zdecydujesz się zmienić to, czego używasz do kontroli źródła, wyodrębnienie historii kontroli źródła z Perforce i przeniesienie jej do nowego systemu X będzie koszmarem, ponieważ jest to zamknięte źródło i najlepsze możesz zgadnąć - wystarczy przenieść Google for Perforce do Git, aby zrozumieć, o czym mówię. Przynajmniej z Git, jego open source, więc eliminuje wiele domysłów.

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.

Carl
źródło
2
re # 6 (skrytka): półka p4, jest nowa.
Trey
Dzięki. Zaktualizowałem moją odpowiedź :)
Carl
8
Największą różnicą między Perforce i Git jest wymagany sposób myślenia. Jeśli prowadzisz scentralizowany sklep VCS, git będzie naprawdę trudny do sprzedania, ponieważ wymaga zmiany sposobu, w jaki Ty, Twój zespół i firma myślicie o kontroli wersji. Innymi słowy, git to doskonałe i wydajne narzędzie, które jest technicznie bardziej wydajne niż Perforce. Najtrudniejsze jest przekonanie ludzi :)
Carl
1
Jestem zakochany w Perforce. Czytanie tego posta to jak oszukiwanie ...
KlausCPH
2
@KlausCPH przynajmniej nie będziesz musiał przygotowywać przemówienia zerwania, kiedy opuścisz Perforce :)
Carl
46

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.

Tim
źródło
18
Dodam, że niezwykły zestaw funkcji Git jest kosztem stromej krzywej uczenia się. (Chociaż nigdy nie uważałem Perforce za tak intuicyjne.)
savetheclocktower
1
Świetna odpowiedź Tim. Justin - dlaczego twój szef jest sprzedawany? Z pewnością musiałeś odpowiedzieć na pytanie Tima, żeby to zrobić? Byłbym również zainteresowany uzasadnieniem.
Greg Whitfield
4
Za Perforce trzeba płacić w środowisku komercyjnym i naprawdę zawsze uważałem, że Perforce jest nieprzyjemny w użyciu. Jedyną siłą, jaką naprawdę widzę, jest to, że dobrze radzi sobie z dużymi binarnymi plamami.
Calyth
2
@Justin: Uważaj na powód „będziemy używać tylko podstawowych funkcji”. Z git skończysz na bardziej zaawansowanych rzeczach. Dlaczego nie miałbyś? Od razu przychodzi mi na myśl Bisect. Więc zrób rebase i wybierz cherry-pick.
Carl
3
Właściwie to, że prowadziliśmy odpowiednią rozmowę w komentarzach, która zakończyła się, gdy pojawił się monit „Czy na pewno nie chciałbyś przenieść tego do czatu”, ktoś w końcu zauważył, że to pytanie w rzeczywistości nie nadaje się do SO. Zasadniczo pyta o to, dlaczego jeden system jest „lepszy” od innego, i zachęca do wielu ożywionych debat.
Adam Parkin
15

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,

tialaramex
źródło
Nie ma też powodu, dla którego nie możesz mieć prywatnej gałęzi scentralizowanego systemu. DVCS czasami radzą sobie lepiej w scalaniu, ale tylko dlatego, że gałąź prywatna nie istnieje w zdalnym repozytorium, nie oznacza, że ​​nie możesz utworzyć gałęzi tylko dla siebie, która istnieje w zdalnym repozytorium.
Billy ONeal
2
Ten komentarz jest technicznie poprawny, ale w pewnym sensie mija się to z celem. Systemy kontroli wersji to narzędzie społecznościowe. Oddział z Twoim imieniem i nazwiskiem na serwerze współdzielonym nie jest „prywatny”, ale jest udostępniony. Tak, nawet z listami ACL i cokolwiek innego. Istnieją również różnice techniczne (oczywiście mój prywatny oddział git jest używany, gdy dojeżdżam do domu, bez / zawodny Internet), ale są one zależne od różnicy społecznej.
tialaramex
2
Prywatny oddział z konieczności jest do bani. Łatwość, z jaką tworzysz i przełączasz się między gałęziami w git, nie może być porównywana z koniecznością. Jakże prywatny jest z konieczności oddziałem „prywatnym”. Nie trzymasz tego lokalnie. Jesteś całkowicie zależny od dostępu do sieci.
Erik Engheim,
9

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ń.

Ryan
źródło
1
Dla uczciwości (wybrałem git zamiast Hg) należy zauważyć, że Mercurial ma również zdolność do dzielenia na dwie części - chociaż jest dostarczany jako wtyczka, którą musisz załadować bezpośrednio.
Arystoteles Pagaltzis
2
darcs miał "śledzenie", zanim istniał git. Trzeba przyznać, że wczesne wersje były dość szorstkie.
mądry
2
jeśli chodzi o interfejs użytkownika - GitX na OSX jest doskonały.
Antony Stubbs
4
SourceTree to także kolejny fajny natywny klient OSX. Stał się wolny po jego zdobyciu. Używam go już od jakiegoś czasu i podoba mi się. Przed użyciem SourceTree byłem głównie Commandlinerem.
Prakash Nadar
1
Z mojego doświadczenia z Git wynika, że ​​naprawdę potrzebujesz zarówno wiersza poleceń, jak i klienta graficznego, aby go efektywnie używać. Potrzebujesz wiersza poleceń, ponieważ jest dużo mocy, której nie można łatwo umieścić w GUI, i potrzebujesz GUI (lub przynajmniej 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.
Marnen Laibow-Koser
9

Z jakich funkcji Perforce korzystają ludzie?

  • Wiele obszarów roboczych na jednym komputerze
  • Numerowane listy zmian
  • Oddziały deweloperskie
  • Integracja z IDE (Visual Studio, Eclipse, SlickEdit, ...)
  • Wiele wariantów kompilacji
  • Obszary robocze złożone
  • Integracja niektórych poprawek, ale innych nie
  • itp

Pytam, ponieważ jeśli wszyscy ludzie robią to pobierać i wstawiać z wiersza poleceń, git ma to na uwadze, podobnie jak wszystkie inne RTS.

Thomas L Holaday
źródło
2
Nie jestem pewien, co oznacza „wiele obszarów roboczych na jednym komputerze” - inne systemy VCS po prostu nie mają pojęcia obszaru roboczego, więc naprawdę nie można go reklamować jako funkcji Perforce. Jednak inne mają sens.
Billy ONeal
Przykład z wieloma obszarami roboczymi: klient A ma wersje deweloperskie i wydania tylko plików A oraz podzbiór narzędzi wewnętrznych w wersji 1.52; klient B ma pliki przeznaczone tylko do tworzenia i wydania B oraz inny, ale nakładający się podzbiór narzędzi wewnętrznych, zarówno w wersji deweloperskiej, jak i 1.52. Programista pracuje nad obydwoma jednocześnie i może zdecydować, że zmienione narzędzia wewnętrzne będą widoczne dla użytkownika A, aby zobaczyć, co się psuje.
Thomas L Holaday
6
@Tomas: Dlaczego nie ... Po prostu sprawdź to dwa razy? Perforce musi mieć to jako „funkcję”, ponieważ w przeciwnym razie będzie to dziwne z powodu konieczności upewnienia się, że zmienne środowiskowe są poprawnie ustawione, wpisy rejestru są poprawne, itd.
Arafangion
@Arafangion, nie jest oczywiste, w jaki sposób dwukrotne sprawdzenie ułatwia selektywne udostępnianie plików do tworzenia zestawów.
Thomas L Holaday
6

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.

Arystoteles Pagaltzis
źródło
4

Używam Perforce od dłuższego czasu, a ostatnio zacząłem też korzystać z GIT. Oto moja „obiektywna” opinia:

Funkcje Perforce:

  1. Narzędzia GUI wydają się być bardziej funkcjonalne (np. Widok poklatkowy, wykres wersji)
  2. Szybkość synchronizacji z wersją głowicy (brak kosztów związanych z przenoszeniem całej historii)
  3. Integracja Eclipse / Visual Studio jest naprawdę fajna
  4. Możesz opracować wiele funkcji w jednej gałęzi na Changelistę (nadal nie jestem w 100% pewien, czy jest to przewaga nad GIT)
  5. Możesz „szpiegować” to, co robią inni programiści - jakie pliki pobrali.

Funkcje GIT:

  1. Mam wrażenie, że wiersz poleceń GIT jest znacznie prostszy niż Perforce (init / clone, add, commit. Brak konfiguracji złożonych Workspace)
  2. Szybkość uzyskiwania dostępu do historii projektu po płatności (kosztem kopiowania całej historii podczas synchronizacji)
  3. Tryb offline (programiści nie będą narzekać, że nieosiągalny serwer P4 uniemożliwi im kodowanie)
  4. Tworzenie nowych gałęzi jest znacznie szybsze
  5. „Główny” serwer GIT nie potrzebuje wielu TB pamięci, ponieważ każdy programista może mieć własną lokalną piaskownicę
  6. GIT to OpenSource - bez opłat licencyjnych
  7. Jeśli Twoja firma uczestniczy również w projektach OpenSource, udostępnianie poprawek jest znacznie łatwiejsze dzięki 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ą.

user389238
źródło
Funkcja Git nr 1 jest w najlepszym razie wątpliwym twierdzeniem. Być może Git wygrywa w konfiguracji, ale codzienne użytkowanie jest dość niezdarne (często wymaga wielu poleceń, aby wykonać proste zadanie)
Adam Parkin
1
@AdamParkin Jakie zadania uważasz za niezdarne z wiersza poleceń? (Używam GUI tam, gdzie to możliwe, ale myślę, że struktura poleceń Gita jest przyzwoita.)
Marnen Laibow-Koser
1
@AdamParkin Cóż, łatwość korzystania z wiersza poleceń to aspekt estetyczny, stąd przynajmniej subiektywny. Powodem, dla którego osobiście uważam linię poleceń Gita za prostszą niż Perforce, jest to, że w Perforce musisz skonfigurować obszary robocze i zmienne środowiskowe (P4USER itp.), Zanim będziesz mógł nawet rozpocząć pracę z plikami repozytorium, w porównaniu z pojedynczym "klonem git" Komenda. Oczywiście istnieje kilka zaawansowanych poleceń git, których nie ma w Perforce (np. Przepisywanie lokalnej historii) i dla zwykłych użytkowników Perforce mogą one wydawać się „nauką o rakietach”.
user389238
Nie używałem tego, ale wydaje mi się, że zarządzanie zestawami zmian to tylko gałąź biednego człowieka, biorąc pod uwagę, że w git możesz zgnieść gałęzie funkcji lub zmienić je na master.
Ryan The Leach
4

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.

Prakash Nadar
źródło
3
W przemówieniu, które Linus wygłosił w @ Google na temat Git, mówi o tym, jak nie robi kopii zapasowych, ponieważ każdy klon jądra Linuksa jest jego pełną kopią zapasową. Właściwie to naprawdę dobra uwaga.
Adam Parkin
Jest to prawdą pod każdym względem, każde zamknięcie jest „kopią zapasową”, ale w wielu przypadkach git jest nadal używany jako narzędzie „scentralizowane-rozproszone”. tj. podobnie jak SVN z dodatkowymi zaletami rozgałęziania. Organizacja zawsze chce mieć kopię zapasową wszystkiego, co ma.
Prakash Nadar
3

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.

pjnlsn
źródło
3

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.

Svend Hansen
źródło
2

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.

Stacja końcowa
źródło
(To prawda, to stara odpowiedź, ale ...) Możesz uruchomić Git (i zakładam również Mercurial) tak, jakby był to VCS klient-serwer. To nadal działa lepiej niż VCSs klient-serwer, ze względu na łatwość rozgałęzienia i połączenia oraz możliwość indywidualnych zatwierdzeń. Nie widzę już pożytku z VCS klient-serwer, przynajmniej dopóki nie osiągną swoich umiejętności scalania na równi.
Marnen Laibow-Koser
-5

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ę.

Adrian May
źródło
4
Och, co do cholery. Mam kilka minut, więc spróbuję skomentować niektóre większe błędy. „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. ”- Nie mogę rozmawiać z projektem jądra Linuksa konkretnie, ponieważ nigdy nad nim nie pracowałem, ale generalnie tak naprawdę działa oprogramowanie typu open source. Możesz pobrać dowolny widelec.
Marnen Laibow-Koser
2
„To, co naprawdę chcemy zrobić ze wszystkimi starymi rzeczami, to wrzucić je do szafy i zapomnieć, że tam są, tak jak robi to każdy normalny system VCS. Fakt, że git ciągnie to wszystko w tę iz powrotem przez sieć każdego dnia jest bardzo niebezpieczny, ponieważ dręczy cię przycinanie go. " • Czy kiedykolwiek używałeś Git? Git nie zmusza cię do przycinania repozytorium. Poza tym kompresja danych Gita jest niezwykle wydajna; zdarza się, że repozytorium Git - ze złożoną historią gałęzi - jest znacznie mniejsze niż kopia robocza SVN (bez historii) tego samego kodu.
Marnen Laibow-Koser
4
„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, by się nad tym zastanawiać. Popraw mnie, jeśli się mylę, ale o ile wiem, git nie zapewnia możliwości pisania zwykłym użytkownikom nie mają dostępu, ale zabraniają im przepisywania historii. Oznacza to, że każdy programista z urazą (lub wciąż borykający się z krzywą uczenia się) może zniszczyć całą bazę kodu ”. • Mylisz się w 100%. Łatwo jest zabronić wypychania siłowego do repozytorium, jednocześnie umożliwiając dostęp do zapisu. Ponadto każdy może mieć kopię tak dużej części repozytorium, jak chce, więc koszowanie nie zadziała.
Marnen Laibow-Koser,
3
„Git twierdzi, że tworzenie gałęzi powinno być lekkie, ale wiele firm ma już poważny problem z nieuczciwymi oddziałami, więc pomyślałbym, że tworzenie gałęzi powinno być doniosłą decyzją ze ścisłą kontrolą policji. W tym miejscu perforce naprawdę błyszczy ...” • Co to jest „problem z nieuczciwym oddziałem”? Jak myślisz, dlaczego rozgałęzianie powinno być „doniosłą decyzją”? W praktyce bardzo przydatna jest możliwość tworzenia gałęzi (prywatnych lub publicznych) dla każdej nowej funkcji lub eksperymentu, tak aby każdy z nich żył w swoim własnym alternatywnym wszechświecie. W przeciwieństwie do, powiedzmy, SVN, Git ułatwia scalanie, więc działa to bardzo dobrze.
Marnen Laibow-Koser,
3
Fakt, że ta odpowiedź ma tylko jedną negatywną opinię oprócz mojej (najwyraźniej @Marnen), zadziwia mnie, biorąc pod uwagę, jak obiektywnie jest ona błędna.
alternatywnie
-8

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.

sogboj
źródło
9
Niektórzy programiści lubią tworzyć gałęzie, aby móc łatwo izolować i segmentować różne opracowania, prototypy, poprawki błędów itp. Często zależy to od rodzaju pracy. Gałęzie Perforce są dość ciężkie w zarządzaniu w porównaniu z gałęziami Git i Mercurial, dlatego można wprowadzić pewne ulepszenia produktywności.
Greg Whitfield,
8
Umiejętność pracy bez kontaktu nie zawsze wiąże się z ideą pracy w pociągu czy samolocie. Niektóre firmy mogą nie mieć niezawodnej infrastruktury sieciowej. Możesz też uzyskać przerwy w pracy, konserwację serwerów, ogólne napady itp. Jednak efektem ubocznym możliwości pracy w trybie odłączonym jest to, że operacje kontroli źródła są oszałamiająco szybkie w porównaniu z systemami, które polegają na obiegowej sieci, aby cokolwiek zrobić.
Greg Whitfield,
6
Z mojego doświadczenia wynika, że ​​używanie procesu do kontrolowania ludzi wskazuje przede wszystkim na zły projekt przepływu pracy. Powinien istnieć przepływ pracy, aby ludzie byli produktywni. Jeśli nie jest używany, jest z nim coś nie tak, ponieważ generalnie ludzie nie są idiotami i jeśli się zetkną, użyją lepszego narzędzia.
Carl
6
Głosowanie w dół z powodu „Jeśli musisz stworzyć mnóstwo gałęzi, robisz coś złego”. Może to być prawdą w scentralizowanym VCS z nieodpowiednimi narzędziami scalającymi (takimi jak SVN lub CVS - nigdy nie używano Perforce). To nieprawda w Git, gdzie rozgałęzianie i scalanie są łatwe i powszechne. Daje to swobodę dla każdej rozwijanej funkcji w swoim własnym alternatywnym wszechświecie do czasu integracji. Osobiście nigdy nie wróciłbym do środowiska, w którym nie mógłbym rozgałęziać się z kaprysu.
Marnen Laibow-Koser