Багато програмістів настільки молоді, що ніколи не знали світу без Git та розробницьких сайтів, побудованих навколо нього, таких як GitHub та GitLab. Вам варто радіти, і то дуже, що Лінус Торвальдс відчув необхідність створити кращу систему контролю версій (VCS).
До цього всі використовували системи управління вихідним кодом (SCM) першого покоління, такі як Revision Control System (RCS), що було… м’яко кажучи, болісно. Потім у 1986 році з’явилася Concurrent Versions System (CVS), а згодом, у 2000 році, – Subversion (SVN). Того ж року з’явився BitKeeper, колись система контролю версій (VCS) з відкритим кодом, який став першим SCM для Linux.
До цього Торвальдс задовольнявся тим, що впорядковував код Linux вручну. Але, як зауважив розробник Ларрі Маквой, до 1999 року Торвальдс був на межі вигорання. Проблема? Проблема була в тому, що самого Торвальдса масштабувати було неможливо. Йому потрібні були правильні інструменти, щоб розподілити навантаження. Маквой вважав, що відповіддю була його власна програма SCM, BitKeeper. Торвальдс не був так упевнений. Він хотів продовжувати робити все так, як робив завжди.
Дилема BitKeeper
Перенесемося в 2003 рік, і це вже інша історія. Ядро Linux 2.4 вийшло із запізненням, великим запізненням, а реліз 2.6 просувався ще повільніше. Тож Торвальдс нарешті перейшов на BitKeeper.
Спочатку все працювало чудово, але ложкою дьогтю завжди було те, що BitKeeper був пропрієтарною програмою. Щоправда, існувала безкоштовна версія BitKeeper, яку можна було використовувати лише з проєктами з відкритим кодом, але вона мала суттєві проблеми.
Як зауважив тоді розробник ядра Linux та редактор Linux Weekly News (LWN) Джонатан Корбет: “Ларрі хотів і рибку з’їсти, і на… сісти. Він справді хотів підтримувати розробку вільного програмного забезпечення — доки це ПЗ не загрожувало його власній бізнес-ніші. … Щоразу, коли BitMover [компанія Маквоя] відчувала загрозу своїй бізнес-моделі,” вона змінювала умови ліцензування “до такої міри, що ліцензія BitKeeper стала відомою в деяких колах як ‘ліцензія «не зли Ларрі»’.
Як прокоментував роками пізніше на Ycombinator Браян Кентрілл, відомий розробник і технічний директор Oxide Computer: “Велика іронія полягає в тому, що Ларрі був одним із найперших прихильників відкриття вихідного коду операційної системи в Sun… Тож, з одного боку, історію BitKeeper у контексті відкритого коду можна вважати майже грецькою трагедією за своїм масштабом”.
У 2005 році Ендрю Тріджелл, розробник ядра Linux, спробував здійснити зворотне проєктування протоколів BitKeeper, щоб створити клієнт BitKeeper з відкритим кодом. Це стало останньою краплею для Маквоя, який згодом припинив підтримку безкоштовної версії BitKeeper.
Однак Торвальдс не вважав справедливим звинувачувати Маквоя у розриві. У дописі до списку розсилки ядра Linux (LKM) він написав: “Не звинувачуйте BitMover, навіть якщо це, ймовірно, буде дуже поширеною реакцією. Ларрі, зокрема, справді намагався все налагодити, але дійшло до того, що я вирішив, що не хочу опинитися в ситуації, коли доводиться склеювати дві частини, які, здавалося, вимагали забагато клею”.
Незалежно від того, хто винен, Linux залишився без SCM. Що робити?
Створення Git
Відповіддю Торвальдса стало створення справжньої альтернативи VCS з відкритим кодом: Git. Всього за 10 днів він розробив робочу версію Git, перший коміт якої було зроблено 7 квітня 2005 року.
Звичайно, він думав про це вже деякий час. Конфлікт із BitKeeper назрівав майже від самого початку. У недавньому інтерв’ю GitHub Торвальдс сказав, що перед ним стояло питання: “Як мені зробити щось, що працює навіть краще, ніж BitKeeper, але робить це не так, як BitKeeper?”
Як тоді сказав Торвальдс, він не хотів змінювати інструменти управління конфігурацією програмного забезпечення; однак у нього не було іншого вибору, крім як відмовитися від BitKeeper і створити власну систему. “Сама назва насправді не має значення. Торвальдс пожартував, що це може бути “випадкова комбінація з трьох літер, яка вимовляється і фактично не використовується жодною поширеною командою Unix. Той факт, що це неправильна вимова слова ‘get’, може бути або не бути релевантним”. Або “дурний. нікчемний і мерзенний. Просто. Обирайте на свій смак зі словника сленгу”. Або “глобальний інформаційний трекер: [якщо] у вас гарний настрій, і він справді працює для вас. Ангели співають, і світло раптом заповнює кімнату”.
Ангели чи ні, але Торвальдс тоді не був упевнений, що Git стане постійною заміною. “Це молодий проєкт, і потрібен час, щоб речі дозріли. Це триватиме роками, якщо припустити, що жодна з інших SCM з відкритим кодом зрештою не виявить себе достатньо спроможною, щоб ми просто вирішили, що Git був хорошим тимчасовим мостом”.
Тривалий вплив
Гадаю, ми всі можемо погодитися, що Git виявився чимось більшим, ніж тимчасовий міст. За останніми підрахунками 6sense, Git займає понад 87% ринку SCM.
Зараз усі думають, що те, що робить Git, є очевидним. Тоді це було не так. Торвальдс сказав: “Те, що ви зараз кажете, що це очевидно, я думаю, тоді це не було очевидним. Я думаю, однією з причин, чому людям було дуже важко використовувати Git, було те, що більшість людей, які починали, не використовуючи Git, мали досвід роботи з чимось на зразок CVS. А я підійшов до мислення Git з точки зору людини, що працює з файловими системами, маючи зневагу і майже ненависть до більшості систем контролю версій, тому я зовсім не був зацікавлений у збереженні статус-кво”. Сьогодні його бачення управління програмним кодом стало тим способом, яким ми майже всі працюємо з кодом.
Досить кумедно, але Торвальдс сказав у 2019 році, що хоча він пишається створенням Linux, те, що робить його “щасливим щодо Git, – це не те, що він захопив світ. Це те, що ми всі маємо сумніви в собі, так? Ми всі думаємо: ‘А чи ми справді чогось варті?’ І одним із сумнівів, які я мав щодо Linux, було те, що це була просто реімплементація Unix, так? Чи можу я дати вам щось, що не є просто кращою версією чогось іншого? Git довів мені, що можу. Мати два проєкти, які наробили багато галасу, означає, що я не ‘поні з одним трюком'”.
Сьогодні майже вся розробка з відкритим кодом використовує Git. Хоча Linux тісно пов’язаний з Git, усі операційні системи тепер підтримують його.
Чому Git став таким успішним?
Децентралізований дизайн Git був революційним на той час. Він дозволив розробникам працювати незалежно та ефективно синхронізувати зміни. Цей підхід трансформував спосіб співпраці команд розробників та розробки проєктів. “Git став практично синонімом контролю версій”, – сказав Скотт Чакон, засновник GitHub, який вважає, що Git змінив хід його життя.
Крім того, як написав на LinkedIn Мохамед Яссер, архітектор програмного забезпечення: “Git — це не просто система контролю версій; це основа довіри. Запис бачення. Простір, де кожна гілка відображає думку, а кожен коміт несе намір”.
Вступаючи у своє третє десятиліття, Git продовжує формувати майбутнє розробки програмного забезпечення. Навіть якщо ви ніколи в житті не написали жодного рядка коду, ви використовували результати роботи, яка контролювалася у програмістському жорні Git.
