Я шукав і не міг знайти жодних ділових причин, чому системи git / mercurial / bazzr є кращими, ніж централізовані системи (підривна робота, виконання).

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

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

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

Хм, будучи менеджером, у мене є дві негайні реакції на це:

• Якщо ви ще не маєте вагомих причин, чому ви ганяєте про інше, ніж бути в тренді?
• Так само, як Subversion виходить з ладу, що вам потрібна заміна?

Я насправді не є негативним - я думаю, що, мабуть, має бути зроблений випадок (залежно від обставин), але якщо справа просто в тому, що git "кращий", ніж підрив, то його насправді немає.

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

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

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

Гм, мабуть, ціла відповідь - це коментар насправді? Вам потрібно зробити свій випадок тут (у запитанні) на те, щоб перемогти підрив (у вашому оточенні), щоб дізнатись, чи зможемо ми допомогти вам визначити ділову справу

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

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

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

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

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

Ці речі дозволяють працювати більш ефективно, як соло, так і в команді. Більш ефективна робота = швидший час розвитку = швидший час на ринку = прибуток.

Пробачте за посилання на свій власний блог, але я писав статті на цю тему:

• Чому порада завжди повинна збиратися
• Чому DVCS забезпечує кращий центральний контроль
• Чому розгалуження краще за допомогою DVCS
• Чому моделі розподіленого розгалуження можуть не працювати добре на вашій CVCS .

Не соромтесь звертатися до них, якщо ви не вважаєте їх актуальними.

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

Мої аргументи для DVCS такі:

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

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

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

По суті, йдеться про зменшення тертя. Для цього є термін: Муда . Чим більше тертя, тим більше болю потрібно робити. Чим більше болю, тим менше робиться, тим менше прибутку.

Прошу вибачення, якщо я вдячний, але дозвольте мені поставити справу не сумнівно:

SVN робить життя розробників жалюгідним . І це робить бізнес із програмним забезпеченням нещасним.

... таким чином, який багато хто не зрозуміє, поки не почне використовувати DVCS. Це найважливіша справа бізнесу, яку можливо зробити . Чому? Добре, порівняно з витратами на пошук та утримання хороших розробників, вартість переходу на DVCS майже не існує .

Розглянемо наступне:

• Усі, крім самих тривіальних операцій у SVN (та більшості інших CVCS), вимагають доступу до мережі. У більшості DVCSes доступ до мережі відбувається лише тоді, коли ви робите операцію pushчи працюєте pull. Це означає, що нетривіальні команди повільні . Що ви робите, коли команду приймають назавжди? Я особисто переглядаю програми programer.se або хакерські новини, поки я чекаю. Простіше кажучи, DVCSes дозволяють програмістам зосередитися на тому, що вони люблять: писати програмне забезпечення компанії .
• SVN має підтримку для розгалуження майже так само, як тюрмам є підтримка скидання мила під душ: ви можете це зробити, але коли ви трапитеся. Таким чином, SVN змушує ваших розробників постійно боротися один над одним, щоб вносити зміни .
• Коли SVN вниз, він знижується. Розробникам стає страшно важко виконувати свою роботу, якщо вони взагалі можуть їх робити. Таким чином, SVN змушує ваших розробників бути надійними на вашій інфраструктурі, будучи на 100% без помилок .
• У наші дні git швидко набирає розум, а SVN швидко втрачає його. Якщо використання DVCS через SVN немає ніяких переваг, чому спільнота програмування змінюється настільки швидко, наскільки це можливо?

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

(Я мушу зазначити, що жирні твердження - це саме те, на що слід зосередитися. Решта з них просто містять контекст.)

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

Різниця показує, коли є проблеми

Ми перейшли на git 6 місяців тому після перенесення нашого десятирічного сховища.

Поки я після невеликого експерименту знайшов таке:

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

• більш надійний за своєю конструкцією - ви не покладаєтесь на 100% на доступному центральному сервері, і якщо це не так, ви можете використовувати рекламу будь-якого клону тимчасово як гарячу заміну. Це усуває вирішальний момент відмови - якщо сервер SVN з будь-якої причини вийде з ладу, ніхто не може виконати роботу SVN. Якщо центральне сховище git з будь-якої причини виходить з ладу, ви все одно можете працювати та натискати / тягнути локально, щоб пересвідчитись комітетів. Ви можете навіть мати кілька сховищ поза сайтом саме для цієї мети.

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

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

Отже, я пропоную для вашого ділового випадку подивитися, що ви будете робити, коли станеться катастрофа ...

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

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

Ділова справа для виривання SubVersion - це підтримка розгалуження, яка є бар'єром для стабілізації та обслуговування продукту. Якщо вам потрібно випустити продукт, а потім продовжити розробку, вам потрібна філія. З підривною роботою розробники не використовуватимуть розгалуження належним чином, і тому ви не зможете утримати розробку на туніку, і переконаєтесь, що виправлення помилок насправді роблять це і на стовбур, і на гілку.