Простий спосіб залучення непрограмістів (тобто дизайнерів) до використання версій управління?

13

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

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

Графічні інтерфейси, як Tower, допомогли, але концепція його або зустрічається гнівом («не моя робота!» Своєрідним ставленням), боязкість, або просто прямо не використовую його (використовуючи FTP замість цього, обходячи контроль версій для скажімо, dev або розгортання ).

Редагувати: Я мав би трохи уточнити, що я не маю на увазі лише зображення / PSD.

version-control teamwork

— Кевін
джерело

11

Зробити це ЛЕГКО для використання ...

1

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

— Кевін

2

Варто пам’ятати, що керування версіями та резервне копіювання інколи стикаються (хоча вони сильно відрізняються) та дизайнеру з бінарними даними; резервне копіювання вже може бути нормою, і тому слід розуміти, що він або вона отримує.

— Аарон Маківер

1

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

— Девід Торнлі

1

Займайтеся дизайнером, а потім залучайте її приватно до контролю версій. :)

11

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

Спільний доступ / резервне копіювання файлів завжди відповідає рівню контролю версій

Коли ви говорите:

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

Потрібно бути в курсі підводних помилок використання управління версіями з бінарними даними:

Переписування : Якщо два дизайнери працюють над одним файлом, другий, який потрібно здійснити, замінить зміни першого як поточну версію. Єдиний спосіб запобігти цьому - це блокування або постійне спілкування про те, хто робить що для якого файлу, і те й інше може перешкоджати робочому процесу своєї команди.
Об'єднання : з’єднання за допомогою інструментів у двійкових даних не існує. Ручне злиття болюче і схильне до величезної кількості помилок.
Здуття репозиторію: системи VC зберігають лише змінені рядки для текстових файлів. Це неможливо з двійковими даними, оскільки весь файл буде виглядати інакше, ніж система VC. Це означає, що хоча 20 версій текстового файлу розміром 10 КБ можуть займати лише 20 КБ, 20 версій файлу розміром 1 МБ, ймовірно, займатимуться ближче до 20 МБ. Команда дизайнерів середнього розміру може легко генерувати багато змін на десятках бінарних файлів. Незабаром ваш ІТ-відділ може ненавидіти вас щодо вимог щодо зберігання даних і, можливо, навіть збільшення пам’яті / процесора, який матиме ваш сервер ВК

Ви та інші розробники також незабаром можуть ненавидіти, скільки часу можуть отримати каси або оновлення, якщо ви не створили дуже гарну організацію сховищ, щоб уникнути бінарних файлів.
Скорочена вигода : Ваші дизайнери рідко, якщо взагалі колись, повернуться до попередніх версій бінарних файлів, тому що 1) непростий спосіб перевірити вміст минулої версії 2) жоден простий спосіб злити її, а головне, 3) вони не Не працюйте таким чином - вони використовуються для створення альтернативних версій деякої графіки, які все ще можуть бути корисні у самих виробничих файлах.

Для свого коду ви повинні абсолютно використовувати VC, і ви маєте право вимагати його.

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

— Ніколь
джерело

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

— Baelnorn

5

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

— Берін Лорич

2

@Berin: Це правда, але одна з переваг сучасної системи ДКС полягає в тому, що двоє людей можуть працювати над одними і тими ж речами одночасно, і багато роботи з примирення є автоматичними. Однак із двійковим файлом, де немає змістовного процесу злиття, це неможливо. Крім того, керівник сховища - той, про який люди будуть вважати "справжнім".

— jprete

1

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

— rsp

1

Ви абсолютно помиляєтесь, наприклад: Overwriting - це не проблема управління версіями, навпаки, це допомагає вам виявити це. Системи ВК зберігають лише змінені рядки для текстових файлів. - Неправда для git.

— maaartinus

4

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

Це ВЕЛИКЕ ставлення, прямо з "не моя робота!" :-)

Найкращий спосіб отримати покупку - використовувати щось на зразок TortoiseGit або TortoiseSVN для інтеграції управління версіями в Провідник (припускаючи Windows). Потрібен час, щоб побачити реальну користь, якщо ви не звикли до парадигми управління версіями. Черепаха принаймні полегшує роботу з VCS за допомогою миші. Простий "Клацніть правою кнопкою миші -> Checkin" - все, що потрібно.

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

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

— Кріс К
джерело

4

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

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

— rsp
джерело

2

Проілюструйте переваги:

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

— jzd
джерело

1

-1 Йшлося про залучення непрограмістів; список видається орієнтованим на програміста. Якщо змінити свою відповідь , я, звичайно , видалити вниз голоси ...

— Аарон МакІвер

1

Я думаю, ви пропустили частину "для непрограмістів". Усі згадані вами завдання - це завдання програміста.

— Ерік Функенбуш

Вибачте, я просто прочитав питання, а не заголовок. Я відредагую відповідь.

— jzd

1 Видалено ...

— Аарон Маківер

1

"Не моя робота" щодо контролю версій - це розумне ставлення непрограміста.

Створіть систему контролю версій так само просто і непомітно, як Dropbox для синхронізації або Time Machine для резервного копіювання.

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

— мувівієль
джерело

1

Я використовував черепаху HG / mercurial з новою леді веб-сайту, проблем там немає. Якщо немає каси, це дуже просто і чинить весь тиск на людину, яка насправді має переконатися, що файли синхронізовані. Це навіть не здається "ще однією справою", це просто "добре, я збираюся демонструвати веб-сайт, тому я повинен попросити Петра повторно синхронізувати зміни". і це не проблема.

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

— Пітер Тернер
джерело

0

Я б сказав, використання клонів черепахи *, тим простіше це отримати. Або інтегруйте керування версіями в IDE або інше.

— Койот21
джерело