# Git

# Основные цели использования git в проектах

• Коммандная работа
  одновременнно с проектом работают два и более разработчиков — им нужны свои копии сайта чтобы не мешать друг другу и не перезаписывать чужие изменения
• Перенос изменений на рабочий сайт
  после локальной разработки (или разработки на тестовом сервере), нужно перенести все на другой сайт, причем сделать это максимально автоматизированно
• Сохранение истории изменений кода
  на долгосрочных проектах или проектах, находящихся на поддержке (с большим количеством мелких задач, которые выполняют разные люди)
• Код ревью — на перспективу
  одна голова хорошо, а две лучше

# Варианты конфигурации

Как правило git используется вместе с несколькими копиями сайта, у каждой своё назначение и своя ветка в репозитории:

1. Копия для разработки (об1ычно локальная)
   Здесь вы вносите изменения в код и самостоятельно тестируете перед закрытием задачи.
2. Тестовая копия (доступная извне)
   Здесь руководитель проекта и/или заказчик проверяют и принимают задачи
3. Рабочий сайт
   Изменения по протестированным и принятым задачам переносятся сюда.

См. также:

• Перенос изменений
• Перенос изменений архивом

# Корпоративный git-сервер

• https://git.citrus-soft.ru
  логин — адрес почты на @citrus-soft.ru, пароль — пароль от почтового ящика.

# Развертывание рабочей копии

Если у проекта нет репозитория, см. Перевод проекта на git

1. Делаем и разворачиваем у себя бекап сайта привычным способом
   При создании бекапа папку .git в архив включать не нужно.
2. git clone репозитория проекта во временную папку
3. Переносим папку .git из временной папки в папку с развернутым бекапом
4. Удаляем временную папку
5. Переводим рабочую копию в нужную ветку
   В репозитории проекта должен быть описан порядок работы с ветками.

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

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

• В общем случае мы считаем что файлы в репозитории главнее и переводим рабочую копию в исходное состояние командой git reset --hard HEAD && git clean -d -f -q
• Если изменения наши (а не другого разрабочтика) и их нужно сохранить, коммитим их как обчно

# Перевод проекта на git

Важно! Файлы вроде .htaccess, bitrix/php_interface/dbconn.php и bitrix/.settings.php должны быть исключены из репозитория и не должны переносится между копиями.

На новых проектах можно полностью исключать папки /bitrix/ и /upload/ из контроля версий, а всю разработку вести в папке /local/ (см. Стандарты разработки).

Для старых, можно использовать подобный .gitignore чтобы исключить ядро из контроля версий.

# Создания репозитория для работы

# Работа над задачами

# Перенос измнений

# Перенос изменений архивом

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

Чтобы упростить эту процедуру есть скрипт git-build.php, собирающий файлы, измененные между двумя коммитами в архив:

1. Положить скрипт в корень сайта (он же корень рабочей копии),
2. Выбрать первый и последний коммит, изменения из которых нужны и скачать архив,
3. Закачать архив через аминку или FTP на удаленный сервер и распаковать его в корень сайта с перезаписью изменений.

# Получить архив с файлами, измененными между вумя комитами из консоли

Работает, но возможно не на всех средах

Список измененных файлов максимум на 1 МБайт:

git diff --name-only -z --diff-filter=d HEAD^ HEAD | xargs -0 --max-chars=1048576 git archive --output=../citrus_arealty.zip HEAD

Не работает если есть измененные файлы с пробелами

git archive --output=../citrus_arealty.zip HEAD $(git diff --name-only --diff-filter=d HEAD^ HEAD)

Не работает если список измененных файлов > ~120КБайт:

git diff --name-only -z --diff-filter=d HEAD^ HEAD | xargs -0 git archive --output=../citrus_arealty.zip HEAD

Где:

• HEAD — конечный коммит
• HEAD^ — начальный коммит
  начальный или конечный коммиты могут быть указаны номером ревизии

Список удаленных файлов можно получить командой:

git diff --name-status --diff-filter=D HEAD^ HEAD

# Конвертация файлов репозитория в другую кодировку на лету

Для конвертации из windows-1251 в utf-8 В своем репозитории (папке .git в файл .git/config) добавляем фильтр:

[filter "convert_to_utf8"]
	clean = iconv -c -f utf-8 -t cp1251
	smudge = iconv -c -f cp1251 -t utf-8
	required

Для нужных файлов в репозитории указываем настройки задаются либо в файле .gitattributes в одном из каталогов проекта (обычно в корне), либо в файле .git/info/attributes, если вы не хотите, чтобы файл с атрибутами попал в коммит вместе с остальными файлами проекта, например, так:

lang/**/*.php	filter=convert_to_utf8

После изменения конфигурации необходимо выполнить checkout(если изменения не применились, вам необходимо удалить содержимое проекта). В итоге файлы в рабочей копии будут в кодировке utf-8, а в репозиторий будут попадать (коммититься) в кодировке windows-1251.

# Как не коммитить изменения прав на файлы

Для того, чтобы изменения атрибутов и права на файлов не учитывались git-ом необходимо выполнить следующую команду:

git config core.filemode false

# Получить изменения с удаленного репозитория

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

git fetch origin
git reset --hard origin/master

# Автоматическое обновления тестовых площадок после коммитов в git

Позволяет авоматически обновлять рабочую копию на тестовом сайте после пуша изменений в репозиторий на git.citrus-soft.ru.

# Настройка

# На стороне сайта

1. На сайт загрузите файлик git-pull.php
   Туда будет стучаться Gogs после получения изменений, файл должен быть доступен по http
2. На *.citrus-dev.ru этот пункт уже выполнен!
   Загрузите в домашнюю папку пользователя, из-под которого работает веб-сервер, в ~/.ssh/ файлы ключей: id_rsa и id_rsa.pub.

В файле git-pull.php задайте секретный ключ в константе GOGS_SECRET, он понадобится позже.

# В репозитории

1. Идем в настройки репозитория на git.citrus-soft.ru
2. На странице Ключи развертывания добавляем содержимое id_rsa.pub
3. На странице Автоматическое обновление нажимаем Добавить Webhook → Gogs
4. В поле URL обработчика указываем пусть к файлу git-pull.php на сервере, в Secret — тот самый GOGS_SECRET

В URL обработчика можно указать суровый и беспощадный параметр force: git-pull.php?force, тогда при каждом обновлении будут прибиваться все незафиксированные в git изменения (потенциально приводяющие к конфликтам).
В этом случае все изменения файлов через админку будут потеряны.

Остальные настройки можно не менять.

Результат и правильность работы можно проверить на странице хука в настройках репозитория.