Бос скептично використовує систему контролю версій для нового проекту, чи варто мені все-таки?

Дивіться /software/109817/superior-refusing-to-use-subversion

Моє запитання подібне, але ось основні відмінності в моєму сценарії:

• Ми починаємо новий проект з нуля, використовуючи PHP та веб-технології. Не було б часу спаду в розвитку, як ми б приймали його з самого початку, якби я мав свій шлях.

• Моя команда розробників складається з мене та мого начальника. Ми - департамент "ІТ" порівняно невеликої фірми.

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

Пропозиція мого начальника, безпосередньо вставлена ​​з електронного листа:

• Оновлення слід подавати у вигляді пакунків у папці SUBMISSIONS. Пакет повинен містити всі відповідні файли, а також файл 'UPDATE.NFO', який містить опис оновлення, список усіх нових файлів, що включені (з описами), та список усіх модифікованих файлів із детальними відомостями про модифікацію.

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

• Усі надіслані пакети мають бути встановлені в тестовому середовищі кожного розробника незабаром після надсилання. Кожен розробник повинен переглянути нове доповнення та висловити будь-які занепокоєння щодо його встановлення до виробничого середовища. Стандартне оновлення упаковки повинно проводитись як мінімум 3 робочих дні для цього процесу огляду перед завантаженням у виробниче середовище. Оновлення / виправлення з високим пріоритетом можуть пропустити цю вимогу.

Причина управління джерелом була придумана в тому, щоб зробити все це автоматичним, правда? Я запропонував підрив, тому що саме цим я користувався в коледжі. Бос не любить підрив, тому що "Він створює безлад коду" (тобто використовує двійкову магію і не легко читається). Ми спробували це один раз, але я думаю, що спроба використовувати його на Windows зробила дивні помилки в нижньому / великому регістрі, і ми не змогли перевірити наші файли. Я не знаю, чи заперечують це лише підривна робота або всі продукти контролю джерел.

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

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

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

Будь ласка, жодних коментарів "не знайдіть іншу роботу". Це не допомагає дебатам.

Не питайте його. Не кажи йому. Покажіть йому.

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

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

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

Дайте йому шпаргалку, яка полегшить йому використання вашої системи контролю версій.

Нарешті, запропонуйте кілька варіантів, але залиште рішення йому . Чи варто налаштувати власний сервер або скористатися однією з безлічі розміщених сервісів ? Чи варто використовувати svn, git чи щось інше? Чи варто перенести всі сім проектів на систему чи спробувати спершу один чи два?

Переваги керування джерелами виходять далеко за рамки, дозволяючи декільком розробникам працювати над одним кодом. Ерік Сінк, засновник SourceGear , перелічує кілька вагомих причин використовувати джерело управління в якості єдиного розробника :

- It's an undo mechanism.
- It's a historical archive.
- It's a reference point for diff.
- It's a backup.
- It's a journal of my progress. 
- It's a server. 

Ерік також має дуже хороший досвід початківців " Управління джерелами" . Існує безкоштовний онлайн підручник з обміну, доступний Джоелом Спольським, Mercurial - популярна система управління версіями.

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

І нарешті, перш ніж спробувати переконати свого начальника, можливо, ви захочете заглибитись у тему розгляду заперечень . Це 101 продаж.

Якщо це не вдалося - рухайтеся якнайшвидше, не дуже витрачаючи час на нахили на вітряні млини.

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

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

Якщо я не можу його переконати, чи буде якийсь сенс використовувати мене лише для себе?

Так. Користь використовувати це лише для себе. Ви отримуєте історію змін, щоб ви могли бачити, що відрізняється.

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

Настійно рекомендую, як згадувалося до використання git, причина №1 полягає в тому, що будь-який VCS є мережею безпеки в разі катастрофи. Шукайте наклейку «У разі пожежі: git počin, git push, покинь будівлю». Код може зберігатися десь в іншому місці, але немає в ноутбуці, який може зламатись, викрасти чи будь-що інше ... навіть сервер локальної мережі не є найбезпечнішим місцем для чогось такого цінного, як код.

Число 2. Простежуваність змін, хто робив, коли і т. Д. ... Злиття, Скасування. Число 3. Розрізняйте магічний інструмент для №2 та багатьох інших справ. Число 4. Відділення № 5. Тег версій, версій тощо.

Ви можете знайти більше інформації про один із найпоширеніших робочих процесів git тут: https://nvie.com/posts/a-successful-git-branching-model/

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

Щодо вашої проблеми з текстовим регістром, не використовуйте Tortoise, я знаю, що більшість людей використовують це як графічний інтерфейс для git, оскільки це було дуже часто для SVN, тому це може бути перший вибір, замість цього використовувати командний рядок або інший графічний інтерфейс, наприклад, настільний github або SourceTree від атласа.