Как настроить смешанный (S)FTP + Git рабочий процесс для веб-сайта

Question

У меня есть много сайтов с виртуальным хостингом, которые в настоящее время обновляются через chroot SFTP. Обновления выполняются клиентами (как правило, с помощью Dreamweaver и CuteFTP/Filezilla) и сотрудниками моей компании (обычно с помощью Eclipse Team Syncronisation с JCraft SFTP). Эта настройка работает нормально, если только клиенты не редактируют свой сайт одновременно с нами. В этом случае мы должны постоянно синхронизироваться, чтобы проверять изменения, которые являются медленными и ненадежными. Также SFTP-передачи являются медленными, учитывая огромное количество файлов на каждом сайте, медленный обратный путь в каталогах и отсутствие дельта-сжатия.

Я хочу перейти к (частичному) рабочему процессу Git, чтобы извлечь выгоду из дельта-сжатия, а также ввести элементарный контроль версий. Я говорю "рудиментарно", потому что типичный рабочий процесс git по разработке и тестированию локально перед объединением изменений в git commitits плохо подходит для наших нужд, потому что:

• Некоторые наши клиенты должны использовать SFTP, а не Git для удобства или совместимости
• Я не хочу форсировать конкретного клиента SFTP (например, git-ftp). Нашим клиентам удобен собственный выбор (например, Dreamweaver или CuteFTP). Они могут быть в любой ОС и не используют оболочки.
• Ни один из наших клиентов не может проводить локальное тестирование, каждое небольшое изменение должно быть загружено на веб-сервер и немедленно начать работу "вживую" (у нас есть тестовые сайты, поэтому "живой" не обязательно означает "производственный" или "общедоступный" в данном случае)
• Около 90% изменений будут небольшими однострочными изменениями CSS/HTML, что делает принятие сообщений длительным.
• Некоторые изменения вносятся непосредственно на webroot сервера с помощью оболочки или скриптов.

Я предполагаю, что я хочу, чтобы удаленное git-репо использовало webroot в качестве рабочего каталога и автоматически фиксировало любой файл, измененный там, с общим сообщением, указывающим, какие файлы были изменены. Однако я продолжаю читать, что основной репозиторий для проекта не должен иметь рабочий каталог (git init --bare), и даже если он делает это, он обычно не фиксирует сделанные изменения. Мне все равно, если эта установка потеряет данные о владельце коммитов (так как он не будет знать, кто изменил файлы, и мне, как правило, все равно).

В противном случае я в основном хочу использовать Git в качестве альтернативы Rsync-over-SSH (который не поддерживается Eclipse Team Sync). Любой ответ, предлагающий другую технологию, должен поддерживать Eclipse (мой инструмент выбора) и Dreamweaver (мой основной инструмент клиентов). Я понимаю, что это не идеально, но это не подлежит обсуждению. Если бы я мог принудительно использовать Git, я бы и эта проблема не имела бы значения. Мне приходится иметь дело с сотнями клиентов, в основном графическими дизайнерами на Mac.

PS. Я понимаю, что будут проблемы, когда клиенты не будут регулярно синхронизировать свои локальные файлы. Любые предложения по обработке, которые будут оценены.

Кто-нибудь может предоставить руководство по этой настройке (Centos 6.4 Linux).

Answer 1

Для изменений, внесенных непосредственно на сервере (или через SFTP):

Взгляните на Gitwatch, который является "bash-скриптом для просмотра файла или папки и внесения изменений в git-репо". Кажется, это именно то, что вы ищете.

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

Большим преимуществом использования отдельного основного репо, такого как github / bitbucket, является то, что вы можете легко просматривать / просматривать вносимые изменения и самостоятельно извлекать их локально, если хотите, без необходимости прямого доступа к git-репо на веб-сервере.

Для изменений, сделанных через git:

Вы также хотите вносить изменения через git и автоматически загружать их на веб-сервере? Теоретически вы можете подключить хук после получения в git, чтобы сделать это для вас. Однако вы могли бы легко получить конфликты слияния, если бы изменения были внесены непосредственно на сервере в то же время.

На второй мысли, избегайте этого. Придерживайтесь однонаправленного веб-сервера -> локальная фиксация -> переход к основному git-репо.

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

Answer 2

Для меня вы должны установить инструмент непрерывной интеграции, такой как Jenkins, CruiseControl или один из многих других вариантов, настроенный для развертывания на веб-сервере.

Тебе нужно:

1. репозиторий для каждого сайта, доступный через sftp и просматриваемый с помощью gitwatchсовершить изменения (как предлагает jszobody) и хитак, чтобы вытащить / push / ask_for_help_via_email_to_a_developer_if_merge_fails
2. "центральное" хранилище, где разработчики и хук будут толкать каждый коммит.
3. инструмент CI по вашему выбору, который при каждом нажатии, полученном центральным репозиторием, активируется и отправляет обновленное содержимое на веб-сервер (sftp, прямой доступ к fs... что лучше для вас).
4. веб-сервер, которому теперь не нужно предоставлять публичный доступ ни через git, ни через sftp.

Плюсы:

• покрывает все ваши требования
• нет необходимости в рабочем каталоге в центральном хранилище
• нет необходимости открывать больше портов на веб-сервере (за исключением http / https, очевидно)
• нет необходимости устанавливать git на веб-сервер
• нет необходимости перегружать файловую систему веб-сервера историей хранилища (которая содержится в .git/ папка)
• довольно гибкий
• легко перейти к полнофункциональному решению CI (автоматизированные тесты, метрики кода и т. д.)
• не синхронизируется с клиентами, потому что ловушка не сможет слиться, и разработчик будет предупрежден

Минусы:

• сложный, поэтому дорогой в настройке
• вам нужно будет проинформировать своих клиентов о новом используемом адресе sftp (если вы разумно не использовали другой поддомен и можете просто подождать обновления DNS).

Answer 3

Я не вижу смысла в том, чтобы сто разработчиков развертывались на одном веб-сервере и пытались отслеживать их изменения, но быстрый и грязный способ - использовать задачу cron для git add . а также git push --force клон сервера к соответствующему зеркалу где-то еще, где вы можете лучше управлять слияниями и отсылать обратно к клону сервера (который должен находиться в отдельной ветке). Клон сервера (для дизайнеров, для которых git невидим) будет выглядеть почти постоянно грязно, так что вы можете захотеть уменьшить интервал cron.

Answer 4

Может быть, что-то, что будет создано на основе dulwich, подойдет вам, какой-то веб-сервер на основе Python для управления репозиториями. https://github.com/jelmer/dulwich