Как затягивать изменения с сервера через Git?

Question

[mletov]

Есть сайт на Битриксе.

Создал на сервере репозиторий, настроил его обновление вот по этому мануалу

В целом все хорошо. Сommit и push работают как надо.

Но есть проблема с pull. В Битриксе когда пользователь через админку что-то меняет, то не всегда изменения пишутся в базу, иногда и в php файлы. И бывает, что просто какие-то файлы через интерфейс закачивают. Хотелось бы их актуализировать на локальной машине через pull -> merge.

Но если нажать pull или fetch all, то локальная версия изменений на сервере не видит.

Например, в github если что-то поменять на сервере, то при pull эти изменения можно вытянуть.
Хотелось бы сделать аналогично.

Как это настроить?
В какую сторону копать, что почитать? Хуки?

Comments

[Егор Живагин]

Недостаточно просто изменить/загрузить файлы, ещё нужно сделать add, commit, push на сервере. Можете делать это раз в день по крону, например

Но ситуация у вас странная)

[mletov]

Егор Живагин, спасибо за ответ)
Попробую зашедулить.

А что именно в ней странного и как надо/принять если файлы могут меняться юзерами?

[Михаил Ливач]

mletov, делать это в автоматическом режиме не рекомендую. Во-первых, пользователи админки могут сделать какую-то дичь - например, накидать в корень сайта видеороликов или папку с картинками. Во-вторых, некоторые изменения не полезны - скажем, urlrewrite.php меняется некотонтролируемо и часто бессмысленно ( просто пара условий меняется местами).
Поэтому правильный путь перед выкаткой нового кода на боевой - это зайти на боевой по ssh, глянуть git status , потом глянуть изменения ( я не парюсь и смотрю их в IDE - нахожу нужный файл и Compare with deployed). Ненужные правки откатить, нужные закоммитить и запушить вручную.
Не так удобно, как автоматика, но зато защищает от проблем.

[Егор Живагин]

mletov, сорри, не часто захожу сюда

Имхо, обычно происходит примерно так:
1 - Пользователь загружает файл на сервер через некий бэкенд-эндпоинт
2 - Бэк загружает файл и пишет в БД информацию о файле, минимум - путь до файла
3 - Все нужные места получают путь к файлу из БД и загружают его

При этом файлы размещаются не в репозитории, с такой схемой они могут лежать хоть в другой папке, хоть на отдельном cdn
И, если локально вы подключаетесь к продовой БД, то и эти файлы у вас будут нормально грузиться с продового сервера. Ни одному разработчику не нужно скачивать через git pull кучу файлов, не надо их хранить в репозитории, ... )

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

P.S. - Допускаю, что для битрикса это всё не валидно, не знаком с ним

[mletov]

Егор Живагин, Спасибо за ответ, попробую разные варианты.

Answer 1

[Сергей Кузнецов]

Этот мануал в вашем случае не подходит. Там синхронизация односторонняя. Вы отправляете не на сайт, а в репозиторий на сервере. Затем хук извлекает содержимое ветки master в каталог с файлами сайта, затирая всё что там ранее мог изменить пользователь через админку.

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

если нажать pull или fetch all, то локальная версия изменений на сервере не видит.

А разве должен видеть? Fetch/Pull скачивает не файлы из рабочего каталога, а коммиты из репозитория. Это вообще разные сущности. Чтобы в репо попали изменения, их нужно коммитить, только так и не иначе.

Предлагаю не создавать bare-репозиторий без рабочего каталога, а инициализировать обычный репо прямо в каталоге сайта. Обновления не проталкивать через push, а забирать через pull, потому что гит не сможет отправить push в текущую ветку. Чтобы забрать изменения файлов с сервера, их нужно предварительно коммитить разумеется, так как pull скачивает не файлы, а коммиты. Pull лучше делать на чистом от изменений рабочем каталоге, поэтому можно запускать простой скрипт

git fetch # скачать обновления заранее, чтобы не ждать во время обновления файлов
git stash # временно спрятать локальные правки
git pull # применить обновления к сайту
git stash pop # вернуть локальные правки обратно

