Który DVCS (git lub hg) jest łatwiejszy do programowania studentów? [Zamknięte]

25

Trochę kontekstu: jestem na trzecim roku studiów. studenci są podzieleni na 4-osobowe zespoły. Prawie wszyscy będą pracować pod oknami (z wyjątkiem kilku takich jak ja, którzy są na systemie Linux). W ramach szkolnego programu nauczania wkrótce zaczniemy pracować nad projektem dla prawdziwego klienta, ale ja i inny zespół zastanawiamy się, w jaki sposób najlepiej byłoby udostępnić sobie nasz kod.

Pracuję w niepełnym wymiarze godzin przez 3 lata i mam duże doświadczenie w używaniu zarówno git, jak i merkurialu w różnych projektach, więc nie mam żadnych problemów z używaniem jednego lub drugiego systemu. Jednak żaden z moich kolegów z zespołu nigdy wcześniej nie używał systemu kontroli wersji. Jest też inny zespół, który próbował użyć SVN, ale miał poważne problemy i wolałby wypróbować coś innego, więc poprosił o moją opinię.

Moje przemyślenia: Słyszałem, że mercurial + TortoiseHg ma lepszą integrację pod oknami, ale zastanawiam się, czy koncepcja anonimowych głów może je pomylić, nawet jeśli je wyjaśnię. Z drugiej strony uważam, że gałęzie git są łatwiejsze do zrozumienia dla początkującego (wyraźne rozdzielenie pracy dla każdego programisty), ale nie działa tak dobrze pod oknami.

Gregory Eric Sanderson
źródło
2
git ma domyślnie włączoną dużą moc, ale wszyscy, z którymi rozmawiałem, mówią, że mercurial jest łatwiejszy do nauczenia, i jestem skłonny się zgodzić na podstawie moich doświadczeń z użyciem obu. I tak, narzędzia rtęciowe są łatwiejsze do zainstalowania w systemie Windows niż ich odpowiedniki git. To powiedziawszy, spodziewaj się poprowadzić ludzi i skieruj ich na samouczki przez pierwszy tydzień (lub dłużej ...).
wkl 28.10.11
1
Korzystanie z DVCS od samego początku jest prawdopodobnie najprostszym sposobem zarządzania łączeniem wkładów od wielu współpracowników pracujących równolegle. Jeśli uważasz, że anonimowe głowy są mylące, nie używaj ich (obsługuje mercurial o nazwie oddziały).
Stephen C. Steel
2
Znowu czas na link do tego postu na blogu? Git to Harrier Jump Jet .
sbi
1
Nigdy nie rozumiałem, dlaczego całe „zbyt trudne do nauczenia” ma znaczenie. Okej, więc zajmuje 20 minut, aby nauczyć się, jak zatwierdzać i rozgałęziać, i tak jak w przeciwieństwie do 10 ... Wielka sprawa?
alternatywny
1
Zobacz, jak jeden z nich przechodzi przez hginit.com i podejmuje działania w oparciu o ich reakcje.
chelmertz

Odpowiedzi:

49

Bez wątpienia Mercurial.

Jest to oczywiście subiektywne i dzieli się od jednej osoby do drugiej, ale ogólna opinia jest taka, że ​​Mercurial jest łatwiejszy do grokowania, szczególnie dla kogoś nowego w VCS lub kogoś pochodzącego z jednego z VCS starej generacji.

