Niemal każdy artykuł, który przeczytałem 1 porównujący Git i Mercurial, wygląda na to, że Mercurial ma lepszą linię poleceń UX, przy czym każde polecenie jest ograniczone tylko do jednego pomysłu (w przeciwieństwie do powiedzenia git checkout
).
Ale w pewnym momencie Git nagle stał się bardzo popularny i liczba osób przesyłających Git na wykresie popcon Debiana (patrz rysunek poniżej) dosłownie eksplodowała.
Źródło: Debian
To, co stało się w sezonie 2010-01, nagle się zmieniło. Wygląda na to, że GitHub został założony wcześniej - 2008.
apt-cache rdepends git-core
, aapt-cache rdepends mercurial
. Być może nie ma to nic wspólnego z git innym niż jest dołączony, ponieważ ktoś zainstalował jakiś inny wspólny pakiet. Na przykład jestem użytkownikiem etckeeper i ikiwiki, które są oparte na git (myślę, że można również użyć mercurial). Sugeruję, abyś poświęcił trochę czasu i spojrzał na wszystkie różne rzeczy, które zależą lub polecają git-core.Odpowiedzi:
Pakiet „gnuit” (GNU Interactive Tools, przeglądarka / przeglądarka plików i przeglądarka procesów) był nazywany „git” w Debianie do 2009-09-09, podczas gdy git był nazywany „git-core”.
Dlatego lepszym wykresem jest:
Co pokazuje, że popularność nie wzrosła dramatycznie (weź zieloną linię na lewą część, aż się skrzyżują, a następnie weź czerwoną linię).
źródło
Pakiet git w Debianie był wcześniej znany jako
git-core
. W kwietniu 2010 r. Zmieniono nazwę pakietu nagit
. Więcej szczegółów można znaleźć w tym poście na blogu Juliusa Plenza lub w tym zatwierdzeniu w Debianie .Oto wykres, który pokazuje numer instaluje zarówno
git
igit-core
czasie:źródło
Przez jakiś czas korzystałem z Darcs do własnych projektów. Przełączyłem się na git podczas szybkiego wstąpienia, do którego odnosi się twój wykres, więc oto moja obserwacja:
Rozproszone systemy kontroli źródła w tym czasie były przełomowe. Tak zwani programiści alfa używali ich z boku, ale wypadli poza zasięg radaru większości profesjonalnych programistów. Sposób patrzenia na świat przez CVS / SVN / SourceSafe / TFS był taki, że programiści ogólnie byli mniej lub bardziej zadowoleni i większość ludzi zakładała, że problemy, które zrodziły rozproszony system kontroli źródła, można naprawić za pomocą lepszych narzędzi. Podobnie jak w przypadku poprawy z CVS -> SVN, któregoś dnia będzie coś, co pozwoli ci przejść do SVN -> SVN ++. Jak inaczej zarządzałbyś kontrolą źródła?
Potem przyszedł git. To, co zmusiło gitarzystę do radaru wszystkich, to fakt, że istniał ogromny , publiczny projekt, który natychmiast go przyjął. Git ma wielu użytkowników za darmo - jeśli chcesz poważnie zhakować jądro, użyjesz git. Chociaż nie mogę być w 100% pewien, postawiłbym na to, że w tym momencie żaden inny DVCS nie miał tak dużej bazy użytkowników.
Potem zadziałało. Działa dobrze. Działało dobrze w miejscach publicznych. Ponadto, ze względu na początkowe brodawki, był bardziej stabilny niż większość ówczesnych DVCS. Na przykład Darcs można wprowadzić w niespójny stan, który wymagałby absurdalnie złożonej (kwadratowej? Silnej? Nie pamiętam na pewno, ale źle ) naprawy. Git zawsze był bardziej stabilny.
Z dużej bazy użytkowników po prostu wykrwawiło się.
Każdy projekt, komercyjny lub open source, potrzebuje tej masy krytycznej. Darcs tego nie rozumiał. Podobnie jak Mercurial. Pomyśl. Wykorzystuje go wiele mniejszych projektów. Prawdopodobnie jest nawet wielu użytkowników komercyjnych. Ale jaka jest Twoja historia sukcesu?
„Jeśli jest wystarczająco dobry dla jądra Linuksa, jest wystarczająco dobry dla ciebie” to bardzo przekonujący argument.
Podsumowując, był to dobry produkt, który pojawił się we właściwym czasie i zyskał dużą, oddaną bazę użytkowników.
źródło
Spóźniłem się na adopcję - przejście z Mercurial na Git około 2010 roku.
Uważam, że Git stał się tak popularny, ponieważ strony takie jak GitHub miały efekt sieciowy w narzędziach kontroli wersji. Nie było to wcześniej widoczne, ponieważ dzielisz kod na podstawie projektu lub firmy.
W szczególności pamiętam przejście na Git i Github, ponieważ wszystkie projekty, którymi byłem zainteresowany, przyczyniły się do tego samego, podobnie jak deweloperzy, z którymi się kojarzę.
To efekt sieci.
GitHub był najpopularniejszą warstwą współpracy opartą na DVCS, a Git okazał się „wystarczająco dobry”. Mercurial był z pewnością łatwiejszy do nauczenia się i obsługi, Git ma wiele niuansów, ale miał solidną markę dzięki Linusowi.
To, że GitHub został uruchomiony w '08, a rozwój zaczyna się w '10, nie oznacza, że GitHub nie ponosi odpowiedzialności. Jeśli spojrzysz na konkurencyjne wykresy wzrostu w innych obszarach, takich jak sieci społecznościowe i rozwój Facebooka, linia jest bardzo podobna.
Nie widzisz takich wykresów wzrostu bez efektu wirusowej pętli / sieci.
Na przykład porównać do wykresu wzrostu na Facebooku
Aktualizacja: Wiem, że powyższe źródło mogło nie być dokładne, ale istnieje wiele źródeł danych, które pokazują, że Git rośnie gwałtownie w ciągu ostatnich kilku lat.
Wykres 1: Wzmianki o Git w ogłoszeniach o pracę
A badanie Eclipse, które pokazuje, że udział w rynku Git wzrósł z 13% w 2011 r. Do 27% w 2012 r . Niesamowity wzrost.
Ten post zawiera znacznie lepsze wyjaśnienie wzrostu Gita i efektów sieciowych niż to, co tutaj zrobiłem.
źródło
Dla jasności, ten wykres pokazuje instalację git na systemach Debian.
Mniej więcej w tym czasie nastąpił skok nazwy pakietu Debian z git-core na git. Może ludzie uznali pakiet za łatwiejszy, skoro nazwa odzwierciedla oprogramowanie.
źródło
Dziwi mnie, że nikt nie wspomniał o Githubie jako jednym z głównych powodów, dla których Git zyskał popularność . Wprowadzili główny nurt git.
Github został wydany w kwietniu 2008 roku i zyskał popularność w ciągu 1-2 lat. A potem, gdy zobaczysz nagłą eksplozję użycia git / git-core, wynika to przede wszystkim z 2 milionów użytkowników github i ich 3,7 miliona repozytoriów. Github sprawia, że git jest łatwy w użyciu. Bitbucket był tam, ale github sprawił, że było to łatwe. Jestem pewien, że gdyby faceci z github wybrali Hg zamiast git, powinniśmy zobaczyć taki sam wzrost wykorzystania Hg.
Analogią może być: Canonical: Linux :: Github: Git
źródło
Cóż, IMHO, dystrybuowane VCS, takie jak Hg i Git, są z natury lepsze niż scentralizowane VCS - więc SVN zawsze przegrał z jednym z nich.
I git, jak już zaobserwowano, miał ogromną przewagę nad Hg, że był używany przez największy i odnoszący największe sukcesy projekt open source na świecie - od samego początku jest to rekordowa historia.
Co do tego, dlaczego nagła eksplozja na początku 2010 r., Moim zdaniem jest dość prozaiczna. Git jest genialny, ale dla początkującego nie jest zbyt intuicyjny.
Najlepsza książka Git, IMHO, to Pro Git, która została opublikowana we wrześniu 2009. Druga najlepsza (ponownie IMHO), książka Git O'Reilly, została opublikowana w czerwcu 2009.
Tak więc powód użycia Gita na początku 2010 roku może być tak prosty, jak fakt, że wtedy dostępne były naprawdę dobre zasoby do nauczenia się, jak z niego korzystać.
źródło
Wybór systemu kontroli wersji jest decyzją społeczną. Cały zespół musi korzystać z tego samego rozwiązania. W przeciwieństwie do edytora tekstu, który jest osobistą decyzją - różni programiści mogą używać różnych edytorów i łatwo współpracować.
Istnieją więc efekty sieciowe związane z wyborem systemu kontroli wersji, co powoduje, że systemy, które mogą być nieco lepsze lub nieco bardziej popularne, stają się jeszcze bardziej popularne.
Na przykład wolę darcs dla projektów typu open source, ale odkryłem, że więcej moich potencjalnych współpracowników zna git i chętniej otrzymuję więcej wkładów na projekty hostowane z git zamiast darcs. Więc zamiast tego używam git dużo zamiast darcs. Następnie, ponieważ używam go i publikuję kod na Githubie, wydaje się, że go popieram, a nawet wolę, co może wpłynąć na korzystanie z niego przez innych.
Deweloperzy nie chcą uczyć się nowego systemu kontroli źródła dla każdego projektu, do którego się przyczyniają, więc korzyścią dla całej społeczności jest posiadanie standardu, który jest „wystarczająco dobry” i powszechnie popularny, a następnie wybór każdego zespołu i projektu na „najlepszy” „roztwór w próżni.
Github dodał tylko paliwo do efektu sieci.
źródło
Patrząc na skorygowany wykres w odpowiedzi Michaela, pokazujący zarówno git-core, jak i git w systemach Debian, wydaje się, że wydaje się, dlaczego git stał się popularny w 2006 roku na systemach Debian i dlaczego rozwijał się wykładniczo w latach 2006-2012.
Powodem może być silne przyjęcie dystrybucji Linuksa opartych na Debianie, takich jak Ubuntu, które stały się popularne około 2005-2006 i stały się pierwszą dystrybucją aż do około 2011 roku, kiedy Mint, również oparta na Debianie, stała się numerem 1. Pod koniec 2012 roku Mint jest nadal numerem 1, a Ubuntu nr 3 według DistroWatch .
GitHub, założony w 2008 roku, zapewnia darmowy hosting gitów, a w latach 2008-2012 stał się pierwszą na świecie usługą repozytorium źródeł z około 2,5 milionami użytkowników i około 4,5 milionami projektów , według Wikipedii pod koniec 2012 roku.
Pod koniec 2000 roku Railsy i wiele innych projektów zmieniło się z Rubyforge na GitHub. Ponadto Bundler został wprowadzony mniej więcej w pierwotnym pytaniu (pod koniec 2009 r.) Z obsługą instalowania / aktualizowania klejnotów za pomocą
:git
opcji w pliku Gemfile, a Bundler został uwzględniony jako zależność od Rails 3. Projekty w Python, JavaScript, C, C ++ , Java, CSS itp. Również zostały migrowane do lub uruchomione w GitHub.Ci, którzy chcieli wziąć udział w projektach na GitHubie, musieli rozwidlić projekt w GitHub, użyć lokalnego klienta git, aby sklonować repozytorium przed wprowadzeniem poprawek i wypchnięciem ich z powrotem do GitHub i wykonaniem żądania ściągnięcia. Było to o wiele prostsze niż inne metody stosowane wcześniej i prawdopodobnie był to istotny powód, dla którego został przyjęty przez projekty, które przeniosły się do GitHub lub zdecydowały się tam rozpocząć. Oznaczało to, że git-core / git musiał zostać zainstalowany w dystrybucjach opartych na Debianie, aby programiści mogli korzystać z GitHub.
Tak więc uważam, że była to kombinacja dystrybucji opartych na Debianie, która stała się bardziej popularna i zyskała popularność git z powodu wzrostu liczby użytkowników i projektów w GitHub, co prawdopodobnie wynika z bezpłatnego hostingu i doświadczeń użytkowników GitHub.
źródło
Myślę, że wiele osób myli korelację z przyczyną.
Wszystkie przedstawione wykresy pokazują korelacje między miarami popularności gitsów i zdarzeń ... a innymi miarami. Jednak korelacja nie jest wyraźnym dowodem na związek przyczynowy.
Niektóre inne odpowiedzi próbują narysować relacje z innymi rzeczami; np. ewangelizacja Linusa Torsvaldsa dla DVCS, utworzenie Github, rozwój sieci społecznościowych. Chociaż istnieją dowody na to, że korelacja (na osi czasu) nie jest tak silna, nie wyklucza to związku przyczynowego. Zwłaszcza jeśli zaakceptujesz hipotezę „efektu sieci”; tzn. istnieje wiele przyczyn.
Najważniejsze jest to, że dostępne dowody nie mogą wykazywać związku przyczynowego. Mówimy o zbiorowym zachowaniu setek tysięcy ludzi, a ludzie podejmują decyzje z różnych powodów ... lub z braku logicznego powodu. Programiści nie różnią się niczym od nikogo innego.
źródło