Это немного помогает избежать конфликтов между вашими локальными изменениями и изменениями из внешнего репозитория. Но лучше предварительно закоммитить изменения на сервере и перенести их на рабочий компьютер.

Я таким способом в своё время успешно синхронизировал правки между компьютером разработки и основным сервером, где работал продукт. Там тоже часть файлов изменялось сервером во время работы. Скрипт отрабатывает достаточно быстро, чтобы сервер не успел заметить откат файлов при stash.

Comments

[Freeman]

Да-да, через похожую схему и я работал, только у меня было stash-rebase-unstash. Временами приходилось разрешать конфликты после последней команды, пусть mletov это учитывает и закладывает время, так сказать.

Хотя, появление конфликтов от характера вносимых и получаемых изменений зависит, конечно. Могут и не возникать.

[mletov]

Сергей Кузнецов,

Спасибо за ответ. Это очень похоже на то, что мне нужно.
Но возникла пара вопросов.

1) При доставании из stash все равно могут возникнуть конфликты если на клиенте и на сервере менялся один и тот же файл. Я правильно понимаю, что их придется все равно устранять вручную, т е ставить на сервер редактор кода для сравнения и ручного разрешения конфликтов? Просто зашедулить скрипт на сервере, чтобы он периодически делал pull, не получится.

2) При попытке сделать "git pull" на сервере, чтобы получить изменения с клиента, ругается:

"There is no tracking information for the current branch.
Please specify which branch you want to merge with.
See git-pull(1) for details.
git pull
If you wish to set tracking information for this branch you can do so with:
git branch --set-upstream-to=/ master"

Пробовал

git pull remote master

Тоже не сработало.

[mletov]

Freeman, да, меня как раз это и смущает, получается, на сервер надо какой-то редактор кода для разрешения конфликтов ставить

[Сергей Кузнецов]

mletov,

Тоже не сработало

А что должно было произойти? Вы же не связали ветки, вот гит вам это и напомнил. Он не понимает откуда вы хотите скачивать. Я в ответе предположил, что вы понимаете основы гита.

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

[Сергей Кузнецов]

Freeman, чтобы конфликты не возникали на самом сервере, их лучше резруливать заранее на своем компе. А сервер обновлять только когда гит статус говорит что всё чисто.

[Сергей Кузнецов]

mletov,

При доставании из stash все равно могут возникнуть конфликты

Чтобы конфликтов на сервере не возникало, коммитьте изменения сначала на сервере и забирайте их к себе на компьютер. Тогда конфликты будут уже на рабочем компе и разрешить вам их будет проще, так как у вас настроена рабочая среда с редактором кода и инструментами разрешения конфликтов.

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

[mletov]

Сергей Кузнецов,

Спасибо за подробные ответы)

Я в ответе предположил, что вы понимаете основы гита.

Честно говоря, не очень)
На работе пользуюсь чисто GUI клиентом или IDE для clone/pull/push/merge, а сам гит админы разворачивают и настраивают. А тут вот понадобилось самому копнуть глубже.

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

А допустима ли такая схема, что на сервере хранятся 2 экземпляра репозитория, один из которых, по сути, альтернатива гитхаб. И в него комитятся и из него забираются изменения и с клиента, и с серверного экземпляра?

[Сергей Кузнецов]

mletov, да
Третий репозиторий можно положить на тот же сервер. Создать или клонировать его уже с опцией bare, чтобы ничего не мешало в него пушить.

А в репозитории который привязан к самому сайту прописать этот третий обычной ссылкой на папку.
git remote add origin /путь/к/папке/репо3
Тут не нужны никакие протоколы типа ssh или https

У меня все компы были рядом в одной сети и работали под Windows. Поэтому я писал просто ссылку на расшаренную папку в сети вида
\\server\шара\путь

[mletov]

Сергей Кузнецов, не подскажете еще такой момент:
когда разворачивал через Git что-то приключилось с правами.

Даже простенький файлик phpinfo не хочет выполняться.

Пробовал в качестве эксперимента сделать

chmod 777 phpinfo.php

Права выставились, а выполняться так и не хочет.



Если развернуть бэкап - все номрально.

Git как-то держит файлы?

[Сергей Кузнецов]

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