Отже, я перебуваю у процесі продажу GIT на роботі. Перше, що мені потрібно, це переконати всіх, що GIT краще в тому, що вони вже звикли робити. В даний час ми використовуємо Perforce. Хтось ще пройшов через подібний продаж? Хороші посилання / поради?
Одним з найбільших виграшів є те, що ми можемо працювати з ним, відключеним від мережі. Ще одним виграшним IMO є спосіб обробки додавання / оформлення замовлення. Вітається більше балів! Також у нас є приблизно 10-20 розробників.
Відповіді:
В даний час вихідний код інтерпретатора Perl 5 переживає перетворення з Perforce на git. Можливо, git-p4rawімпортер Сем Вілена представляє інтерес.
У будь-якому випадку, один із головних виграшів, який ви отримаєте над кожним централізованим VCS, і більшість розподілених також є необробленою швидкістю . Ви не можете собі уявити, наскільки визвольним є мати під рукою всю історію проекту, лише частки частки секунди, поки ви цього не відчуєте. Навіть створення журналу комітів всієї історії проекту, що включає повну різницю для кожного коміту, можна виміряти частками секунди. Git такий швидкий, що твій капелюх полетить. VCS, яким доводиться здійснювати перельоти через мережу, просто не має жодних шансів конкурувати, навіть по гігабітній лінії Ethernet.
Крім того, git дозволяє дуже легко бути ретельно відбірливим під час здійснення комітів, дозволяючи тим самим розподілити зміни у вашій робочій копії (або навіть у межах одного файлу) по кількох комітах - і в різних гілках, якщо вам це потрібно. Це дозволяє робити ментальні нотатки під час роботи - вам не потрібно так ретельно планувати свою роботу, заздалегідь вирішуючи, який набір змін ви здійсните, і обов’язково відкладаючи щось інше. Ви можете просто вносити будь-які потрібні зміни, коли вони трапляються для вас, і все одно розплутувати їх - майже завжди досить легко - коли настає час зробити коміт. Тут може дуже допомогти схованка.
Я виявив, що разом ці факти змушують мене, природно, робити набагато більше і набагато більш цілеспрямованих комітів, ніж раніше, ніж я використовував git. Це, у свою чергу, не тільки робить вашу історію загалом більш корисною, але особливо корисно для таких інструментів, що додають вартість, таких як git bisect.
Я впевнений, що зараз є більше речей, про які я не можу придумати. Однією з проблем продажу вашої команди на git є те, що багато переваг взаємопов’язані і відтворюють одна одну, як я вже натякнув вище, так що важко просто поглянути на перелік особливостей і переваг git і зробити висновок, як вони збираєтеся змінити ваш робочий процес, і які зміни будуть добросовісними вдосконаленнями. Вам потрібно це врахувати, а також потрібно чітко вказати на це.
Я використовую Perforce на роботі. Я також використовую Git, тому що я все одно хотів би певної форми контролю версій, коли я працюю над кодом і не можу підключитися до сервера. Ні, узгодити роботу в автономному режимі просто не однаково. Ось де я знайшов git як велику користь:
Ну, це мої 2 центи. На захист Виконавця я повинен сказати їх правила підтримки клієнтів, а також їх інструмент "Перегляд часу". Я не знаю, як отримати проміжок часу за допомогою git. Але для зручності та економії часу я б ходив із git будь-який день.
Мені знадобилося б багато переконливого, щоб перейти від виконавця. У двох компаніях, якими я цим користувався, це було більш ніж адекватно. Це були обидві компанії з різними офісами, але офіси були створені з великою кількістю інфраструктури, тому не було необхідності мати роз'єднані / відключені функції.
Скільки розробників ви говорите про перехід?
Справжнє запитання полягає в тому, - що саме таке, що не відповідає потребам вашої організації, може дати git? І так само, які слабкі сторони має git порівняно з perforce? Якщо ви самі не можете відповісти на це, тоді запитання тут не допоможе. Вам потрібно знайти бізнес-кейс для вашої компанії. (наприклад, можливо, це з меншими загальними витратами на володіння (що включає втрату продуктивності на проміжному етапі навчання, вищі адміністративні витрати (принаймні спочатку) тощо)
Я думаю, що вас чекає жорстка продажа - виконавці досить непогані, щоб спробувати їх замінити. Якщо ви намагаєтесь завантажити пвх або ssafe, неважко.
Я думаю, що для того, щоб зробити людей щасливими під час переходу / після переходу, одна з речей, яку потрібно пережити рано, - це те, наскільки приватним може бути місцеве відділення в Git, і скільки свободи дає їм можливість робити помилки. Запропонуйте їм усім клонувати кілька приватних гілок з поточного коду, а потім шалено дивитись там, експериментуючи. Перейменуйте деякі файли, перевірте речі, об’єднайте речі з іншої гілки, перемотайте історію, перебазуйте один набір змін поверх іншого тощо. Покажіть, як навіть найгірші аварії на місцях не мають наслідків для їхніх колег. Вам потрібна ситуація, коли розробники почуваються в безпеці, щоб вони могли вчитися швидше (оскільки Git має круту криву навчання, що важливо), а згодом, щоб вони були ефективнішими як розробники.
Коли ви намагаєтесь вивчити централізований інструмент, ви, очевидно, будете турбуватися про те, щоб зробити якийсь підступ, який спричиняє проблеми для інших користувачів сховища. Одного побоювання збентеження достатньо, щоб відбити людей від експериментів. Навіть наявність спеціального сховища "навчання" не допомагає, оскільки розробники неминуче стикаються з ситуацією в виробничій системі, якої вони ніколи не бачили під час навчання, і тому вони знову хвилюються.
Але розподілена природа Git це позбавляє. Ви можете спробувати будь-який експеримент у місцевій гілці, і якщо це піде жахливо, просто викиньте гілку, і ніхто не повинен цього знати. Оскільки ви можете створити локальну гілку чого завгодно, ви можете повторити проблему, яку ви бачите, із реальним реальним сховищем, але не маєте небезпеки "зламати збірку" або іншим чином обдурити себе. Ви можете перевірити абсолютно все, як тільки ви це зробите, не намагаючись групувати роботу в акуратні маленькі пакунки. Отже, не лише дві основні зміни коду, на які ви витратили сьогодні чотири години, але й те виправлення збірки, яке ви запам’ятали наполовину, і орфографічну помилку в документації, яку ви помітили, коли щось пояснювали колезі тощо. І якщо від основних змін відмовляться, оскільки проект змінює напрямок,
Команда, яка продала мене особисто на git, була навпіл . Я не думаю, що на сьогодні ця функція доступна в будь-якій іншій системі контролю версій.
Сказано, якщо люди звикли до клієнтського графічного інтерфейсу для контролю джерел, вони не будуть вражені git. Зараз єдиним повнофункціональним клієнтом є командний рядок.
git log --graph), оскільки історії ревізій Git мають тенденцію бути нелінійними та важко візуалізувати без зображення. Я використовую GitX і SourceTree в якості графічних інтерфейсів, хоча gitk (який зараз поставляється з Git) є прохідним.
Які функції Perforce використовують люди?
Я запитую, тому що якщо всі люди роблять це отримати і поставити з командного рядка, git це охоплює, як і всі інші RTS.
Очевидно, GitHub зараз пропонує компаніям навчальні курси по git . Цитували їхню публікацію в блозі про це :
За останні кілька тижнів я неодноразово відвідував кампус Google, допомагаючи тренувати Android там, у Git. Мене попросив Шон Пірс (ви можете знати його за його славою Git та EGit / JGit - він герой, який бере на себе підтримку, коли Хуніо не в місті), щоб я допоміг йому навчити інженерів Google, які працюють над Андріодом в процесі переходу від Perforce до Git , щоб Android міг ділитися з масами. Я можу сказати вам, що я був більш ніж радий це зробити.
[…]
Logical Awesome зараз офіційно пропонує такий тип спеціальних навчальних послуг для всіх компаній, де ми можемо допомогти вашій організації в навчанні та плануванні, якщо ви також хочете перейти на Git.
Акцент мій.
Я використовую Perforce вже давно, а нещодавно я також почав використовувати GIT. Ось моя "об'єктивна" думка:
Виконати особливості:
Особливості GIT:
Загалом для проектів OpenSource / Distributed я завжди рекомендував би GIT, оскільки це більше схоже на додаток P2P, і кожен може брати участь у розробці. Наприклад, я пам’ятаю, що коли я робив віддалену розробку з Perforce, я синхронізував проекти на 4 Гб за посиланням 1 Мбіт / с раз на тиждень. Через це просто витратили багато часу. Також для цього нам потрібно було налаштувати VPN.
Якщо у вас невелика компанія, і сервер P4 завжди буде працювати, то я б сказав, що Perforce - це також дуже хороший варіант.
Ми використовували Git деякий час, нещодавно жорсткий диск нашого сервера Git вийшов з ладу, і ми не змогли повернутися до останнього стану. Нам вдалося повернутися до декількох днів старого штату. Коли сервер було створено резервну копію. Усі в команді витягували / проштовхували свої зміни і вуаля, сервер повернувся до поточного стану.
Важливою відмінністю Perforce від git (і тієї, що найчастіше згадується) є їх відповідна обробка величезних двійкових файлів.
Як, наприклад, у цьому блозі співробітника компанії з розробки відеоігор: http://corearchitecture.blogspot.com/2011/09/git-vs-perforce-from-game-development.html
Однак важливим є те, що різниця в швидкості між git і perforce, коли у вас величезне сховище 6 Гб, що містить все, від документації до кожного коли-небудь побудованого двійкового файлу (і нарешті, о так! Фактична історія джерел), як правило, походить від Справа в тому, що величезні компанії, як правило, запускають Perforce, і тому вони налаштовують його, щоб вивантажити всі важливі операції до величезного серверного банку в підвалі.
Ця важлива перевага з боку Perforce походить лише від фактора, який не має нічого спільного з Perforce, від того, що компанія, що керує ним, може дозволити собі зазначений серверний банк.
І, як би там не було, зрештою, Perforce та git - це різні продукти. Git був розроблений виключно як VCS, і це робиться набагато краще, ніж Perforce (тим, що він має більше можливостей, які, як правило, простіші у використанні, зокрема, за висловом іншого, розгалуження у Perforce схоже на виконання відкритих сердець хірургічне втручання, це повинні робити лише фахівці: P) ( http://stevehanov.ca/blog/index.php?id=50 )
Будь-які інші переваги, які отримують компанії, які використовують Perforce, приходять лише тому, що Perforce не є лише VCS, він також є файловим сервером, а також має безліч інших функцій для тестування продуктивності збірок тощо.
Нарешті: Git, будучи відкритим вихідним кодом і набагато гнучкішим для завантаження, не буде настільки складно виправити git, щоб вивантажити важливі операції на центральний сервер, працюючи безліч дорогого обладнання.
Я думаю, що одна річ, на яку я знаю, що GIT виграє - це здатність "зберігати закінчення рядків" у всіх файлах, тоді як perforce, схоже, наполягає на перекладі їх у формат Unix, Dos / Windows або MacOS9 ("\ n", "\ r \ n "або" \ r).
Це справжній біль, якщо ви пишете скрипти Unix у середовищі Windows або змішаному середовищі ОС. Навіть неможливо встановити правило на основі розширення файлу. Наприклад, він перетворить файли .sh, .bash, .unix у формат Unix, а файли .ccp, .bat або .com перетворить у формат Dos / Windows.
У GIT (я не впевнений, що це за замовчуванням, варіант чи єдиний варіант) ви можете налаштувати його на "збереження закінчень рядків". Це означає, що ви можете вручну змінити закінчення рядків файлу, і тоді GIT залишить цей формат таким, яким він є. Мені це здається ідеальним способом робити щось, і я не розумію, чому це не варіант із Perforce.
Єдиний спосіб досягти такої поведінки - це позначити файли як двійкові. Як я бачу, це було б неприємним хаком, щоб обійти відсутні функції. Окрім того, що це буде нудно робити на всіх сценаріях тощо, це також, мабуть, порушить більшість відмінностей тощо.
"Рішенням", з яким ми вирішили на даний момент, є запуск команди sed, щоб видалити всі повернення кареток зі сценаріїв кожного разу, коли вони розгортаються у своєму середовищі Unix. Це теж не ідеально, тим більше, що деякі з них розгортаються всередині файлів WAR, і лінію sed потрібно запускати знову, коли вони розпаковуються.
Це лише те, що, на мою думку, дає GIT велику перевагу, і про що, на мою думку, не згадувалося вище.
РЕДАГУВАТИ: Трохи довше використовуючи Perforce, я хотів би додати ще пару коментарів:
A) Щось, чого я дуже скучаю у Perforce, - це чітке та примірник різниці, включаючи змінені, видалені та додані файли. Це доступно в GIT за допомогою git diffкоманди, але в Perforce файли потрібно перевіряти перед тим, як їх зміни будуть записані, і хоча у вас можуть бути налаштовані ваші основні редактори (наприклад, Eclipse) для автоматичної перевірки файлів під час їх редагування, ви іноді може редагувати файли іншими способами (блокнот, команди unix тощо). А нові файли, здається, взагалі не додаються автоматично, навіть за допомогою Eclipse та p4eclipse, що може досить дратувати. Отже, щоб знайти всі зміни, вам потрібно запустити "Diff against ..." на всій робочій області, яка, перш за все, займає деякий час, а по-друге включає всі види нерелевантних речей, якщо ви не створили дуже складні списки виключень, що веде мене до наступного пункту.
Б) У GIT я вважаю .gitignore дуже простим і простим в управлінні, читанні та розумінні. Однак списки ігнорування / виключення робочої області, що налаштовуються у Perforce, здаються громіздкими та надмірно складними. Я не зміг отримати жодних виключень, коли працюють узагальнюючі символи. Я хотів би зробити щось подібне
-//Server/mainline/.../target/... //Svend_Hansen_Server/.../target/...
Виключити всі цільові папки з усіх проектів на сервері / основній лінії. Однак, схоже, це працює не так, як я очікував, і в підсумку я додав рядок для кожного проекту, наприклад:
-//Server/mainline/projectA/target/... //Svend_Hansen_Server/projectA/target/...
-//Server/mainline/projectB/target/... //Svend_Hansen_Server/projectB/target/...
...
І подібні рядки для папок для сміття, файлів .classpath та .projet тощо.
В) У Perforce є досить корисні списки змін. Однак припустимо, що я вніс групу змін, перевірив їх усі та помістив до списку змін, щоб потім працювати над чимось іншим, перш ніж подавати цей список змін. Якщо пізніше я внесу зміни до одного з файлів, включених до першого списку змін, цей файл все одно буде в цьому списку змін, і я не можу просто пізніше подати список змін, припускаючи, що він містить лише ті зміни, які я спочатку додав (хоча будуть ті самі файли). У GIT, якщо ви додасте файл, і вони внесуть до нього подальші зміни, ці зміни не будуть додані (і все одно відображатимуться вgit diffі ви не зможете скопіювати файл без попереднього додавання нових змін. Звичайно, це не корисно так само, як може бути і список змін, оскільки у вас є лише один набір доданих файлів, але в GIT ви можете просто зафіксувати зміни, оскільки це насправді їх не штовхає. Ви могли б їм працювати над іншими змінами, перш ніж натискати їх, але ви не змогли б натиснути ні на що інше, що ви додасте пізніше, не натискаючи на попередні зміни.
Я не маю досвіду роботи з Git, але маю досвід роботи з Mercurial, який також є розподіленою VCS. Це дійсно залежить від проекту, але в нашому випадку розподілена система VCS підходить для проекту, оскільки в основному усуває часті непрацюючі збірки.
Думаю, це залежить від проекту насправді, оскільки деякі більше підходять для VCS клієнт-сервер, а інші наводять розподілений.
Ось що мені не подобається у git:
Перш за все, я думаю, що розподілена ідея летить перед реальністю. Кожен, хто насправді використовує git, робить це централізовано, навіть Лінус Торвальдс. Якби ядро управлялося розподіленим способом, це означало б, що я фактично не міг завантажити "офіційні" джерела ядра - їх не було б - мені довелося б вирішити, чи хочу я версію Лінуса чи версію Джо, або версія Білла. Це, очевидно, було б смішно, і тому існує офіційне визначення, яке Linus контролює за допомогою централізованого робочого процесу.
Якщо ви визнаєте, що хочете централізоване визначення ваших матеріалів, тоді стає зрозумілим, що роль сервера та клієнта абсолютно різні, тому догма про те, що програмне забезпечення клієнта та сервера має бути однаковим, стає суто обмежувальною. Догма про те , що клієнт і сервер дані повинні бути таким же , стає очевидно смішно, особливо в кодовому , що отримало п'ятнадцять років історії , що ніхто НЕ піклується про , але все б клон.
Те, що ми насправді хочемо зробити зі всіма цими старими речами, засипаємо їх у шафу і забуваємо, що вони там, як і будь-який звичайний VCS. Той факт, що git щодня перетягує все це туди-сюди по мережі, дуже небезпечний, тому що це дратує вас, щоб його обрізати. Ця обрізка передбачає багато нудних рішень, і це може піти не так. Отже, люди, мабуть, зберігатимуть цілу серію знімків з різних моментів історії, але чи не для цього був призначений контроль над джерелами? Ця проблема не існувала, поки хтось не винайшов розподілену модель.
Git активно заохочує людей переписувати історію, і вищесказане, мабуть, одна з причин цього. Кожен звичайний VCS робить переписування історії неможливою для всіх, крім адміністраторів, і переконує, що у адміністраторів немає підстав розглядати її. Виправте мене, якщо я помиляюся, але, наскільки мені відомо, git не надає жодного способу надати звичайним користувачам доступ до запису, але забороняє їм переписувати історію. Це означає, що будь-який розробник із незадоволенням (або який все ще бореться з кривою навчання) може зіткнути всю кодову базу. Як нам затягнути цю? Ну, або ви регулярно створюєте резервні копії всієї історії, тобто ви тримаєте історію в квадраті, або ви забороняєте доступ до записів усім, крім деяких бідних дернів, які отримували б всі різниці по електронній пошті та зливали їх вручну.
Давайте візьмемо приклад добре фінансуваного великого проекту і подивимось, як git працює для них: Android. Одного разу я вирішив пограти з самою системою android. Я дізнався, що мав використовувати купу сценаріїв, що називаються repo, щоб дістатись їх git. Деякі з репо виконуються на клієнті, а деякі - на сервері, але обидва самі по собі ілюструють той факт, що git є неповним у будь-якій якості. Сталося так, що я не міг дістати джерела близько тижня, а потім взагалі відмовився. Мені довелося б отримати справді величезну кількість даних з декількох різних сховищ, але сервер був повністю перевантажений такими людьми, як я. Час очікування репо закінчувався, і він не зміг відновити роботу з того місця, де він закінчився. Якщо git настільки розповсюджуваний, ви могли б подумати, що вони я зробив якусь рівну рівну річ, щоб зняти навантаження на цьому одному сервері. Git можна розповсюджувати, але це не сервер. Git + repo - це сервер, але репо не розповсюджується, тому що це лише спеціальна колекція хаків.
Подібною ілюстрацією неадекватності git є гітоліт (і його предок, який, мабуть, працював не так добре.) Gitolite описує свою роботу як полегшення розгортання git-сервера. Знову ж таки, саме існування цієї речі доводить, що git - це не сервер, не більше, ніж клієнт. Більше того, це ніколи не буде, бо якби воно переросло в будь-яке, воно б зрадило своїм основним принципам.
Навіть якби ти вірив у розподілену річ, git все одно був би хаосом. Наприклад, що таке філія? Вони кажуть, що ви неявно робите гілку кожного разу, коли клонуєте сховище, але це не може бути таким самим, як гілка в одному сховищі. Отже, це принаймні дві різні речі, які називаються філіями. Але потім ви також можете перемотати репо і просто розпочати редагування. Це як другий тип гілок, чи знову щось інше? Можливо, це залежить від того, який тип репо у вас є - о так - мабуть, репо - це не дуже чітка концепція. Є нормальні і голі. Ви не можете натиснути на звичайний, оскільки гола частина може вийти з синхронізації з деревом джерела. Але не можна cvsimport до голого, тому що вони не думали про це. Отже, вам потрібно cvsimport до нормального, клонувати це до оголеного, який вдарили розробники, і cvsexport - до робочої копії cvs, яку ще потрібно перевірити на cvs. Кому можна заважати? Звідки взялися всі ці ускладнення? З самої розподіленої ідеї. Зрештою я кинув гітоліт, тому що він накладав на мене ще більше цих обмежень.
Git каже, що розгалуження має бути легким, але багато компаній вже мають серйозну проблему неправдивих філій, тому я б подумав, що розгалуження має бути важливим рішенням із суворим контролем. Тут виконавці дійсно сяють ...
У perforce вам рідко потрібні гілки, оскільки ви можете дуже гнучко жонглювати наборами змін. Наприклад, звичайний робочий процес полягає в тому, що ви синхронізуєтесь з останньою відомою доброю версією на головній лінії, а потім пишете свою функцію. Щоразу, коли ви намагаєтесь змінити файл, різниця цього файлу додається до "набору змін за замовчуванням". Коли ви намагаєтеся перевірити набір змін, він автоматично намагається об'єднати новини з основної лінії у ваш набір змін (ефективно перебазуючи їх), а потім фіксує. Цей робочий процес застосовується, навіть якщо вам не потрібно його розуміти. Таким чином, Mainline збирає історію змін, які ви зможете легко вибирати пізніше. Наприклад, припустимо, ви хочете повернути старий, скажімо, той, що був попереднім. Ви синхронізуєтесь із моментом до зміни, що позначається, позначте файли, що зазнали впливу, як частину набору змін, синхронізувати з моментом після і об’єднати з "завжди моїм". (Там було щось дуже цікаве: синхронізація не означає мати те саме - якщо файл можна редагувати (тобто в активному наборі змін), він не буде заблокований синхронізацією, але позначений як належний для вирішення.) Тепер у вас є список змін, який скасовує правопорушник. Об’єднайте наступні новини, і у вас буде список змін, який ви зможете прокласти поверх основної лінії, щоб отримати бажаний ефект. Жодного разу ми не переписували жодної історії. Об’єднайте наступні новини, і у вас буде список змін, який ви зможете прокласти поверх основної лінії, щоб отримати бажаний ефект. Жодного разу ми не переписували жодної історії. Об’єднайте наступні новини, і у вас буде список змін, який ви зможете прокласти поверх основної лінії, щоб отримати бажаний ефект. Жодного разу ми не переписували жодної історії.
Тепер, припустимо, що на половині цього процесу хтось підбігає до вас і каже вам кинути все і виправити якусь помилку. Ви просто надаєте списку змін за замовчуванням ім'я (фактично число), а потім "призупиняєте" його, виправляєте помилку в пустому списку змін за замовчуванням, фіксуєте його та поновлюєте названий список змін. Типово, що одночасно призупиняється кілька списків змін, коли ви пробуєте різні речі. Це просто та приватно. Ви отримуєте те, що ви дійсно хочете від режиму відділення, без спокуси зволікати чи куряти від злиття на основну лінію.
Я припускаю, що теоретично було б можливо зробити щось подібне в git, але git робить практично все можливе, а не затверджувати схвалений робочий процес. Централізована модель - це сукупність дійсних спрощень щодо розподіленої моделі, яка є недійсним узагальненням. Він настільки узагальнений, що в основному очікує від вас, що ви реалізуєте контроль над джерелом поверх нього, як це робить репо.
Інша справа - реплікація. У git все можливо, тому вам доведеться розібратися в цьому самі. Працюючи, ви отримуєте ефективно кеш-пам’ять без громадянства. Єдина конфігурація, яку йому потрібно знати, - це де знаходиться ведучий, і клієнти можуть на свій розсуд вказувати на головний або кеш. Це п’ятихвилинна робота, і вона не може піти не так.
У вас також є тригери та настроювані форми для затвердження оглядів коду, посилань на bugzilla тощо, і звичайно, у вас є гілки, коли вони вам дійсно потрібні. Це не чітко, але це близько, і його просто встановити та обслуговувати.
Загалом, я думаю, що якщо ви знаєте, що будете працювати централізовано, як це роблять усі, ви можете скористатися інструментом, розробленим з урахуванням цього. Git переоцінений через жахливу дотепність Лінуса разом зі схильністю людей йти один за одним навколо, як вівці, але його основний сенс існування насправді не витримує здорового глузду, і, слідуючи йому, git пов'язує власні руки з дві величезні догми про те, що (а) програмне забезпечення та (б) дані повинні бути однаковими як для клієнта, так і для сервера, і це завжди буде ускладнювати та кульгати при централізованій роботі.
Поширеним є використання GIT як замінника управління невдалим рядком коду. Багато недоліків Perforce є наслідком поганих стратегій розгалуження. Те саме для будь-якого іншого централізованого інструменту. Якщо вам доводиться створювати тонну гілок, ви робите щось не так. Навіщо розробникам потрібно створювати стільки гілок?
Крім того, чому робота в режимі відключення так важлива? Просто щоб хтось міг працювати в поїзді? Це приблизно єдине місце, де сьогодні неможливо отримати бездротове з’єднання. І навіть у більшості поїздів є гідний Wi-Fi.