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

13

Каковы основные способы вовлечения вашей команды в использование контроля версий во время разработки, веб-разработки или иным образом?

Я отказываюсь работать без него, а это значит, что все, кто участвует в проекте, также должны его использовать. Это просто хорошая практика.

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

Изменить: я должен был уточнить, что я имею в виду не только изображения / PSD.

version-control teamwork

— Kevin
источник

11

Сделать это ЛЕГКО для использования ...

1

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

— Кевин

2

Следует помнить, что управление версиями и резервное копирование иногда сочетаются (хотя и сильно отличаются) от разработчика с двоичными данными; резервное копирование уже может быть нормой, и поэтому необходимо понимать, что он или она приобретает.

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

1

@ Кевин: То, что легко, очевидно и интуитивно понятно программисту, не обязательно является чем-то подобным для других людей, даже для умных и творческих людей.

— Дэвид Торнли

1

Вступите в контакт с дизайнером, а затем втяните ее в управление версиями. :)

11

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

Общий доступ к файлам / резервное копирование всегда совпадают с контролем версий

Когда ты говоришь:

Я отказываюсь работать без него, а это значит, что все, кто участвует в проекте, также должны его использовать. Это просто хорошая практика.

Вы должны знать о подводных камнях использования контроля версий с двоичными данными:

Перезапись : если два дизайнера работают с одним и тем же файлом, второй коммит перезапишет изменения первого как текущую версию. Единственный способ предотвратить это - блокировка или постоянное общение о том, кто что делает с каким файлом, и то, и другое может помешать работе их команды.
сращивание : инструмента отсутствует в двоичных данных. Ручное объединение болезненно и подвержено огромному количеству ошибок.
Репозиторий вздутие живота: системы VC хранят только измененные строки для текстовых файлов. Это невозможно с двоичными данными, так как весь файл будет выглядеть иначе, чем в системе VC. Это означает, что хотя 20 версий текстового файла размером 10 КБ могут занимать всего 20 КБ, 20 версий файла объемом 1 МБ, вероятно, будут занимать около 20 МБ. Команда разработчиков среднего размера может легко создать множество ревизий для десятков двоичных файлов. Ваш ИТ-отдел может вскоре возненавидеть вас за требования к хранилищу и, возможно, даже по увеличению памяти / ЦП, которые будут у вашего VC-сервера.

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

Для вашего кода вы обязательно должны использовать VC, и вы вправе требовать его.

Но вам нужно проверить предположение, что это означает, что все также должны использовать его, а также то, является ли это хорошей практикой для дизайнеров (хотя резервное копирование является). Вы должны хранить конечные графические ресурсы, необходимые для вашего веб-сайта / приложения, в вашем VC, но для рабочих файлов это может быть неправильным решением.

— Николь
источник

Что касается «раздувания репозитория»: вы можете попытаться обойти это с правильными форматами файлов. Документация, хранящаяся в формате языка разметки документов , и графика, хранящаяся в формате языка разметки графики вместо эквивалентных двоичных форматов, могут сильно помочь. Конечно, жизнеспособность этого зависит от рассматриваемого проекта и готовности и компетентности вовлеченных людей. ;)

— Baelnorn

5

Перезапись на VCS не стоит ничего. Что происходит, что у вас есть две версии одного и того же файла. Да, ГОЛОВКА хранилища будет иметь последнее сохранение; но работа другого дизайнера не теряется, как на общем жестком диске. Я думаю, что это важное различие.

— Берин Лорич

2

@Berin: Это правда, но одно из преимуществ современного VCS заключается в том, что два человека могут работать над одним и тем же одновременно, и большая часть работы по согласованию выполняется автоматически. Однако с двоичным файлом, где нет значимого процесса слияния, это невозможно. Кроме того, глава хранилища - это тот, кого люди будут считать «реальным».

— jprete

1

Поскольку жизненный цикл исходного кода и проектной документации отличается, обязательно используйте для них отдельные репозитории. Я не согласен, что репозитории отстой для дизайнеров; большая часть времени уходит на размышления и моделирование, а не на внесение множества мелких изменений в документы. Мы также устанавливаем правило, запрещающее автоматическое объединение (для всех файлов, хранящихся в репозиториях) и, следовательно, обязательное блокирование файлов для изменений. В сочетании с хорошим командным общением это позволяет избежать многих упомянутых вами недостатков.

