3

Решил познакомиться с гитом. Есть 2 компьютера (две территориально разделенные машины), на них папка с проектом (сайт) один-в-один синхронизируется через дропбокс (это development версия проекта). На хостинге лежит production версия этого проекта. Как сделать так, чтобы:

  1. между локальными машинами development-версия снхронизировалась один-в-один через git (через сервер bitbucketa)
  2. путем исключения ненужных файлов из последней development-версии получить production и залить на хостинг

На данный момент development-версия лежит на битбакете

Я думал так: сделать 2 удаленных репозитория (на битбакете) для dev и prod версий. В локальном репо будет dev, она будет вручную пушиться в удаленный dev. При необходимости (т.е. вручную) некой магической командой (набором команд) из удаленного dev-репо будет браться последний вариант и копироваться в удаленный prod-репо. Оттуда пулл на хостинг. В итоге цепочка такая: local-repo -> remote-dev-repo -> remote-prod-repo -> hosting. У меня локально все dev версии, на битбакете - все версии и dev и prod, на хостинге только последняя версия prod.

Samir Routh
  • 125
  • А что за ненужные файлы, которые нужно исключать? Может, их сразу не стоит версионировать и просто заигнорить? – Nick Volynkin May 04 '16 at 11:39
  • По этапу развертывания - посмотрите на вот этот ответ, подходит? http://ru.stackoverflow.com/a/428514/181472 – Nick Volynkin May 04 '16 at 11:40
  • Вот, наконец-то хоть один человек начал меня понимать. Да, можно было бы игнорить, и тогда на хостинг заливалось бы только то, что мне нужно. Но как быть со второй локальной машиной. Там мне нужна последняя версия со всеми файлами (версия dev). DropBox? но я ведь взял Git, чтоб удобней было и чтоб контроль версий (включая эти спец файлы) был. – Samir Routh May 04 '16 at 11:45
  • DropBox точно не подходит. А вы можете точнее пояснить, что это за файлы? Они от среды разработки? Какие-то скрытые части сайта? Изменения, которые пока не пришло время зарелизить? – Nick Volynkin May 04 '16 at 11:46
  • Скрытые части - модули, которые нужны для dev версии (типа дебагера и тд) и изменения, которые пока не пришло время зарелизить (или несколько вариантов одного и того же, но пока я не выбрал, что лучше) – Samir Routh May 04 '16 at 11:48
  • Хмм. А дебагер вообще надо версионировать? Вроде есть какая-то тулза, возможно называется php composer, которая автоматически подтягивает зависимости и позволяет не версионировать чужой код. – Nick Volynkin May 04 '16 at 11:50
  • Несколько вариантов лучше просто хранить в разных ветках. Потом какие понравятся - сольёте (merge или rebase) в основную. При этом возможны конфликты, их придется руками поправить. http://ru.stackoverflow.com/a/437458/181472 – Nick Volynkin May 04 '16 at 11:52
  • Не, дебагер не надо. Он композером сам подтянется, если надо. Имеется ввиду, конфиг, где прописано, что нужен дебагер (а на хостинге этот конф файл должен быть пустым, чтоб не включался дебагер, нотам не только дебагер, это просто пример) – Samir Routh May 04 '16 at 11:55
  • "Несколько вариантов лучше просто хранить в разных ветках" - ну если я пока не определился, например, с внешним видом страницы и сделал 2 разных варианта, не буду же я вторую ветку делать. Я просто переименую их page.php и page_2.php. и все. и простым переименованием буду менять варианты. Пока когда нибудь не приду к окончательному решению. Но раз пока я выбрал вариант page.php, на хостинге должен быть он, а на dev-сервере - оба. При необходимости я просто переименую page_2.php в page.php, сделаю push, потом на хостинге pull, и вот у меня на сайте второй вариант. – Samir Routh May 04 '16 at 12:00
  • Давайте продолжим обсуждение в чате. – Nick Volynkin May 04 '16 at 12:01

4 Answers4

2

git сам не синхронизирует, придется делать git push, что бы отправить на сервер изменения и git pull, что бы получить. На первый взгляд выглядит неудобно (ведь нужно постояного коммитить и пушить) и не получиться "немного поработать на одной машине, а потом немного на другой. Но держать одинаковые версии не обязательно. Можно делать на разных компах разную функциональность. Со временем Вы придете к понимаю этого. А можно выделить себе сервер для разработки. Тогда многие "проблемы" уйдут сами по себе, но нужен постоянный доступ к серверу.

Теперь вторая часть - деплой. Тут есть много вариантов, но разделим их на две части - автоматический и ручной. При автоматическом варианте максимум что нужно - это нажать кнопку "деплой", а иногда и этого не нужно, но как по мне, так это очень опасно. Другие отвечающие об этом и говорят, когда упоминают CI. При ручном все переноситься поштучно, но это для особых любителей.

