Чому Git отримав стільки галасу? … А інші ні? [зачинено]

В останні роки ажіотаж навколо Гіта сильно піднявся. Всі знають про Git, ніхто не знає про альтернативи.

Інші, такі як Mercurial, здаються непоміченими. Обидва були випущені в 2005 році і забезпечують аналогічні функції. Більше того, Mercurial, як правило, вважається простішим у використанні, інтуїтивнішим і на тривалий час кращими інтерфейсами користувача. Тому можна припустити, що це буде популярною альтернативою, особливо для тих, хто має розповсюджений контроль над версіями. Тим не менше, більшості людей це здається невідомим, на відміну від Git, який досяг успіху.

Сенс цієї публікації - спробувати зрозуміти це явище краще.

Як Git отримує всю частину торта? Вони якось використовували кращий маркетинг? Це тому, що її спільнота більше ... ах ... "багатослівна"? Це через назву "Лінус"? Це через його примхливий образ?

Яка твоя думка?

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

Для меркуріалу не було такої послуги, коли DVCS став популярним (принаймні жодного, про який я не знав). У вас є Bitbucket зараз і, напевно, інші, але GitHub існує там вже досить давно, він добре відомий, і він стає все кращим і кращим.

Я бачу чимало відповідей на це, які покладаються на почуття, які автор мав, чуючи про ту чи іншу СКМ. Інші кажуть, що все це було чистою долею. Я вірю, що удача простежується в історії.

Я розповім про історію.

Git і Mercurial були створені одночасно для вирішення одного і того ж питання. Ще в ті часи ядро ​​Linux було змушене припинити використання BitKeeper , фірмового розповсюдженого SCM, який він використовував протягом 3 років. Причиною цього стало те, що Ларрі Маквей, генеральний директор BitMover, компанії, що стоїть за BitKeeper, перестав безкоштовно передавати своє програмне забезпечення розробникам Linux, оскільки хтось із спільноти Linux його реінжинірував.

Лінус Торвальдс, незадоволений тим, що вже існував, згодом почав працювати над абсолютно новою SCM, яку незабаром він назвать Git. Незабаром після цього Метт Маккал з подібних причин розпочав проект Меркуріалу.

Через деякий час розробляючи ці проекти окремо, Метт Маккалл представив розширену версію свого SCM і певним чином відзначив його, порівнюючи його з Git (якому було само пару тижнів). Лінус розглядав можливість використовувати його замість Git для розробки Kernel, але відмовився від ідеї, коли зрозумів, що Mercurial використовує набори змін для внесення змін до змін . Він побоювався, що це занадто близько до того, як працював BitKeeper, і він, звичайно, не хотів нічого, що могло б змусити когось сказати: "Вони побудували клон BitKeeper".

Тому Git використовувався для розробки Kernel замість Mercurial, але вони були технічно доречними. Кінцевий результат полягає в тому, що Git почався з того, що він фактично використовувався там, де він був призначений для використання, в той час як Mercurial не був таким швидким, щоб знайти своє перше велике використання FOSS. Оскільки він був наділений дуже гарним дизайном і завдяки наполегливості Метта Макалла, він з часом став відомим і звик до великих проектів у реальному світі.

Сьогодні вони обоє відомі. Хто з них найвідоміший, сказати неможливо. Google Code лише нещодавно інтегрував Git, хоча він був Mercurial протягом тривалого часу. Багато справді великих і відомих проектів використовують будь-який.

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

Bazaar - це ще одна СКМ, яка дуже відома у світі GNU, але не настільки поза її межами, оскільки вона була побудована з метою задоволення громади GNU. Програми часто ходять туди, куди хочуть їх творці, і не далі.

З іншого боку, розподілені СКМ є явними переможцями. Я не бачу там багато широко використовуваних нерозподілених СКМ.

Лінус Торвальдс

Лінус є великим прихильником Git і протягом багатьох років активно просував його до основної групи Linux, і він вирощується звідти. Смію сказати, що це повністю пов'язано з впливом Лінуса на спільноту * nix.