Punkty w ręku:

  1. Mercurial został opracowany z myślą o systemie Windows ; Git został przeniesiony. Bez względu na to, co ktoś próbował mi powiedzieć, Git nadal jest obywatelem drugiej kategorii w systemie Windows. W ciągu ostatnich kilku lat sytuacja uległa znacznej poprawie, ale nadal pojawia się wiele sprzeczek, dlaczego coś działa / nie działa w systemie Windows, tak jak w przypadku * nix box. TortoiseHg działa bardzo dobrze, a implementacje Visual Studio są jeszcze łatwiejsze w użyciu bez przerywania przepływu pracy.

  2. Jeśli ktoś rozpocznie dyskusję „Git jest potężniejszy po tobie ...”, to prawie mówi wszystko. Dla 95% użytkowników Mercurial wydaje się bardziej intuicyjny. Począwszy od braku indeksu, przez jego bardziej intuicyjne opcje (przełączniki opcji są spójne), aż po lokalne liczby zatwierdzeń zamiast skrótów SHA1 (kto kiedykolwiek uważał, że skróty SHA1 są przyjazne dla użytkownika?!)

  3. Gałęzie Mercuriala są nie mniej potężne niż Git. Post opisujący niektóre różnice. Powrót do poprzedniej wersji jest tak prosty, jak „aktualizacja starej wersji”. Zaczynając od tego; po prostu wykonaj nowe zatwierdzenie. Nazwane oddziały są również dostępne, jeśli ktoś chce ich użyć.

Teraz wiem, że wszystkie są szczegółami i można się ich nauczyć i wszystko, ale chodzi o to, że ... te rzeczy się sumują. I w końcu jeden wydaje się prostszy i bardziej intuicyjny niż inny. A system kontroli wersji nie powinien być czymś, na co trzeba się uczyć - musisz się uczyć programowania, a następnie programować; VCS to narzędzie.

Uwaga: Używam Git i Mercurial codziennie. Nie miej problemów z użyciem jednego z nich. Ale kiedy ktoś prosi mnie o rekomendację, zawsze polecam Mercurial. Wciąż pamiętam, kiedy po raz pierwszy dostał się w moje ręce, czułem się bardzo intuicyjnie. Z mojego doświadczenia wynika, że ​​Mercurial produkuje po prostu mniej WTF / minutę niż Git.

Wieża
źródło
4
+ dla „VCS to narzędzie”. Nie wziąłem pod uwagę „małych rzeczy” jako czynnika, ale prawdą jest, że kiedy dodacie małe problemy tu i tam, mogą one stać się prawdziwą uciążliwością.
Gregory Eric Sanderson
8
„System kontroli wersji nie powinien być czymś, czego można się nauczyć.” To mnóstwo bzdur. Zawsze powinieneś spędzać czas na nauce swoich narzędzi. Spędzasz czas na nauce kompilatora; ale VCS jest tak samo ważnym narzędziem do programowania, jak kompilator.
JesperE
9
+1. Szczególnie argument „obywatel drugiej klasy w systemie Windows” jest absolutnie ważny w tej sytuacji.
tdammers
+1 za „WTF (s) / minute” ( osnews.com/story/19266/WTFs_m ). Te dzieci muszą nauczyć się skillz :-)
Ross Patterson
1
@ Mark to tylko wynik różnic terminologicznych ... Oddział w Git to tak naprawdę tylko nazwa.
alternatywnie
10

Przekonałem się, że interfejs TortoiseHg to świetne doświadczenie w systemie Windows. Kiedy eksperymentowałem z Gitem w przeszłości, zamiast tego trafiłem do wiersza poleceń. Dla przeciętnego użytkownika dobry interfejs użytkownika jest znacznie bardziej dostępny niż wiersz poleceń. Sugerowałbym więc użycie Mercurial. (Zawiera również ładny wykres rozgałęzienia w oknie środowiska roboczego. Powinien on usunąć wszystkie podstawowe trudności z rozgałęzianiem).

Gdy zrozumieją wszystko z perspektywy interfejsu użytkownika, mogą w końcu przejść do wiersza poleceń, aby napisać skrypt lub wykonać operacje ręczne - ale nie muszą.

John Fisher
źródło
Będąc ćpunem konsolowym, nigdy wcześniej nie korzystałem z aplikacji Tortoise {Svn, Git, Hg}, więc nie wiedziałem, że TortoiseHg ma wykres rozgałęziony. Muszę to sprawdzić
Gregory Eric Sanderson
4

