Чому всі користуються Git централізовано?

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

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

Але, схоже, кожна компанія використовувала Git централізовано, як і SVN або CVS. На сервері завжди є центральне сховище (як правило, на GitHub), з якого люди витягуються та переходять на нього. Я ніколи не бачив і не чув (за своїм недопустимим досвідом) людей, які використовують Git справді децентралізованим способом, яким він був призначений, тобто підштовхувати та перетягувати до інших сховищ колег, як вважав за потрібне.

Мої запитання:

1. Чому люди не використовують розподілений робочий процес для Git на практиці?
2. Чи здатність до розповсюдженої роботи навіть важлива для сучасного контролю версій, чи це просто добре звучить?

Редагувати

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

Ааа, але насправді ви які з допомогою мерзотника децентралізовано!

Порівняймо попередника git у mindshare, svn. Субверсія мала лише одне "репо", одне джерело істини. Коли ви взяли на себе зобов’язання, це було до єдиного центрального репо, до якого береться і кожен інший розробник.

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

Тоді виникає ціла проблема "невдачі" та супутні проблеми, які це приносить. Якщо ваш центральний svn repo помирає якось, ви все закрутили до тих пір, поки його не вдасться відновити з резервного копіювання, і якщо не було резервних копій, ви все подвійно накрутили. Але якщо "центральний" git repo гине, ви можете відновити його із резервної копії чи навіть з однієї з інших копій репо, які знаходяться на сервері CI, робочих станціях розробників тощо. Це можна зробити саме тому, що вони поширюються, і кожен розробник має першокласну копію репо.

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

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

Коли збірка сервер (ви які використовуєте CI, правильно?) Створює збірку, де це витягнути з? Звичайно, для інтеграційної побудови, яку ви можете стверджувати, не потрібна "одна справжня репо", але, безумовно, розробка дистрибутива (тобто те, що ви надаєте замовнику).

Іншими словами: фрагментація. Якщо ви призначите одне репо як "репо" та призначте опікунів, які ветеринарно проводять запити, у вас є простий спосіб задовольнити запит "дайте мені складання програмного забезпечення" або "я новачок у команді, де код?"

Міцність DVCS полягає не стільки в його одноранговому аспекті, скільки в тому, що він є ієрархічним . Я змінюю свою робочу область, після чого я зобов'язуюся до локальної. Після того, як у мене функція завершена, я зливаю свої комітети і відсуваю їх до пульта. Тоді будь-хто може побачити мій попередній код, надати зворотний зв'язок тощо перед тим, як створити запит на виклик, і адміністратор проекту об'єднає його в репо-версію One True.

З традиційними CVCS ви або скористаєтесь, або не зробите. Це добре для деяких робочих процесів (я використовую обидва типи VCS для різних проектів), але він стає рівним на обличчі для загальнодоступних проектів або проектів OSS. Ключовим моментом є те, що DVCS має кілька кроків, які є більшою роботою, але забезпечують кращий спосіб інтеграції коду від сторонніх людей за допомогою вбудованого процесу, який дозволяє покращити видимість у те, що перевіряється. Використовуючи його централізовано, це означає, що ви все ще можете мати цей золотий стандарт поточного стану проекту, забезпечуючи також кращий механізм спільного використання коду.

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

Але 90% + часу, звичайно, ми переходимо через центральний репо. Коли мені не байдужа якась зміна чи робота конкретного колеги, це зручніше, і це масштабується краще, щоб витягнути "всі зміни моїх колег, перевірені в центральному репо", а не окремо тягнути зміни від кожного з N колеги. DVCS не намагається запобігти тому, щоб "тягнути з основного репо" найпоширенішим робочим процесом, намагається запобігти тому, щоб він був єдиним доступним робочим процесом.

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

Якщо «дійсно децентралізовані» означає «ні спеціальних репо» , то я не думаю , що це те , що Лінус значить чемпіон, враховуючи , що в дійсності він робить підтримувати спеціальні операції РЕПО , які є більш важливими у великій схемі речей, ніж якийсь випадковий клон Linux, який я зробив вчора і планую використовувати лише для розробки невеликого патча, а потім видалити його, як тільки він прийняв патч. gitне привілейований його репо над моїм, але Лінус робить привілей. Його "поточний стан Linux", моє - ні. Тому природно зміни мають тенденціюпройти через Лінус. Сила DVCS над централізованою системою VCS полягає не в тому, що не повинно бути фактичного центру, це те, що зміни не повинні проходити через будь-який центр, оскільки (конфлікти, що дозволяють), кожен може злити що завгодно.

