Установка мерзавца для неразработчиков

Вы сказали, что они не будут читать руководства, но, возможно, вы сможете прочитать это и объяснить им ..

http://hoth.entp.com/output/git_for_designers.html

Что касается графического интерфейса, посмотрите эти сообщения:

https: // stackoverflow.com / questions / 157476 / what-guis-exist-for-git-on-windows

https://stackoverflow.com/questions/83789/what-is-the-best-git-gui-on-osx

Я только что видел этот вопрос всплывающим. В нем упоминается flashbake, представляющий собой набор скриптов Python (которые вы можете установить для дизайнеров в виде значков для двойного щелчка, как предлагается), которые заботятся о многих типичных действиях git. Я не использовал его, но похоже, что это будет лучше, чем начинать с нуля - и если вы внесете некоторые улучшения, это поможет другим на вашем месте! На странице проекта:

Основное внимание в сценариях уделяется генерации подробного, но автоматизированного сообщения о фиксации для git. Во-вторых, он автоматизирует управление проектом git, поэтому единственный неизменный вызов flashbake позаботится о наиболее распространенном рабочем процессе git, добавлении и фиксации файлов.

Я определенно также думаю, что VonC '

Почему бы просто не позволить им продолжать использовать SVN и позволить более технически подкованным людям использовать Git.

Git может работать с репозиториями SVN. Так что держите репозиторий SVN для дизайнеров и репозиторий git для разработчиков. Попросите своих опытных пользователей управлять между ними, если потребуется.

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

(Просто примечание - я действительно не понимаю, почему вы не можете использовать git-svn)

По сути, вам нужно сделать Git:

• прозрачным для нетехнических пользователей
• под управлением одного технически подкованного Git "суперпользователя"

Это означает:

• одно центральное репозиторий Git, куда каждый дизайнер / менеджер контента будет отправлять (даже если они этого не знают)
• скрипты, запускаемые каждый день (обычно рано ночью) для:
  • мониторинг центрального «файла инструкций» (который может дать указание сценарию на каждой станции коммиттера изменить ветвь или обновить файл .gitignore или ...)
  • git add -A , git commit
  • git push
  • git pull (им нужно знать, чтобы каждое утро просматривать свое рабочее пространство, чтобы учесть новые работы, полученные из центрального репозитория)
  • записывать результат всех команд в специальные файлы (датированные и названные в честь коммиттера, в центральном общем каталоге)

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

У нас есть несколько дизайнеров, работающих с git, используя GitExtensions. У них нет никаких проблем, потому что GitExtensions делает все автоматически, например, прячет, подталкивает и предупреждает пользователя, когда возникает какая-либо проблема / конфликт. Настройки автоматически проверяются при запуске, и тут мало что можно сделать неправильно. Это намного проще, чем tortoisesvn, если вы привыкнете к терминам push / pull / commit.