Добрый вечер.Чесно говоря времени перечитывать всю документацию по гиту не было, вопрос стоит очень жестко. Словом, есть некий репозиторий на Bitbucket . Две команды трудяться над проэктом. Есть рабочий сервер с проэктом. Есть два других - тестовых. Ранее файлы на основном сервере загружали через ФТП, когда команда была одна.Сейчас стал вопрос над тем чтоб обновлять рабочую машину прям с репозитория. Помогите на следующим, как создать хранилище на основном сервере когда в каталоге уже есть рабочие файлы и не затрут ли файли с РЕПЫ файлы на сервере?
правильно создать! по факту у вас есть же последняя свежая и работоспособная версия файлов? Создаете пустой репозиротий - прописываете гитигнор, потом в эту пустую папку заливаете эти файлы свежие, делаете первый коммит - куда и входит все эта версия.... ну а потом на тестовых серверах делаете клоны - желательно создаете для каждой команды новую ветку .. .ну или одну - но не мастер и алга.... коммитим - пушим, мерджим, тестим, рабочий код - на главный сервер правдо вопрос как вы будете рабочую машину с репозиротия обновлять .... какую нить систему деплоя надо типа дженкинс ну или самим чего-то писать автоматизируя процесс обновления
Я только что закончил контракт где помогал это настроить за деньги: git, bitbucket, пара серверов, один из которых "рабочий". Подскажу схему бесплатно, если не дойдёт, то могу за деньги всё сделать за вас. По поводу "не помешает ли, что файлы уже есть" и "затрут ли": если захотим, то не помешает и да, затрут. Читай про `git checkout -f`. Чтобы в репу попадали только те файлы, которые должны перезаписываться на хостинге, надо аккуратно настроить .gitignore. Например папку под upload файлов надо поместить в игнор. Каждому сайту надо сопоставить бранч в гите. Например : master - это стейджинг сайт, демо production - это рабочий сайт или какие-то другие несколько веток для нескольких демо-сайтов, а мастер для продакшена. выбор только за вами. В битбакете в настройках репозитария есть такая фишка как webhook. Это обращение к вашему веб-скрипту при наступлении какого-то события в репе. Например при push обратиться к http://example/deploy.php Понятна идея? Битбакет передаёт этому скрипту всю необходимую информацию, в том числе имя ветки в которой были изменения. Этот скрипт будет делать git pull и размещать полученное в нужной папке. Упрощенно так. Остаётся создать этот самый deploy.php на вашем хостинге. Есть готовая либа и внятное описание (на английском) https://bitbucket.org/lilliputten/automatic-bitbucket-deploy/ http://blog.mobnia.com/bitbucket_automated_deployment/ вам нужно правильно создать конфиг-файл для деплоя, для каждой ветки своё описание. --- Добавлено --- P.S. переместил тему в правильный раздел
Чуть подробнее про ветки: Должен быть порядок! Допустим все могут коммитить в master и результат должен автоматом попадать на демо-сайт. Работник ответственный за выпуск релизов уполномочен мержить master в production и это действие должно приводить к выкладке на рабочий сайт. Это правило следует задокументировать и довести до каждого, чтобы всё знали как происходит рабочий процесс. Технически это происходит так: тот кто хочет опубликовать изменения на рабочем сайте создаёт Pull Request. Есть такая команда в битбакете. А уполномоченный товарищь этот PR "апрувит", то есть даёт добро и только тогда происходит копирование коммитов в ветку production. Размещение скрипта деплоя: a) Простейший случай когда оба сайта демо и продакшн размещены на одном хосте и сайты работают из-под одной и той же пользовательской учетки типа www-data. В таком случае вебхук может быть один на всё про всё, только конфиг будет настроен так, чтобы разные ветки деплоить в разные DocumentRoot. b) Если сайты хостятся в разных местах или учетки разные, понадобятся несколько записей про вебхук на битбакете и соответственно несколько экземпляров скрипта развёртывания. Для каждого экземпляра описывем настройку только для одной ветки git. Итого, что нужно знать: - git: ветки и мержинг, bare-репа, параметр GIT_WORK_TREE - ssh: ключи, пользовательский конфиг - Pull Request это термин битбакета, а не гита. мердж происходит при одобрении PR - в настройках вебхука на битбакете нельзя указать конкретную ветку, но это не критично, т.к. информация о ветке передаётся в параметрах вызова скрипта - виртуальные хосты сайтов могут работать под разными пользователями, это надо учитывать.
2artoodetoo - а https://bitbucket.org/lilliputten/automatic-bitbucket-deploy/ подходит под новые реалии битбакета? А то у них там в апреле или когда формат хуков менялся, пришлось писать свой велосипед А через Докер контейнеры не пробовали сделать что-то? Вроде возможности большие... но мне чето так даже просто е ФТП обновление не получилось сделать
@ADSoft Прямо на этой странице написано, что "Fixed new bitbucket.org webhooks interface (stream instead of POST)" --- Добавлено --- всё работает --- Добавлено --- докер это концептуально и актуально, но это не для всех. всегда говорю: проще — лучше.