Системи DVCS також змушені , оскільки вони децентралізовані, надавати певні зручні функції, засновані на тому, що ви обов'язково повинні мати повну історію (тобто репо) на місцях, щоб зробити що-небудь. Але якщо ви задумаєтесь про це, немає жодної принципової причини, чому ви не змогли б налаштувати централізований VCS з локальним кешем, який зберігає всю історію для операцій лише для читання, дозволених застарітими (я думаю, Perforce має можливість для цього режиму, але я ніколи не використовував Perforce). Або в принципі ви могли налаштувати gitсвій.git/каталог у віддаленій монтованій файловій системі, щоб імітувати "особливість" SVN, що вона не працює, якщо у вас немає мережевого з'єднання. Насправді, DVCS змушує сантехніку бути більш надійною, ніж можна дістатись у централізованому ДКС. Це (дуже вітається) побічний ефект і допомогло мотивувати дизайн DVCS, але такий розподіл відповідальності на технічному рівні не такий, як повністю децентралізація всієї відповідальності людини .

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

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

• Має дуже невеликий список основних розробників, які надають доступ до "центрального" репо для кожної мікросервіси. Всі інші можуть працювати з виделок та подавати їх через запити на тягу.
• Можна здійснювати набагато частіше, як правило, кілька разів на годину проти одного чи двох разів на день.
• Ви можете створити гілки з будь-якої причини, щоб тимчасово погодитись із колегами, і натиснути на неї та витягнути з неї кілька разів на день, а потім розчавити, коли готовий поділитися з більшою групою. Чи маєте ви уявлення про те, як важко отримати дозвіл на створення тимчасової гілки для чогось подібного в традиційному CVCS?

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

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

Проект військового моделювання, над яким працювала моя команда кілька років тому. Весь код (ми говоримо про кодову базу з 1 млрд доларів США) повинен був (згідно із законом / міжнародною угодою, чоловіки в темних костюмах приходять, якщо цього не робити), бути на машинах, фізично ізольованих від будь-якого інтернет-з'єднання . Це означало звичайну ситуацію, коли у нас було 2 ПК, один для запису / запуску / тестування коду, інший для речей Google, перевірка електронної пошти тощо. І в команді цих машин була локальна мережа, очевидно, жодним чином не підключена до Інтернету.

"Центральним джерелом істини" була машина на армійській базі, у підземному приміщенні без вікон (підсилений будинок, яда-яда). Ця машина також не мала підключення до Інтернету.

Періодично було б чиєюсь роботою транспортувати (фізично) привід з git repo (що містить усі наші зміни коду) до армійської бази - яка була за кілька сотень кілометрів, тож ви можете собі уявити.

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

Крім того, якщо ви розглядаєте щось у масштабі ядра Linux ... Розробники не просто надсилають запит на тягнення до самого Linus. По суті це ієрархія репо - кожне з яких було / є «центральним» для когось / якоїсь команди.

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

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

Розподілений аспект DVCS весь час відображається у розробці з відкритим кодом у формі розгортання. Наприклад, деякі проекти, до яких я сприяю, були кинуті оригінальним автором, і тепер є купа вилок, де інженери, які інколи перетягують конкретні риси один від одного. Навіть в цілому проекти OSS беруть внесок за допомогою виклику, а не шляхом надання випадковим людям доступу до репо-реального принципу.

Це не дуже поширений випадок використання при будівництві конкретного продукту з конкретним офіційним випуском, але у світі F / OSS це норма, не виняток.

Чому всі користуються git централізовано?

Ми ніколи не зустрічалися, як це ви кажете всім? ;)

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

Звичайно, багато людей можуть використовувати його централізовано, як CVS або SVN. Але не забувайте про іншу функцію, яка по суті поставляється з розподіленим VCS: всі копії більш-менш "повні" (усі гілки та повна історія доступна), і всі гілки можна перевірити, не підключаючись до сервера.

Я думаю, це ще одна особливість, яку не слід забувати.

Хоча ви не в змозі зробити це за допомогою CVS і SVN, Git можна без проблем використовувати централізовано, як і попередні.

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

Інші функції, які виходять з коробки з Git:

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

Також дивіться ці три таблиці у Вікіпедії - Порівняння програмного забезпечення для управління версіями :

• Особливості

• Основні команди

• Розширені команди

Отже, знову ж таки, можливо, децентралізована манера не є єдиною особливістю, завдяки якій люди користуються нею.