Особисто я все ще використовую Subversion, але це з переваг, а не корисності.

Звичайна больова точка з системою контролю версій - це злиття гілок .

Вам потрібно спробувати це, коли це не працює, щоб зрозуміти, наскільки це може бути болісно і як важливо працювати, щоб вільно працювати з гілками.

Дізнавшись, що Лінус Торвальдс написав git, щоб зробити це правильно, і що нібито в одній ситуації він застосував git, щоб об'єднати дванадцять гілок разом, це дуже переконливий аргумент, щоб git був цікавим.

Я був у ситуації близько року тому, коли мені довелося вибирати між hg і git, і вищезгадане злиття було одним з важливих факторів у виборі git. По-друге, організація Eclipse перейшла на git, тому очікувалося, що інструменти Eclipse будуть хорошими для Java-проектів. З випуском Eclipse 3.7 це сталося. Ми були, мабуть, 6-9 місяців раніше з цього питання.

Для різних потреб hg може бути настільки ж корисним. Sun вибрала його для свого VCS на основі дуже ретельного дослідження. Можливо, ви захочете знайти білі газети і подивитися, якими були їхні міркування.

EDIT: Зауважте, я не кажу, що є щось, що Mercurial не може зробити, саме для Java з Eclipse - що є нашим основним напрямком - ринкові сили в даний час найсильніші для git, навіть під Windows, і нам потрібно стояти на плечах. інших, а не їхні ноги.

Замість того, щоб сказати, чому гито чи меркуріум краще, і сказати, що це єдина його популярність, я збираюся зосередити увагу на громаді.

Як я підкреслював раніше , спільнота Git дуже гучна і зарозуміла. Більшість енергійно захищають свою дорогоцінну програму. Більшу частину війни, яку я бачив у Гїті проти Меркуріалу, розпочали люди, які цікавились, чому всі на Землі не використовують святу. Такі сайти, як whygitisbetterthanx.com, навіть демонструють цю зарозумілість у вступі, який написаний для того, щоб принадити полум'я інших.

Я не кажу, що все так, але більшу частину часу, коли я стикався з людьми з git, про-git веб-сайтами та блогами pro-git, я відчував, що git забивається в горло, а не пропонується як життєздатний DVCS система.

На відміну від інших спільнот DVCS не такі голосні. Я не знав, що Mercurial існує, поки я не побачив "Що найкраще DVCS?" питання про СО. Хоча git з’являється скрізь, інші DVCS знадобиться час, щоб знайти.

Я не думаю, що Mercurial є особливо низьким. Піч побудована на Hg, і вже деякий час є хороша підтримка в таких IDE, як Eclipse & Netbeans.

Більшість розробників, з якими я говорю, віддають перевагу Hg через кращу підтримку Windows. Якби ми були розробниками Linux, це може бути інша історія.

Також вам не вистачає "Базару", який є справжнім "забутим DVCS".

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

Думка скромна, але git може отримати весь цей ажіотаж через два параметри:

