Який DVCS (git або hg) простіший для програмування студентів? [зачинено]

Трохи контексту: я на 3 курсі коледжу. студенти діляться на команди по 4. Практично всі працюватимуть під вікнами (за винятком кількох, як я, які в Linux). Як частина шкільної програми, ми незабаром почнемо працювати над проектом для справжнього клієнта, але я та інша команда задаємось питанням, який спосіб був би найкращим для обміну кодом між собою.

Я працюю неповний робочий день 3 роки і маю багато досвіду використання як git, так і mercurial у різних проектах, тому у мене немає проблем з використанням тієї чи іншої системи. Однак ніхто з моїх товаришів по команді ніколи раніше не використовував систему контролю версій. Є ще одна команда, яка намагалася використовувати SVN, але у них були великі проблеми і вважала за краще спробувати щось інше, тому вони попросили моєї думки.

Мої думки: я чув, що меркуріал + TortoiseHg має кращу інтеграцію під вікнами, але мені цікаво, чи може поняття анонімних голів заплутати їх, навіть якщо я їх поясню. З іншого боку, я вважаю, що гіти Git легше для початківців, щоб зрозуміти (чіткий розділ роботи для кожного програміста), але він не працює так добре під Windows.

Меркуріал, без сумніву.

Це, звичайно, суб'єктивно і змінюється від однієї людини до іншої, але загальна думка полягає в тому, що Меркуріал легше рискувати, особливо для когось нового в VCS або когось із поколінь VCS старого покоління.

Окуляри в руці:

1. Mercurial був розроблений з урахуванням Windows ; Гіт був перенесений. Незалежно від того, що хто-небудь намагався мені сказати, Git все ще є другорядним громадянином Windows. Речі дещо покращилися за останні кілька років, але ви все ще бачите багато проблем, чому щось працює / або не працює в Windows, як це було зроблено у * nix box. TortoiseHg працює дуже добре, а реалізаціями Visual Studio ще простіше користуватися, не порушуючи робочий процес.

2. Якщо хтось починає дискусію "Git є потужнішим після тебе ...", то він майже все це говорить. Для 95% користувачів Mercurial здається більш інтуїтивно зрозумілим. Починаючи від нестачі індексу, до його більш інтуїтивно зрозумілих параметрів (опціональні комутатори є когерентними), до його локальних номерів для комітетів замість хешів SHA1 (хто коли-небудь вважав, що хеші SHA1 зручні для користувачів ??!)

3. Гілки Меркуріала не менш потужні, ніж Гіт. Пост з описом деяких відмінностей. Повернутися до попередньої редакції так само просто, як "оновити стару версію". Починаючи звідти; просто зробіть новий вчинок. Іменовані гілки також доступні, якщо хочеться ними користуватися.

Тепер я знаю, що все це деталі, і їх можна дізнатися і про все, але річ у тому ... ці речі складаються. І врешті-решт, одне здається простішим та інтуїтивнішим, ніж інше. І система контролю версій не повинна бути те, на що витрачаєш час, - ти там вивчаєш програмування, а потім програмуєш; VCS - це інструмент.

Просто зазначити; Я щодня використовую Git і Mercurial. Не мати проблем із використанням одного з них. Але коли хтось запитує у мене рекомендації, я завжди рекомендую Mercurial. Ще пам’ятаю, коли це вперше потрапило мені в руки, це почувалося дуже інтуїтивно. На мій досвід, Mercurial просто виробляє менше WTF / хвилину, ніж Git.

Я виявив, що інтерфейс TortoiseHg - це чудовий досвід роботи в Windows. Експериментуючи з Git у минулому, я замість цього перейшов до командного рядка. Для середнього користувача хороший інтерфейс користувача набагато доступніший, ніж командний рядок. Отже, я б запропонував використовувати Mercurial. (Він також містить хороший графік гілки у вікні верстака. Він повинен очистити будь-які основні труднощі розгалуження.)

Як тільки вони зрозуміють речі з точки зору користувальницького інтерфейсу, вони можуть перейти до командного рядка для сценарію або виконувати вручну операції - але цього не потрібно.

