Хорошим прикладом того, хто відповідає цьому опису, може бути керівник проекту.

Днями мене запитав мій начальник, "що це за штука Гітбуба і чому вона важлива?" У нього є власні проекти, тому йому знадобиться приватний хостинг, і я опинився, що намагаюся пояснити поза звичайним: VCS роблять співпрацю тривіальною, надають історію та "резервне копіювання" всіх ваших даних та дозволяють записувати атомні зміни в базі коду. . На моїй думці я думав, "це майже так, як якщо б вам довелося використовувати DRVS, щоб дійсно зрозуміти, наскільки це вигідно".

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

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

Контроль версій відмінно підходить для (принаймні) трьох чотирьох речей: резервне копіювання, обмін кодом між розробниками, пошук + виправлення помилок та відстеження прогресу.

1. Резервне копіювання . Якщо нічого іншого, це резервне копіювання на стероїди. У вас є вся історія розробок, кожен фіксатор - це знімок всього вашого коду з ідентифікатором (номер редакції), описом, часовою маркою, інформацією про користувача. І порівняти файли між версіями просто. Якщо нічого іншого, це швидше, ніж проста резервна копія (надсилаються та зберігаються лише зміни файлів) і містить набагато більше корисних метаданих. Навіщо винаходити це?

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

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

4. Відстеження прогресу . Коли ви здійснюєте свою роботу в моментних знімках, це дозволяє вам (і вашому менеджеру) відстежувати прогрес щодо впровадження функцій та стану відкритих помилок. Системи ВК також легко інтегруються із системами відстеження та системами безперервної інтеграції . Підтримувати рівень якості нічого іншого, крім хобі-проекту, майже неможливо, якщо у вас немає VCS.

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

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

"Ви коли-небудь вважали кнопку" скасувати "корисною? О, значить, ви погоджуєтесь, що тоді ми повинні використовувати контроль версій?"

Коли я почав використовувати управління версіями, головна особливість, яка мене зацікавила, - це можливість «скасувати» мої помилки та повернутися до попередньої версії. Кожен може оцінити кнопку скасування. Зазначений контроль версій може зробити набагато більше.

Почніть з основ:

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

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

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

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

Після того, як ви продали VCS (які, зрештою, використовуються лише командам розробок, де кількість розробників перевищує нуль), тоді питання, чому DVCS закінчується, скажімо, SVN чи TFS, і подальше питання, чи потрібно працювати вдома або використовувати розміщену службу, таку як «Піч», «Бітбукет» або «Github» (яка є приватною, якщо ви платите), є більш глибокою та залежною від контексту.

ДКС

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

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

DVCS

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

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

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

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

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

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

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

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

У вашого менеджера проектів є проста мета - завершити проекти вчасно та за бюджетом.

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

Що вам потрібно зробити - пояснити менеджеру проектів, що команда витрачає Xкількість годин щотижня вручну, вирішуючи проблеми, які GIT може вирішити автоматично, або, скажімо, 0.1 * Xкількість годин розробника.

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

Мені подобається опис @ Buttons840 його як кнопки скасування для бази коду. Це також може допомогти порівняти його з (менш засмучуючою) версією програми Word або InDesign "Відстежувати зміни". З мого досвіду, це однозначно зменшує потребу однієї людини ходити навколо, кажучи іншим не торкатися файлів X, Y і Z протягом наступних кількох годин, що зручно для того, щоб робити речі.

Також я знайшов інформацію про дрібнозернисту версію неймовірно корисною для виправлення / роботи навколо помилок. Я зберігаю номер версії SVN (через властивість $ Id) майже в кожному генерованому файлі даних. Таким чином, якщо (коли?) Знайдена помилка, тривіально виявити файли з потенційними проблемами та відновити їх або мати інший код, що компенсує помилку.

Якщо ви не використовуєте контроль версій, як ви знаєте, як відновити виробниче середовище?

1 Різні люди (тестери, розробники) шукатимуть однакову інформацію в різних місцях

що веде до DUPLICATE ДАНИХ, які виходять із синхронізації.
Контроль версій - це найпростіший спосіб усунення повторюваних даних.

2 Якщо ви користуєтеся контролем версій, легко переконатися, що виробниче середовище відповідає тому, що є у контролі версій.

Це дозволяє легко визначити, чи була проблема через погану збірку (prod не відповідає контролю версій), або помилка дизайну чи кодування (prod відповідає матч версій).

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

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

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

Крім того, VCS полегшує вам перенесення цього виправлення в нову гілку розвитку, якщо помилка все ще присутня там.

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

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

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

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

1) Ми можемо клонувати весь сховище, не потрібно турбуватися про проект або його веб-сайт загинув.

2) Люди готові надсилати виправлення помилок через запит на витягнення, що призводить до швидшого виправлення помилок для нагальних проблем.