1. Це дуже ефективно
2. Це цікаво використовувати (якось дуже специфічним способом для вчених-комп'ютерів)

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

Тут працюють три фактори: "бета-гек-медіа", "час настає" та "слідкуйте за лідером"

Beta Geek Media

Існує ряд каналів, які обговорюють "видовищні дії". Вони, безумовно, висвітлюють появу нової системи управління версіями, але вони охоплюють ще більше. Чому? Тому що Лінус Торвальдс писав це спочатку, сперечався про це публічно і використовував це як рішення своєї широко розрекламованої проблеми з бітмером. Ефективно, щоразу, коли на lkml ведеться вогнева війна, бета-виразні ЗМІ напишуть статтю про це. Дискусія з Git розпочалася з lkml, тому вона отримала більше висвітлення, ніж інші альтернативи. І бета-вундеркінд, який читає Slashdot, начебто Variety, з'їв його. Кінцевим підсумком цього є те, що git має в десять разів більше статей, ніж mercurial.

Час підходить

Великі проекти з відкритим кодом з великою кількістю учасників мають проблеми з централізованим контролем джерел. По мірі того, як відкритий код зростає, а проекти стають більш шансовими мати багато учасників, проблема загострюється. Linux, мабуть, найвідоміший проект, який страждає від цього, але є багато інших. Оскільки багато проектів досягли цього, потрібен був якийсь передовий VCS. Git, Mercurial і Bazaar стали великими переможцями тут. Арка та Монотон були лише занадто рано, і вони пропустили хвилю ажіотажу.

Слідуй за лідером

У великих проектах є послідовники, які регулярно перевіряють і створюють код, навіть якщо вони не роблять внесок. Послідовники ознайомлюються з інструментами, необхідними для отримання проекту, за яким вони слідують, тому ці інструменти отримують більше використання. Давайте подивимось на проекти «великий розіграш» для великих трьох DVCS:

• Git : Linux, Perl, jQuery, Ruby on Rails, Eclipse, Gnome, KDE, QT, X
• Mercurial : Java, Mozilla, Python
• Базар : Ubuntu, Emacs

У Git є більше проектів «великий малюнок», які використовують його, тому більше людей знайомі з git, написано більше навчальних посібників з git.

Це, головним чином, лише посилення шуму. Git - найпопулярніший, тому він отримує найбільшу розголос, що призводить до того, що він стає більш популярним.

Git, Hg і Bzr - всі ідеально хороші системи DVCS, але лякаюча кількість людей порівнюють DVCS з Git, і вважають, що всі прекрасні риси DVCS є унікальними для Git. І тому вони використовують Git і рекомендують Git, і говорять такі речі, як "Git краще, тому що він може робити злиття восьминога" (Так може і Bazaar), або "Git краще, тому що він поширюється" (так це будь-який DVCS, звідси і назва ), або "Git краще, оскільки він робить розгалуження та злиття легким" (знову це стосується кожного DVCS).

На жаль, тому що я вважаю, що альтернативи також можуть запропонувати багато, і я вважаю за краще, щоб люди обрали Git за його унікальні сильні сторони, ніж просто тому, що вони думають, що DVCS == Git.

Коли хтось виявляє, наскільки розумні DVCS, вказуючи на один конкретний DVCS, вони часто не йдуть і кажуть іншим: "Ей, DVCS''s великі, ви повинні їх використовувати", а точніше, "DVCS, що я дізнався про DVCS''s від чудово, ви повинні ним скористатися ".

Гітуб. Github є піонером у соціальному кодуванні. Це перетворило контроль над версіями в соціальну платформу, яка привернула багато уваги, і він, очевидно, просто підтримує Git. Соціальні медіа = більше прийняття. Bitbucket набирає пари, хоча отримує багато нових функцій, що робить його ймовірним конкурентом :)

Насправді, я думаю, що галас стосується всіх DSVCs разом.

Але прихильники git просто більш голосові, часто більш агресивні у своїх коментарях, щоб бути чесними та любити говорити про це скрізь.

Я підозрюю, що Mercurial широко застосовується, звичайно, так само часто, як git, можливо, і більше (Microsoft і інші великі компанії використовують його зараз), але люди, які використовують Mercurial, найчастіше просто хотіли DSVC, щоб вони могли швидко зрозуміти, а не на чому базувати релігію. Таким чином, вони є менш голосовими та більш реактивними у дискусіях, ніж активні, як деякі користувачі git.

Про Bazaar майже не говорять, оскільки лише деякі великі відомі проекти користуються ним, і жодна інша велика компанія, крім Canonical, не знає, що ним користуються. Порівняйте, наприклад, Google (git, mercurial, svn) та великі проекти з відкритим кодом, і ви можете зрозуміти, чому про це насправді не говорять. Fossil - це ще один цікавий для ніші розробників, тому я думаю, що це нормально і добре, щоб їх почули лише ті, хто шукає надані ними функції (наприклад, вбудовані вікі, відстеження випусків та форум).

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

Крім того, Google Code Hosting і SourceForge тепер дозволяють як git, так і mercurial, тому це стає більш конкретним проектом, ніж раніше, коли ви вибрали git через функції GitHub.

