Чим вас дратує GitHub?

Привіт, спільното!

Натрапила на цікавий блог Мета Даггана про те, що не так з GitHub, та якою могла бути його нова версія, якщо б її зробили ближчою до щоденної роботи розробників.

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

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

Що розробнику не подобається зараз

  • зворотний зв’язок приходить запізно: перевірки часто запускаються вже після коміту або pull request, а не до відправлення змін;
  • схвалення змін занадто спрощене: «схвалено» або «не схвалено», хоча рев’ю часто має проміжні стани;
  • не кожна дрібна зміна потребує однакового рівня перевірки, особливо якщо автор досвідчений, а ризик низький;
  • послідовні pull request мають бути вбудованою можливістю, а не окремим обхідним рішенням;
  • платформа не повинна бути всім одразу: сховищем коду, задач, дошок, вікі тощо;
  • локальна копія репозиторію могла б містити не лише код, а й задачі, рев’ю та статуси;
  • під час клонування не завжди потрібно тягнути всю історію проєкту — старі дані можна підтягувати за потреби;
  • дії автоматизації мають бути підписані, перевірювані та придатні до локального запуску.

Даггана загалом відштовхують великі монолітні платформи. Йому ближча ідея менших вузлів, які можна запускати окремо та об’єднувати в організацію. Умовно, не величезний GitHub Enterprise, а щось легше, що можна підняти навіть на кількох Raspberry Pi.

«У світі, де GitHub добре справляється зі своєю роботою, я б навіть не намагався про це писати. GitHub використовується за замовчуванням, і розмови з людьми про подолання цього явища зазвичай марна трата часу. Heinz — це кетчуп за замовчуванням, коли я замовляю Coca-Cola, я не хочу Pepsi... має бути дивовижна причина, щоб я не обрав те, що використовують усі. Але ми живемо у світі, де кузня руйнується, а ніхто ще не побудував їй заміну»

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

А що вам наразі найбільше не подобається в GitHub?

👍ПодобаєтьсяСподобалось1
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

щоб все не тягнути є аж дві опції

git clone --depth=1
git clone --filter=tree:0

GitHub навмисно створений так, щоб міліони простих кодерів, які щось роблять, але не хочуть думати про тонкощі задля акуратної і чистої історії, в якій можна було б щось знайти і через 20 років без надмірних зусиль, змогли б працювати в режимі, коли Git спрощений до централізованого засобу ведення коду, тільки з оффлайн-сховищем. І він не один такий: BitBucket, Gitlab йдуть тим же шляхом. Бо інакше «ширнармаси» такого не осилять. Те, що роблять в LKML чи в Gerrit — скрупульозна праця над якістю кожного окремого коміта — для пересічного користувача GitHub це нісенітниця, яка не коштує і цента уваги, йому треба «деліверити».

Але в них всіх додані фішки інтеграції з CI, публікації релізів і пр. — все, що потрібно, щоб «деліверити» «з рельсів в бій». Тому до них і тягнуться.

Мет говорить частково про те ж. По пунктах:

(1) — ну не знаю. Ну да, GitHub запускає тести на будь-який push. Я не знаю, чого Мет пише про «You don’t want the feedback loop after the commit you want it before.», може, у якомусь складнішому випадку?

(2) — дискусія є в обох, але в GH висновок від одної людини і дуже простий.
Дивимось на Gerrit: за замовчуванням оцінки від −2 до +2, можна розширити.

(3) — я взагалі не зрозумів. Здається, через API можна пригорнути автомати.

(4) — stacked PRs це те, що головна фішка в Gerrit, і зроблені вони там суперово. Я не бачив аналогів.

(5) — ну зовнішні тулзи завжди існують, питання в якості інтеграції.

(6) — не впевнений, вони всі громіздкі.

(7) — я не бачив крім Fossil тулзи де б це було, але Fossil це не Git.

(8) — ну може бути. Я погано собі уявляю таку роботу, але треба пробувати.

(9) — не зрозумів, що саме підписуватиметься.

Висновок на зараз: GitHub якийсь... лайнуватий, мʼяко кажучи, але не зовсім зрозуміло, куди іти так, щоб було на схожу кількість користувачів, ніж зараз.

Github це у першу чергу корпоративна привʼязка компаній до Microslop. Окремі розробники можуть обирати те що краще працює, але компанії обирають те з чим їм легше укладати контракти.

Не подобається — є старий добрий SourceForge. Ше є Gitlab. Взагалі можете розгорнути Git де завгодно, на власному сервері чи хостінгу.

платформа не повинна бути всім одразу: сховищем коду, задач, дошок, вікі тощо;

О так, зоопарк інтеграцій, це ж саме те, що потрібно. Це дуже зручно, продуктивно.

локальна копія репозиторію могла б містити не лише код, а й задачі, рев’ю та статуси;

Ага, git репа, значить, має містити у собі все підряд. А от github — не повинна бути усим одразу ©

WhoIsMatDugan?

The website https://matduggan.com/ appears to be a personal website run by a DevOps engineer who has moved from Chicago to Denmark. The site is likely used for professional networking and sharing information related to his career and interests in technology and data centers. 
Треба ще запитати у дізайнерів, чому їм гітхаб не подобаєцца, наприклад, не можна прямо у браузері PSD редагувати...

Дореч, у нього about me не працює matduggan.com/about-me

Підписатись на коментарі