Jeśli interesuje Cię trzecia opcja, proponuję skamielinę . Uważam, że możliwość rzucenia tymczasowego serwera WWW w celu współdzielenia kodu działa świetnie w małych projektach. Skamielina jest tylko plikiem wykonywalnym, więc możesz umieścić ją i swoje źródło w pamięci USB i używać z dowolnego komputera uniwersyteckiego.

Posługiwać się fossil ui do uruchamiania tymczasowego serwera internetowego w dowolnym miejscu, aby umożliwić synchronizację z innymi uczniami. Zapewnia również system zgłoszeń, wiki i łatwy w użyciu interfejs sieciowy do zmiany oddziałów i oznaczania zatwierdzeń.

Upewnij się tylko, że przeczytali przewodnik Szybki start i / lub książkę . Wreszcie, istnieje projekt o nazwie winFossil, który daje im bardziej przyjazny interfejs użytkownika niż interfejs WWW.

Spencer Rathbun
źródło
Słyszałem dobre rzeczy o skamielinach, ale niestety nie mam zbyt wiele czasu na zapoznanie się z nowym DVCS. Wolę używać czegoś, do czego jestem przyzwyczajony (jeśli to możliwe), ponieważ już wiem, jak obejść najczęstsze pułapki. Ale dzięki za sugestię, na pewno przyjrzę się jej, kiedy będę miał czas.
Gregory Eric Sanderson
+1; skamielina jest mało znana, ale jest tak łatwa do pracy i tak niezależna (dvsc + wiki + bilety + serwer WWW), że jest prawdziwą alternatywą dla całego trac lub nawet github.
Javier
Ale skamielina nie będzie wyglądać tak dobrze na CV uczniów, jak git lub hg, ponieważ bardzo niewielu ludzi ma tego dość.
Ian
Mercurial ma również wbudowaną funkcjonalność służącą do obsługi hg. Oczywiście brakuje mi narzędzia do śledzenia błędów i wiki. Ale jest też bitbucket.com
Johannes Rudolph,
3

Biorąc pod uwagę, że zespoły są nowe w kontroli wersji, a wiele korzysta z systemu Windows, poleciłbym mercurial zamiast git.

Koncepcyjny model kontroli wersji używany przez git i mercurial jest bardzo podobny, więc po opanowaniu jednego łatwo jest wybrać drugi (iz podobnych powodów dość łatwo jest przekonwertować repozytorium z jednego na drugi) . Oznacza to, że nie jest to wielka sprawa, jeśli później zmienisz zdanie.

Moim zdaniem merkurial jest łatwiejszy do nauczenia się dla nowych użytkowników. To sprawia, że ​​proste rzeczy stają się łatwe, a niebezpieczne trudne. Git sprawia, że ​​niebezpieczne operacje są łatwe (łatwe do wykonania, niekoniecznie łatwe do prawidłowego wykonania!).

Interfejs TortoiseHg dla Winodows jest również bardzo miły i jest kolejnym argumentem przemawiającym za użyciem mercurial.

Stephen C. Steel
źródło
2

Moje osobiste preferencje dotyczą git.

Ponieważ jednak niektórzy ludzie będą korzystać z systemu Windows i istnieje świetny samouczek hginit , zalecam nauczenie ich rtęci.

dan_waterworth
źródło
+1 za wzmiankę o hginit. Chociaż Pro Git też jest całkiem niezły.
Tamás Szelei
@ TamásSzelei, Dzięki, nie widziałem wcześniej Pro Git.
dan_waterworth
0

Jak wiele osób sugerowało, Mercurial za pośrednictwem TortoiseHg ma bardzo niską barierę wejścia.

Dla tych w systemie Windows jest to pojedynczy instalator zamiast dwóch instalatorów (i cała masa rzeczy, o których mogliby nie chcieć się uczyć), a interfejs użytkownika THg jest znacznie bardziej dopracowany niż TortoiseGit + Msysgit .

Anonimowe głowy

Jeśli sądzisz, że pomylą ich anonimowe głowy, nie zachęcaj ich do używania. Większość hgksiążek przyjmuje zrównoważone podejście i uczy zarówno topologicznych, jak i nazwanych gałęzi, i pozwala czytelnikowi określić, który jest najbardziej odpowiedni do ich użycia.