Нема справжньої війни, просто цікава різноманітність інструментів.

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

Я дуже часто користувався Bazaar з тих пір, як він був створений для різних речей. Найбільше, що я використав для цього, це проект AllTray, для якого я (на даний момент) єдиний розробник та обслуговуючий персонал. Базар приємний. Це просто працює, воно не заважає мені, і майже ніколи мені не доводиться дивитись на сторінку --help або сторінку людини. Однак, є деякі недоліки в цьому:

1. Багато функціональних можливостей, які, мабуть, повинні бути частиною основної VCS, не є. Такі речі, як здатність виконувати поділ історії, виконувати довгий вихід через пейджер або мати «кольорові» гілки (наприклад, сховища стилю git), поставляються як плагіни.
2. Дуже багато плагінів не є настільки стабільними. Наприклад, функціональність кольорових гілок, здається, не працює добре на сервері (принаймні, я ніколи не змушував її працювати, вона, як правило, помиляється, кажучи, що гілка на даному шляху не існує, коли це прямо там перед вами, і ви можете побачити криваву річ).
3. У ній немає операції "клонування", ви тягнете гілки по одній. Вам потрібно зробити додаткову роботу, якщо ви хочете мати сховище, щоб ви могли ефективно витягувати нові гілки.
4. Для деяких проектів це болісно повільно. Спробуйте коли-небудь "bzr branch lp: mysql".
5. Не вистачає міцної підтримки гачків; ви можете писати плагіни bzr, які забезпечують гачки, але не існує стандартного способу створення довільних сценаріїв гаків на стороні сервера.

Нещодавно я перейшов на git для розвитку AllTray і дуже швидко розглядаю можливість перенесення всіх моїх проектів на git. Існує трохи більше передового часу, витраченого на знайомство з мотузками, але, здається, воно того варте того. Деякі речі, які я помітив:

1. git clone є відносно швидкою операцією і дає вам інформацію про всі гілки, які існують у сховищі, яке ви клонували.
2. Додавання додаткових віддалених сховищ безболісне, і тому ви можете відслідковувати безліч різних сховищ, які мають кілька відділень, якщо бажаєте.
3. Pro Git книга доступна в Інтернеті і в різних форматах, в тому числі для пристроїв читання електронних книг, і це не важко читати.
4. git здається набагато простішим, ніж Bazaar, і для цього вам не потрібно використовувати жоден конкретний API. (Примітка: це і перелом, і зворотний бік.)
5. git має вбудовану бісекцію, і я не можу наголосити на достатній корисності цієї функції.
6. GitHub досить приємний.
7. gitosisСистема також дуже приємно. Я навіть не впевнений, як би хтось реалізував це інше, як плагін на Bazaar, і не можу уявити, що це було б десь поруч настільки ефективно.

Короткий виклад короткого оповідання: я дуже довго використовував bzr, але git швидко доводить свою приголомшливість для мене.

Використовуючи git, ви, як правило, завжди залишаєтеся в тому ж локальному каталозі, коли займаєтесь розробкою, і просто git checkout branchnameперемикаєтесь між гілками (я весь час використовую "легкі" гілки функцій, тому для мене це дуже важлива особливість).

Переглядаючи документацію та підручники Mercurial, здається, що кращим способом боротьби з різними галузями розвитку є створення нових сховищ шляхом клонування. Цей підручник є прикладом.

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

(Я щодня використовую git. У мене мало досвіду роботи з mercurial, я грав з ним і переглянув кілька навчальних посібників)

Я не знаю, скільки таких рангів я бачив за останні кілька тижнів, але всі вони, здається, вважають це фактом того, що Меркуріал та / або Базар об'єктивно кращі за Git. Можливість використання є, як правило, загальною темою. Так, вивчити Git було напрочуд важко після використання CVS та Subversion, але в цей момент я не хотів би торгувати ним будь-яким іншим VCS, якщо це не призвело до чергової зміни парадигми . І вказівка ​​на таблицю особливостей розповість мені про те, наскільки вона гнучка, розширювана, безпечна чи без особливих зусиль . Наприклад, за замовчуванням git-diff використовуються кольори та пейджер. Впевнений, що я можу отримати те саме з diff ... | colordiff | less -Rчи чимсь, але має бути очевидним, чому один перевершує інший.

