Git настройка для не-разработчиков
Я пытаюсь представить git на работе, и для этого хочу максимизировать участие в бай-инах.
Это не проблема для программистов (мы, как правило, рады изучать новые вещи, подобные этому), но это проблема для дизайнеров и менеджеров контента, которые выполняют статический контент, такой как html, css и т.д. Они могут с трудом использовать Subversion через TortoiseSVN, поэтому мне нужно как можно больше упростить git. Это означает, что некоторые понятия должны быть как-то скрыты, например, индекс, stash, merges, rebase, branches.
Грязные рабочие копии должны автоматически обрабатываться с помощью штампов.
Также нет способа использовать командную строку. Они также не будут читать руководства или учебные пособия.
Вы можете задаться вопросом, почему я не просто придерживаюсь git -svn: это потому, что дизайнеры должны настраивать html/css, которые я создаю, прежде чем он будет объединен с trunk.
Итак, вопросы: кто-нибудь использовал git с не-разработчиками? как вы справляетесь с этим? что ваш рабочий процесс? Может ли git -cvsserver быть полезным для этого? Есть ли какой-либо графический интерфейс, который автоматически сжимает?
Все, что может быть использовано для упрощения git, будет с благодарностью.
Ответы
Ответ 1
В принципе, вам нужно сделать Git:
- прозрачный для ваших нетехнических пользователей
- управляемый одним техническим Git -savvy "суперпользователем
Это означает:
- один центральный репозиторий Git, где каждый менеджер конструктора/контента будет подталкивать (даже если они этого не знают)
- скрипты, запускаемые каждый день (обычно рано ночью) для:
- мониторинг центрального "файла инструкций" (который может проинструктировать упомянутый script на каждой станции коммандера изменить ветвь или обновить файл
.gitignore
или...)
-
git add -A
, git commit
-
git push
-
git pull
(им нужно знать, чтобы каждое утро просматривать их рабочее пространство, чтобы учесть новые работы, извлеченные из центрального репо).
- записать результат всех команд в выделенных файлах (датированных и названных после коммиттера в центральном общем каталоге)
Каждое утро суперпользователь проверяет, успешны ли все попытки и разрешает ли конфликт. Он/она также объединит утвержденную работу в локальных ветких центрального репо (включая ту, которая тянется каждую ночь).
Я также рекомендовал бы сделать эти хранилища Git (на рабочих станциях коммитеров) в общем каталоге, чтобы суперпользователь мог получить к ним доступ и напрямую манипулировать ими, если это необходимо.
Ответ 2
У нас есть несколько дизайнеров, работающих с git с помощью GitExtensions. У них нет никаких проблем, потому что GitExtensions делает все автоматически, как пристыковка, нажатие и предупреждение пользователя, когда есть какая-либо проблема/конфликт. Настройки автоматически проверяются при запуске, и мало что можно сделать неправильно. Это намного проще, чем черепаха, когда вы привыкнете к терминам push/pull/commit.
Ответ 3
Вы сказали, что они не будут читать учебники, но, возможно, вы можете прочитать это, объясните им.
http://hoth.entp.com/output/git_for_designers.html
Что касается GUI, посмотрите эти сообщения:
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
Ответ 4
Я только что увидел этот вопрос. В нем упоминается flashbake, представляющий собой набор скриптов python (которые вы могли бы установить для дизайнеров в качестве значков для двойного щелчка, как предлагалось), которые заботятся о множестве общих действий git. Я не использовал его, но похоже, что он, вероятно, будет лучше, чем начинать с нуля - и если вы сделаете некоторые улучшения, это поможет другим в вашем месте! На странице проекта:
Основное внимание в сценариях заключается в создании богатого, но автоматизированного сообщения фиксации для git. Во-вторых, он автоматизирует управление проектом git, поэтому один, инвариантный вызов flashbake заботится о наиболее распространенном рабочем процессе git, добавлении и фиксации файлов.
Я определенно также думаю, что предложение VonC выше о рабочем процессе, включая большой надзор суперпользователя, - вот еще одна большая часть ответа здесь.
Ответ 5
Почему бы просто не позволить им продолжать использовать SVN и позволить более техничным подкованным использовать Git.
Git может работать с репозиториями SVN. Поэтому сохраните репо SVN для дизайнеров и репо для git для разработчиков. Попросите своих опытных пользователей управлять нажатием и вытаскиванием между ними, если это необходимо.
TortoiseSVN очень прост, и похоже, что это все, что вам действительно нужны нетехнические пользователи. Какую пользу они увидят, если они перейдут на Git?
(Просто примечание - я действительно не понимаю, почему вы не можете использовать git -svn)