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

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.

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.

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

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.

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.

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.

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