Справедливо кажучи, я вважаю, що прихильники git vs. mercurial мало в порівнянні з центральними адвокатами git vs. Однак причини легко підсумувати:

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

Що я маю на увазі під контролем версій для програмістів, це те, що програмісти загалом віддають перевагу гнучкості перед простотою навчання. Зрештою, ми готові витрачати роки на вивчення езотеричних мов, щоб мати гнучкість змусити комп’ютери робити те, що не підготовлені. Git надає програмістам можливість користуватися нею, проте вони бажають, за рахунок цього потрібно більше часу, щоб навчитися безпечно використовувати цю гнучкість. Це дозволяє встановлювати обмеження для застосування політики, але не виходить таким чином. Зауважте, я сказав, що легше навчання, а не простота використання . Після того, як ви дізнаєтесь це, git стає таким же простим у використанні, як і будь-який інший VCS, і часто простіший за рахунок збільшення швидкості та особливостей.

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

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

Розробка NetBSD використовує CVS, і це все, що важливо.

У нього є оснащене, більш пікантне ім'я, яке добре піддається каламбурам.

Нещодавно я шукав систему контролю версій для особистих проектів, тому просто спробував купу їх. Я практично неграмотний у командному рядку, і я чув, що хоча графічні інтерфейси доступні, Git справді призначений для використання через командний рядок, що зробило мене трохи не вагаючись. Чесно кажучи, це було смішно легко забрати, і мені це дуже подобається. Документація - це величезний фактор прийняття нової технології, і Git має безліч смішно простої документації, зрозумілої та доступної. Інші альтернативи, такі як SVN та Bazaar, були чудовими, вони просто не зробили це так просто, як Git. Github також є великим фактором, оскільки він став настільки центральним для руху з відкритим кодом на даний момент. Наявність (за іронією) централізованого місця для обміну кодом та проектами - це сам по собі зміна ігор.

Тільки мої 2 ¢ - я вибрав git над альтернативами, оскільки це написано на мові С, а не на мові radtool або на занадто академічній мові високого рівня. Переваги полягають у тому, що це швидко та ефективно та що я можу насправді RTFS, якщо я стикаюся з помилками чи поведінкою, я не можу пояснити. Це також дозволяє використовувати в крихітних середовищах розробки, що не містять гігантських інтерпретаторів / час виконання, тобто я можу безпосередньо витягуватися з git repo і компілювати в таких системах, а не потрібно добирати останнє джерело в іншому місці та rsync.

Можливо, вам буде цікаво прочитати, чому проект GNOME на робочому столі обрав git over hg та bzr, коли він вирішив перейти зі svn через кілька років назад. Звичайно, було багато бурхливих релігійних дискусій, але ця вікі-сторінка GNOME добре підсумовує плюси та мінуси, що стосуються саме цієї громади.

Не кажучи вже про те, що Apple зараз долучилася до того, щоб підключити її до цільової спільноти c, якщо ви нещодавно створили нову програму в Xcode 4, ви б помітили, що вона автоматично запитує, чи хочете ви зробити Git repo.

Дозволений Xcode 4 існує лише кілька місяців, і це не впливає на попередній успіх Gits, але всі ми знаємо, наскільки популярний Apple може зробити речі за короткий проміжок часу.

Я зараз переходжу з hg (печі) на git (github). Я зараз використовував піч близько року. Для мене hg не має недоліків. Я можу зробити все, що повинен. Так це чудово.

Чому я зараз використовую?

Зараз є лише три причини.

1. gitHub пропонує великі суті
2. gitHub пропонує чудові соціальні можливості
3. Проводячи презентації та семінари для розробників, я завжди публікував свої зразки на hg та git. На git у мене приблизно в 10 разів більше відвідувачів, ніж на hg !!

Я думаю, що третій - найважливіший.

Торстен

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