— rsp

1

Вы совершенно не правы, например: перезапись - это не проблема контроля версий, напротив, она помогает вам обнаружить это. Системы VC хранят только измененные строки для текстовых файлов. - Ложно для мерзавца.

— Maaartinus

4

Я отказываюсь работать без него, а это значит, что все, кто участвует в проекте, также должны его использовать. Это просто хорошая практика.

Это ОТЛИЧНОЕ отношение, прямо там с "не моей работой!" :-)

Лучший способ получить бай-ин - использовать что-то вроде TortoiseGit или TortoiseSVN для интеграции контроля версий в Explorer (при условии Windows). Требуется время, чтобы увидеть реальную выгоду, если вы не привыкли к парадигме контроля версий. Черепаха, по крайней мере, облегчает работу с VCS с помощью мыши. Простой «Правый клик -> Регистрация» - это все, что нужно.

По этой причине я стремился реализовать прозрачный контроль версий в TortoiseGit при каждом закрытии файла. Если вы дадите кому-то ветку для работы, а затем каждая запись / закрытие станет операцией фиксации, то в какой-то момент вы, как разработчик, сможете объединить их ветку, не беспокоясь о целостности всего репозитория, и они смогут продолжить работу с бизнес делать то, что они делают, без необходимости знать о контроле версий.

У меня та же проблема с огромным набором документов аудита, из-за которых я не могу привлечь людей к управлению версиями, поэтому у нас есть 50 версий одного и того же документа, которые немного отличаются друг от друга.

— Крис К
источник

4

Для этого можно настроить систему сборки (например, Hudson ), которая использует систему управления версиями для извлечения источников сборки и сделать ее правилом проекта, согласно которому только те артефакты , которые предоставляются системой сборки , отправляются в группу тестирования и в конечном итоге развернут на сайте заказчика.

Сделайте очень ясным, что в отношении процесса проекта все, что не происходит в сборке, является конфиденциальным только для разработчиков; пока чья-то работа не принята в сборку, она может и не существовать.

— RSP
источник

2

Проиллюстрируем преимущества:

Покажите им, как они могут сэкономить время, предоставив всем возможность делиться работой и иметь доступ к центральному местоположению.
Покажите им, как это позволяет дизайнерам работать над различными частями проекта одновременно и объединить их вместе.
Покажите им, как они могут помечать и создавать более старую версию приложения для тестирования или устранения неполадок.
Покажите им, как они могут возиться с дизайном для экспериментов, а затем обновить проект и не сохранять изменения, если они не хотят.
Покажите им, как они могут видеть, что произошло с течением времени.

— JZD
источник

1

-1 Это было о привлечении непрограммистов; список кажется ориентированным на программиста. Если вы измените свой ответ, я, безусловно, уберу отрицательный голос ...

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

1

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

— Эрик Фанкенбуш

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

— JZD

1 Удалено ...

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

1

«Не моя работа» по поводу контроля версий - нормальное отношение непрограммиста.

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

Это должно просто работать. Нет проверки, нет фиксации. Просто поместите файлы в папку проекта.

— mouviciel
источник

1

Я пользуюсь tortoiseHG / mercurial с новым веб-сайтом, никаких проблем там нет. Отсутствие проверок делает это очень просто и оказывает все давление на человека, который фактически должен убедиться, что файлы синхронизированы. Это даже не похоже на «еще одну вещь, которую нужно сделать», просто «хорошо, я собираюсь продемонстрировать сайт, поэтому я должен попросить Питера повторно синхронизировать изменения». и это не проблема.

Раньше у меня не было опыта работы с Mercurial, мы используем VSS, и я бы никогда не пожелал этого кому-либо для контроля исходного кода сайта. Я попробовал это однажды, и я не стал бы никого обвинять в том, что он не хотел использовать это тогда.

— Питер Тернер
источник

0

Я бы сказал, использование черепах * клонов, тем проще. Или интегрируйте контроль версий, в IDE или что-то еще.

— Coyote21
источник