1. Чому люди не використовують розподілений робочий процес для Git на практиці?

Кожен, хто сприяє або розміщує більш масштабний проект на Bitbucked, GitHub тощо, зробить це явно. Обслуговувачі зберігають "основне" сховище, дописувач клонується, здійснює і потім надсилає запит на виклик.

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

2. Чи здатність роботи в розподіленому вигляді навіть важлива для сучасного контролю версій, ...

Як завжди: це залежить від вимог.

Використовуйте децентралізований VCS, якщо застосовується будь-яка точка:

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

Є ще кілька, але чотирьох має бути достатньо.

... чи це просто звучить приємно?

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

Гнучкість - це прокляття, а також благо. І як Git є надзвичайно гнучким, це майже завжди далеко надто гнучким для типової ситуації. Зокрема, більшість проектів Git - це не Linux.

Як результат, розумним вибором є усунення частини цієї теоретичної гнучкості при впровадженні Git. Теоретично сховища можуть формувати будь-який графік, на практиці звичайним вибором є дерево. Ясні переваги ми бачимо за допомогою теорії графів: у дереві репозиторіїв будь-які два сховища поділяють рівно одного предка. У випадковому графіку ідея предка навіть не існує!

Однак ваш клієнт git майже напевно за замовчуванням застосовує модель "єдиного предка". А графіки, у яких вузли мають єдиного предка (крім кореневого вузла) - це саме дерева. Таким чином, ваш клієнт git сам за замовчуванням відповідає моделі дерева, а отже, централізованим сховищам.

Бізнес-логіка винагороджує централізований сервер. Для майже всіх реалістичних бізнес-сценаріїв централізований сервер є основною особливістю робочого процесу.

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

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

Для того, щоб колега витягнути з git repo на моїй машині, це означає, що мені потрібно мати демон git, що працює на рівні кореня, як фонове завдання. Мені дуже цікаво демон, що працює на власному комп’ютері або на ноутбуці, який надає компанія. Найпростіше рішення - "НІ"! Щоб колега витягнути з git repo на моїй машині, це також означає, що моя адреса в Інтернеті повинна бути виправлена. Я подорожую, працюю вдома, а інколи працюю в офісі.

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

З третьої сторони, моє місцеве git repo - це повнофункціональне сховище. Я можу розпочати нову роботу, створити нову гілку для експериментальних робіт і повернути роботу, коли я роблю безлад, навіть коли я працюю в літаку, що летить на відстані 30 000 футів посеред нікуди. Спробуйте це зробити з централізованою системою управління версіями.

Складність:

Для центрального сховища може бути типовий робочий потік

branch off from the central master branch
change the code
test
possibly go back to changing the code
commit
merge any new changes from the central master branch
test
possibly go back to changing the code
merge changes into the central master branch and push

Складність щодо кількості розробників в O (1).

Якщо натомість у кожного розробника є своя власна гілка, для розробника 0:

branch off from master branch 0
merge from master branch 1
...
merge from master branch N-1
change the code
test
possibly go back to changing the code
commit
merge any changes from master branch 0
merge any changes from master branch 1
...
merge any changes from master branch N-1
test
possibly go back to changing the code
merge changes into master branch 0

Підхід однорангових - O (N).

Консистенція:

Тепер подумайте, чи існує конфлікт між об'єднанням між головним відділенням Аліси та головним відділенням Боба. Кожен з N розробників міг вирішити конфлікт по-різному. Результат: хаос. Існують способи досягнення можливої ​​узгодженості, але поки це не відбудеться, всілякий час розробника можна витратити даремно.

Простий:

Компанії - це централізовані організації, що мають централізований робочий процес.

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

GIT пропонує функції, які корисні компаніям (наприклад, витягнути запити на перегляд коду) і лише вони змушують їх перейти на GIT. Децентралізована частина - це просто функція, яка їм не потрібна - тому вони ігнорують її.

Щоб відповісти на ваше запитання: Розподілена частина справді перевершує розподілене середовище, наприклад, з відкритим кодом. Результати залежать від того, хто говорить. Лінус Торвальдс - це не зовсім твій щур в кабіні, тому для нього важливі різні особливості GIT, ніж для твоєї компанії, орієнтованої на github.

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

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

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

Можливо, це тому, що база даних про помилки централізована і повинна зберігатися в синхронізації з кодом .

Бути централізованим - це здорово, доки не виникне проблема… ..

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

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

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