Якщо вас цікавить третій варіант, я б запропонував викопний . Я знаходжу можливість підключити тимчасовий веб-сервер, щоб ділитися кодом, чудово працює в невеликих проектах. Копальня - це просто виконуваний файл, тому ви можете помістити його та джерело у привід для великого пальця та використовувати його з будь-якого університетського комп’ютера.

Використовуйте fossil uiдля запуску тимчасового веб-сервера, де б ви не мали синхронізації з вами однокурсниками. Він також надає вам систему квитків, вікі та простий у користуванні веб-інтерфейс для зміни гілок та позначення комітетів.

Просто переконайтеся, що вони прочитали посібник із швидкого запуску та / або книгу . Нарешті, існує проект під назвою winFossil, щоб надати їм дружніший інтерфейс користувача, ніж веб-інтерфейс.

Зважаючи на те, що команди новинки в контролі версій, і багато хто використовує Windows, я б рекомендував курсив над git.

Концептуальна модель управління версіями, що використовується git та mercurial, дуже схожа, тому щойно ви освоїли одне, легко підібрати інший (і з подібних причин перетворити сховище з одного в інше досить просто) . Це означає, що це не велика справа, якщо ви згодом передумаєте.

На мій погляд, новому користувачеві легше навчитися. Це робить прості речі легкими, а небезпечні - важкими. Git робить небезпечні операції легкими (легко робити, не обов’язково легко робити правильно!).

Інтерфейс TortoiseHg для Winodows теж дуже приємний, і це ще один аргумент на користь використання mercurial.

Мої особисті переваги - це git.

Однак, оскільки деякі користувачі будуть використовувати Windows, і чудовий посібник з hginit існує, я б рекомендував навчати їх меркуріалу.

Як вважають багато людей, Mercurial через TortoiseHg має дуже низький бар'єр для входу.

Для тих, хто працює в Windows, це один інсталятор, а не два інсталятори (і ціла кількість речей, про які вони можуть не хотіти дізнатися), а інтерфейс користувача THg набагато більш відшліфований, ніж TortoiseGit + Msysgit .

Анонімні голови

Якщо ви думаєте, що їх збентежать анонімні голови, тоді не заохочуйте їх використання. Більшість hgкниг мають збалансований підхід і вчать як топологічні, так і названі гілки, і дозволяють читачеві визначити, який найбільш підходить для їх використання.

Названі гілки

Одна річ , яку я дійсно НЕ вистачає в gitце hg«s названі гілки , так що це один варіант. gitгілки добре під час роботи над ними, але коли ви об'єднали цю роботу в іншу гілку, ви втратите велику частину контексту для цих змін.

У hgвас може створити гілку під назвою Jira#1234і завжди бути в змозі знайти все ревізії , пов'язані з цим виправленням . Після того git, як ваша філія об'єднана і посилання буде видалено, ви повинні зробити висновок, які редакції були частиною виправлення з топології дерева ревізії. Навіть якщо ви не видалите посилання, ви все одно знаєте лише останнє зобов’язання в цій гілці, а не хто з його предків був частиною цього ланцюжка комітетів.

Закладки

Крім того, якщо ви не хочете використовувати названі гілки, але хочете виконати gitстиль роботи з вашими анонімними гілками, тоді ви можете використовувати закладки .

Це може бути найкращим для обох світів - вони отримують для вивчення gitробочого процесу, але отримують для використання більш прості hgкоманди.

Індекс / Кеш / Постановочна область

Особисто я вважаю, що студенти набагато частіше плутають gitіндекс / кеш / область постановки, ніж hgанонімні голови. Я дуже вважаю за краще, hgщоб ця розширена функціональність була необов’язковою в командному рядку, тому що gitви завжди хочете / потребуєте її використовувати.

Я також думаю, що місце постановки заохочує вчинення, які не були перевірені або навіть складені. Оскільки у багатьох місцях, над якими я працював, не виконувались, якщо воно не компілює правило, я б швидше відклав / приховав зміни, які я не хочу зараз, повторно запустіть одиничні тести та введіть версію, яка Я знаю компіляції.

Коли ви пізніше прийдете відслідковувати помилку за допомогою hg bisect або git bisect , ви подякуєте собі, що ви можете перевірити всі зміни, не лише ті, що компілюються.