Зроблено в МТІ: система контролю версій Gitless


Всі ви знаєте систему Git. Хоча б чули — це напевно. Розробники, які користуються системою, її або люблять, або лають за складний інтерфейс і баги. Система контролю версій Git де-факто є стандартом в індустрії. У розробника можуть бути думки про переваги Mercurial, але найчастіше доводиться миритися з вимогою вміти користуватися Git. Як у будь-якої складної системи, у неї безліч корисних і необхідних функцій. Однак, до геніальної простоти добираються не всі, тому існуюча реалізація залишала простір для вдосконалення.

Простими словами — хитромудрою додатком було важко користуватися. Тому в лабораторії Массачусетського Технологічного Інституту взялися за поліпшення і відтяли всі «проблемні» (адже те, що для одного проблема, для іншого легко може перевагою). Поліпшену і спрощену версію назвали Gitless. Її розробляли з урахуванням 2400 питань, пов'язаних з Git і взятих з сайту розробників StackOverflow.

Команда авторів вичленувала найбільш проблемні місця в Git, включаючи дві концепції staging і накопичення. Потім вони запропонували зміни, покликані вирішити відомі проблеми.

не так з Git
Багато користувачі скаржилися, що Git потребує в новому інтерфейсі. Фахівці навіть склали документ Що не так з Git? Концептуальний аналіз дизайну. Автори: S. Perez De Rosso і D. Jackson.

Приклад
git checkout < file > // відкинути всі зміни в одному файлі з останньої вивантаження в систему
git reset --hard // відкинути всі зміни у всіх файлах з останньої вивантаження в систему

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

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

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

Функція накопичення ховає чорнову роботу в робочому каталозі — записані файли, які були змінені і зберігає все в стек з незавершеними змінами. Всі зміни можна застосувати пізніше, коли буде зручно. Це потрібно, коли ви працюєте в одній гілці і в ній все в безладному стані, а потрібно терміново переключитися на іншу гілку. Ви не хочете вивантажувати код з частково зробленою роботою в першій гілці на час паузи.

Функція staging індексує зміни, внесені в файл. Якщо ви помітили файли staged, Git розуміє, що ви підготували їх до вивантаження.

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

Автор посібника Gitless повідомляє, що проблема з'являється при перемиканні між гілками. Може бути складно запам'ятовувати який з stashes де знаходиться. Ну і вершиною всього цього стало те, що функція не допомагає в разі коли ви в процесі мерджа, що включає в себе конфліктні файли. Така думка Переза де Россо.

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

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



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



Розгалуження процесів розробки
Основна, необхідна для розуміння нової версії, ідея: гілки в Gitless стали абсолютно незалежними лініями розробки. Кожна з них залишається при своїй робочою версією файлів окремо від інших. Перетинань і проблем немає. В який момент ви б не переключалися на іншу гілку, вміст вашого робочої області зберігається та файли, які мають відношення до гілки призначення, відновлюються. Класифікація файлів також зберігається. Якщо файл класифікований по-різному в двох окремих гілках, то Gitless буде враховувати це.



Простіше кажучи, у версії Gitless вам не потрібно пам'ятати про незавантажених в систему зміни, які перебувають у конфлікті із змінами в гілці призначення.



Також ви зможете відкласти вирішення конфліктної ситуації, якщо у вас середина мержда або fuse. Конфлікт залишиться поки ви не переключиться назад.



Робота з віддаленими репозиторіями
Ось синхронізація з іншими репозиторіями відбувається в обох програмах однаково.



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

Керівництво по роботі з Gitless ви можете переглянути на офіційному сайті програми. В документації описано наступне: як створювати репозиторій, зберігати зміни; як працювати з гілками; як користуватися тегами, працювати з віддаленими репозиторіями.

у підсумку
Вийшло додаток, яке зберігає функціонал Git, але в той же час став більш простим у вивченні і використанні командами розробки. Насправді і до Gitless вже були спроби поліпшити Git. Але за словами Філіпа Гуо (він асистент професора когнітивної науки в Каліфорнійському університеті Сан-Дієго) ця версія вперше досягла цілей щодо перетворення інтерфейсу і дійсному рішенням голо проблем.

Проект використовував строгі методи по створенню програмного забезпечення. Це необхідно для виокремлення недоліків в одному з найбільш широко застосовуваних у всьому світі програмних проектів. У минулому безліч користувачів приводили смішні аргументи як за, так і проти Git, але всі вони не грунтуються на науковому підході.
На прикладі Gitless стає очевидно, що підхід спрощення можливо застосовувати і до інших складних систем. Наприклад, Google Inbox і Dropbox.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.