Nazwane oddziały

Jedna rzecz, którą naprawdę brakuje w gitto hg„s wymienione gałęzie , tak że jedna opcja. gitgałęzie są w porządku, gdy nad nimi pracujesz, ale po scaleniu tej pracy z inną gałęzią tracisz znaczną część kontekstu dla tych zmian.

W hgmożesz utworzyć oddział o nazwie Jira#1234i zawsze być w stanie znaleźć wszystkie poprawki związane z tą poprawką . W gitraz twój oddział jest scalona i sędzia usunięte, trzeba wnosić poprawki, które były częścią poprawki od topologii drzewa rewizyjnej. Nawet jeśli nie usuniesz referencji, nadal wiesz tylko ostatnie zatwierdzenie w tej gałęzi, a nie który z jej przodków był częścią tego łańcucha zatwierdzeń.

Zakładki

Alternatywnie, jeśli nie chcesz używać nazwanych gałęzi, ale chcesz mieć gitstyl pracy z anonimowymi gałęziami, możesz zamiast tego użyć zakładek .

Może to być najlepsze z obu światów - uczą się gitprzepływu pracy, ale mogą korzystać z prostszych hgpoleceń.

Indeks / pamięć podręczna / obszar przejściowy

Osobiście uważam, że uczniowie są znacznie bardziej zdezorientowani przez gitindeks / pamięć podręczną / obszar postoju niż przez hganonimowe głowy. Zdecydowanie wolę, hgaby ta zaawansowana funkcjonalność była opcjonalna w wierszu poleceń, a przy okazji gitzakładam, że zawsze chcesz / musisz z niej korzystać.

Myślę też, że obszar inscenizacji zachęca do zatwierdzeń, które nie zostały przetestowane ani nawet skompilowane. Ponieważ w wielu miejscach, w których pracowałem, nie było zatwierdzania, jeśli nie kompiluje reguły, wolałbym odkładać / ukrywać zmiany, których nie chcę teraz, ponownie uruchomić testy jednostkowe i zatwierdzić wersję, która Znam kompilacje.

Kiedy później przyjdziesz do śledzenia błędu za pomocą hg bisect lub git bisect , podziękujesz sobie, że możesz przetestować wszystkie wersje, nie tylko te, które się kompilują.

Mark Booth
źródło
Po zakończeniu nie musisz usuwać gałęzi git; to tylko zwyczaj. Również -1 do błędnej interpretacji użycia indeksu - nie używasz go do tworzenia niepoprawnych zatwierdzeń, używasz go do przemieszczania częściowych kroków większej serii zatwierdzeń. Zwykle dzieje się tak podczas rebaseu, gdy czyścisz swoją historię.
alternatywnie
@mathepic - Jeśli nie usuniesz nazw gałęzi i nie wypchniesz wszystkich lokalnych gałęzi „naprawiających” zdalnie, to skończysz z ogromną liczbą referencji, tak jak skończysz z mnóstwem starych gałęzi w svn. W hgtych gałęziach nazwy są zawsze topologicznie lokalne, więc możesz je zobaczyć tylko wtedy, gdy ich szukasz.
Mark Booth
@mathepic - Jeśli chodzi o twoje -1, myślę, że źle interpretujesz to, co mówię. Nie mogę sobie wyobrazić, dlaczego ktoś celowo popełnił błąd, ale z git łatwo to zrobić przypadkowo. Jeśli zapomnisz tego pliku cimplementuje zmodyfikowany interfejs w pliku ii przypadkowo popełnić ibez cwtedy, gdy ktoś ściąga zmiany przed masz wokół do popełniania cich kompilacji zakończy się niepowodzeniem. Jeśli zamiast tego użyjesz przepływu pracy ukryć / kompiluj / zatwierdzaj, ten błąd po prostu się nie zdarzy, ponieważ pierwsza kompilacja ulegnie awarii. Próbowałem jednak wyjaśnić swoją odpowiedź.
Mark Booth