Работа с git, когда проект работает на простом хостинге. Как правильно организовать ветки?

Question

[EazyE]

Добрый день!
Подскажите, пожалуйста, как правильно организовать ветки в git?
Ситуация такая. Использую фреймворк Laravel в проекте. Он имеет известную и простую структуру каталогов (примерно, т.к. детали тут не особо важны, структура практически у всех фреймворков такая же):

• app
  
• bootstrap
  
• public - папка с index.php
  
• ...
  
• еще всякие папки и файлы
  

А вот на хостинге самом организована такая структура каталогов для этого сайта:

• какая-то папка, созданная хостингом 1
  
• какая-то папка, созданная хостингом 2
  
• какая-то папка, созданная хостингом 3
  
• site_app - каталог с системными каталогами Laravel (app, bootstrap, ...)
  
• www - каталог с содержимым public, название www придумано не мной, изменить невозможно
  

Раньше я копировал изменения по ФТП и сделал такую структуру (а именно решил всё хранить в site_app, что раньше было не в папке public). Естественно, недостатков масса, начиная с того, что в www/index.php надо менять пути на site_app, заканчивая банально неудобным методом внесения обновлений. А хочется тупо зайти по ssh и сделать git pull.
Но как это сделать?
Можно создать ветку под названием, скажем, master_hosting, мерджить туда ветку develop, изменять её под "хостинговую структуру", коммитить, а затем уже на хостинге делать git pull.
Но мне очень понравился подход, описанный в этой статье habrahabr.ru/post/106912/. Там смысл такой, что после изменений делаем ветку release-x.x из develop, что-то в ней возможно меняем (та хоть бы readme.txt, а может и мелкие баги), коммитим, мерджим в master и develop (которая могла и измениться уже, так что исправляем конфликты). Видимо предполагается, что master мы pull'им затем куда следует и радуемся.
Как же поступить в моём случае? Видимо алгоритм добавление новой фичи в проект такой:
1. Создаём ветку my_feature из develop
2. Добавляем функционал
3. Коммитим
4. Мерджим с develop
5. Создаём ветку my_release из develop
6. Изменяем там readme.txt и/или еще что-то
7. Коммитим
8. Мерджим с master и develop
9. Создаём ветку hosting из master
10. Делаем изменения в структуре каталогов.
11. Коммитим
12. git pull с хостинга.

Но мне кажется, что что-то не так, не совсем это красиво... Подскажите, как делаете вы? Или может вообще я думаю не совсем правильно, скорректируйте мысли)

Comments

[Igor Deyashkin]

Что у вас в итоге с этим вопросом - он решился? Вам еще нужна помощь с ним?

[EazyE]

Igor Deyashkin: Решился) "Подгоняю" всё методом ln -s, если нужно

Answer 1

[D']

Зачем такое извращение с ветками?
Я обычно делаю ln -s laravel/public /path/to/www
Т.е по сути www у нас теперь ссылается на public папку laravel и нету никаких проблем с изменениями. Так же папку с самим проектом можно хранить где угодно.

Answer 2

[Антон Радушев]

может посмотреть в сторону capistrano ?

Comments

[qweqwa]

Кэп устарел.
Тогда уж Ansible или Chef.

Answer 3

[Philipp]

На мой взгляд удобнее арендовать VPS и настроить непрерывную интеграцию. Немного болезненно в начале, но никакого шаманства и треша в управлении версиями потом. Если ваш проект удачный, то он будет развиваться и обычного хостинга вам сразу перестанет хватать.
В текущем случае можно сделать что-то вроде этого stackoverflow.com/questions/327417/using-capistran...

Answer 4

[Alex Black]

Чтобы каждый раз не коннектиться к серверу и не делать каждый раз пул-реквест, можно настроить это автоматом. Я использую для управленя серверами вот эту штуку https://forge.laravel.com/ - рекомендую, кстати.

Answer 5

[Павел]

Нашёл этот вопрос решая ту-же проблему.
Я думаю чуть в другую сторону.
Буду исходить из того, что там (на хостинге) нету git.

Думаю делать rsync в локальную директорию, а уже её обрабатывать с помощью git.