Но думаю, что на первых порах Вам подойдет полуавтоматический режим. Он очень простой и надежный. Суть сводиться к тому, что нужно написать свой скрипт (на любом языке (если знаете php - пишите на нем, я бы писал на смеси баша и перл). Этот скрипт должен делать следующее - сливать самостоятельно мастер ветку в отдельную чистую папку, потом удалять оттуда "лишние файлы" и добавить "правильные файлы/конфиги". Можно ещё и тесты прогнать (если они есть). В самом конце все пакуется в архив. Этот же скрипт может скопировать файл на удаленный сервер(а). А вот потом уже на сервере нужен ещё один скрипт, который остановит апач (или какой там сервер), забекапит старое (если нужно) и распакует новое (ну и естественно запустит сервер).

В результате деплой нового кода - это запуск одного скрипта, для сбора пакета и ещё один для собственно запуска. В будущем, эти скрипты можно будет использовать для того же CI.

Многие считают, что деплоить на сервер можно и нужно с помощью того же git. Но это абсолютно неправильно - на сервере будут "лишние данные". Если сервер случайно взломают, то получает доступ не только ко всей истории, а и к репозиторию.

KoVadim
  • 112,121
  • 6
  • 94
  • 160
  • "Многие считают, что деплоить на сервер можно и нужно с помощью того же git. Но это абсолютно неправильно - на сервере будут "лишние данные". Если сервер случайно взломают, то получает доступ не только ко всей истории, а и к репозиторию. " Вот-вот, я про это и говорю: мне нужна последняя prod версия и все на хостинге. А репозиторий со всеми прод-версиями с историей, чтоб хранилась на сервере битбакета, чтоб я оттуда всегда мог брать последнюю версию и заливать на хостинг. – Samir Routh May 04 '16 at 12:10
  • Про взлом сервера - абсолютно верно. Нельзя там хранить репозитории. – Nick Volynkin May 04 '16 at 12:23
1

Без Continuous Integration синхронизироваться ничего не будет. Только руками делая pull`ы на нужных серверах/машинах.

Если Вы только начали знакомство, лучше бы Вам ознакомиться с документацией и стандартными воркфлоу. Есть как минимум два популярных: gitflow и githubflow. Для небольших проектов/команд больше подходит второй вариант(на мой взгляд).

Powar
  • 91
  • так я и хочу ручками. Но как? Как pull с битбакета для локал машины дифференцировать с pull с битбакета для хостинга? – Samir Routh May 04 '16 at 11:25
  • Занесите локальные конфиги в gitignore. На продакшене у Вас вероятно должна быть всегда рабочая ветка(бренч) - master, для разработчиков и девелоп окружения, создайте вторую ветку, вносите изменения в неё, делайте в любом месте пулл с этой ветки, а как только поймёте, что код нужно отправить на прод, мержите ветку девелоп в мастер и делаете пулл из мастера на прод сервере. – Powar May 04 '16 at 12:02
  • так, кажется это то, что мне нужно. вечером попробую, отпишусь, что вышло у меня. спасибо – Samir Routh May 04 '16 at 12:13
0

В нормальных проектах обычно ставят Continious Integration (CI) сервер, который по определенным обстоятельствам деплоит проект на продакшн.

У нас устроено так: Teamcity (CI) подписан на наш GitLab, есть хук, по которому каждый мердж в бранч release с проставленным тегом (мы их именуем как v1.0.1, v1.0.2 и т.д.) проходит последнее тестирование (до этого отдельно тестирование проходили сами ветки с фичами). После успешного тестирования выполняется специальный скрипт деплоя, который обновляет в нужных папках нужные файлы.

Michael Sivolobov
  • 594
  • Ребят, я новичок в php, а с Git вообще первый раз сталкиваюсь, какой CI??? Тем более, я один. Те, у кого серьезные проекты и команда из нескольких человек и кому нужен CI, будут задавать вопросы, подобные тем, что я задал? – Samir Routh May 04 '16 at 11:22
  • Раз уж предлагаете CI для такой задачи, давайте сразу 12factor-app и релизиться контейнерами, чего мелочиться ) – Nick Volynkin May 04 '16 at 11:38
  • Я расписал не самую сложную схему деплоя, но которую можно настроить бесплатно, самостоятельно и потратив на это не более недели (с учетом чтения документаций по любым непонятным вопросам). Даже если над проектом работает всего один человек, ничего плохого не будет в том, если он научится делать все изначально красиво и правильно. – Michael Sivolobov May 08 '16 at 08:54
0

Вам нужно создать новую ветку в репозитории на dev сервере, к примеру production. В этой ветке изменяете необходимые файлы для работы на другом сервере:

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

После чего делаете push в ваш репозиторий на bitbucket.

На вашем production сервере клонируете репозиторий, переключаетесь на production ветку.

В итоге вы имеете 2 ветки:

 - development, для разработки
 - production, для основного сервера, куда вы сливаете все новые обновления из ветки development. И на основном сервере делаете pull.

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

Тогда вам будет достаточно с тестового сервера сделать push из production ветки и изменение прилетят на основной сервер

Victor
  • 387
  • У вас списки получились отформатированы как код. Это осознанно так? Последнюю строку трудно читать из-за этого. – Nick Volynkin May 04 '16 at 11:48
  • Крон-задача это плохо, создает лишнюю нагрузку на сеть и сервер. Смысл обновлять есть только когда обновилась ветка, из которой осуществляется релиз. Для этого можно настроить хук. – Nick Volynkin May 04 '16 at 11:49
  • да у меня маленький проект, все изменения вношу только я один. Мне крон не нужен, я вручную буду. Вечером попробую сделать так, как посоветовали и отпишусь – Samir Routh May 04 '16 at 11:52