Оказывается контроль версий с Git на VM Bitrix это очень просто

Лет 5 назад я работал с системой контроля версий - это была SVN.
Такая себя громоздкая и неповоротливая. Но все же система контроля версий.

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

Очень пугала неизвестность, т.к. практического опыта работы с mercurial или git не было. И из-за этого вопрос всё откладывался и откладывался...

Но на практике оказалось, что всё достаточно просто и с этим вопросом (при отсутствии знаний Git совсем) можно разобраться за пару дней, а с наличием знаний и вовсе за час-два.

В своем посте хочу привести пример настройки репозитория в самом простом варианте.

Зачем вам репозиторий?
Если у вас нет репозитория, то ваша работа с сайтом, это как операция на открытом сердце. Любая ваша ошибка нарушает работоспособность сайта.
Пока сайт в разработке, это вроде некритично, но вот после запуска - это становится огромной проблемой!

Приведу два примера

Пример 1
Есть одна виртуальная машина или сервер (это не важно для нас сейчас).
В папке /home/bitrix/www - располагается файловая структура вашего сайта, например, site.com.
Для разработки нам необходима копия сайта
/home/bitrix/ext_www/dev.site.com, на домене dev.site.com
В обеих папках у нас будут локальные репозитории Git, которые будут работать с удаленным репозиторием.

Пример 2
Отличается тем, что файловая структура сайтов лежит на разных серверах.
Например,
сервер 1 /home/bitrix/www, site.com
сервер 2 /home/bitrix/www, dev.site.com

Настройка репозиториев

1. Проверяем есть ли у нас Git
На виртуальной машине версии 5 все уже установлено.
Подключаетесь к вашему серверу по ssh, авторизовываетесь под пользователем bitrix и вводите команду

>git

Если вы увидели вывод информации о гит, все нормально.
Если сообщение, что команда системе не известна, тогда понадобится проинсталировать пакет. В этом посте я этот вопрос рассматривать не буду.

Если Вы проводили инсталяцию git самостоятельно, то не забудьте запретить доступ к папка git вашего сайта в настройках nginx и apache (htaccess).

2. Настраиваете файл .gitignore
Создаете в корне сайта файл .gitignore и настраиваете его.
Приведу пример, в котором мы исключаем из репозитория все что относится к ядру сайта и включаем, только то что нужно.
Коллеги в комментариях подсказали, что можно и вовсе исключить из индекса папку bitrix, для этого нужно использовать папку /local

/.gitignore /.htaccess /*.htaccess /.htaccess* /urlrewrite.php /web.config /*web.config /*.log /*.sql # исключаем из репозитория текстовые файлы, но оставляем robots.txt /*.txt !/robots.txt /sitemap*.xml /*.dt /*.tar.gz /*.gz /*.tar /*.bak /*.old /*~ */_* /_* /composer.* # исключаем ВСЮ папку bitrix, но ниже настроим включение нужных папок # или используйте папку /local, чтобы полностью исключить папку bitrix /bitrix/* # включаем папку components, но исключаем components/bitrix !/bitrix/components /bitrix/components/bitrix/ # включаем папку php_interface и исключаем файл dbconn.php !/bitrix/php_interface/ /bitrix/php_interface/dbconn.php /bitrix/php_interface/*.bak # включаем папку шаблонов !/bitrix/templates/ # исключаем служебные и ненужные папки проекта /dev /pma /upload /verstka

3. Инициализируем репозиторий
В командной строке переходите в домашний каталог, в котором лежит ваша папка сайта

>cd /home/bitrix

Инициализируем репозиторий в папке www

>git init www

4. Начинаем работу с локальным репозиторием
Чтобы посмотреть что и как у вас настроено
Переходите в папку сайта

>cd /home/bitrix/www

Проверяете состояние репозитория

>git status

В результате вы увидите список файлов и папок, которые попадут в репозиторий.
Как раз сейчас самое время внести корректировки в файл .gitignore
Добавьте или уберите исключения, которые нужны именно для вашего проекта.
Если надо проверить индексацию внутри папки сайта, например /bitrix, используйте

>git status bitrix

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

>cd /home/bitrix/www

Файлы можно добавлять выборочно с помощью команды

>git add index.php

Или все сразу

>git add .

После этого можете проверить, что все файлы будут проиндексированы

>git status

на экране будет сообщение, что все проидексировано.
Можно делать первый коммит

>git commit -m "first commit"

6. Настройка удаленного репозитория
После того как вы настроили работу репозитория локально, надо выгрузить хранилище на сервер.
В качестве сервера можно выбрать https://bitbucket.org/
Бесплатный сервис, который предоставляет приватные репозитории.
Вы можете выбрать любой сервис, который вам больше по душе.
Настройка авторизации на этих сервисах отлично опасана в интернетах, поэтому я не буду раздувать пост и приведу основные команды для настройки начала работы.

Для начала нам понадобится сгенерировать ssh-ключи
Это делается командой

>ssh-keygen -t rsa -C "bitrix@имя.сайта"

По умолчанию, если ничего не будете менять, этой командой вы сгенерируете два ключа, приватный id_rsa и публичный id_rsa.pub
они будут в папке /home/bitrix/.ssh/

Далее вам нужно взять содержимое публичного ключа и вставить в настройки аккаунта bitbucket.org
Вы можете открыть файл приватного ключа в редакторе кода и скопировать одной строкой его содержимое. Или вывести на экран содержимое файла командой

>cat ~/.ssh/id_rsa.pub

Важное замечание! Ключ в bitbucket нужно вставлять в настройках вашего профиля, а не репозитория!

После того как вы настроили ключи, проверьте соединение

>ssh -T [email protected]

В результате вы должны увидеть сообщение об успешно коннекте к сервису.

Если увидите ошибку, то выполняйте соединение с выводом логов

>ssh -v [email protected]

или

>ssh -vvv [email protected]

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

>ssh-agent /bin/bash >ssh-add ~/.ssh/id_rsa

и проверьте соединение еще раз

>ssh -v [email protected]

Теперь все должно быть хорошо!

7. Передача синхронизация репозитория
Сервисы тоже отлично подсказывают как синхронизировать репозитории  и выдают команды для вашего проекта, поэтому так же кратко.

В локальном репозитории, нужно добавить связь с удаленным репозиторием

>cd /home/bitrix/www/ >git remote add origin [email protected]:your_company/your_repo

your_company - ваш логин bitbucket.org
your_repo - название вашего репозитория в bitbucket.org

Т.к. локальный репозиторий уже подготовлен, то нам осталось его передать в удаленное хранилище

>git push origin master

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

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

Если вы настраиваете репозитории, имея одну рабочую копию сайта, то вам достаточно будет скопировать файловую структуру, это и будет вторым готовым к работе репозиторием.
Кратко о процессе:
1. Создаете дополнительный сайт на виртуальной машине с помощью меню виртуальной машины
2. В папку созданного сайта копируете всю структуру

>cd /home/bitrix/www >cp -r . /home/bitrix/ext_www/dev.site.com/

Если у вас второй сервер, то сверните файлы и скопируйте их на новый сервер

>cd /home/bitrix/www >tar -cf /home/bitrix/site.com.tar.gz .

В результате у вас появится файл /home/bitrix/site.com.tar.gz со структурой вашего сайта, который вы можете скопировать на новый сервере и там развернуть

>tar -xf site.com.tar.gz

9. Заключение
В итоге мы настроили
1. Локальный репозиторий продакшен сайта
/home/bitrix/www
2. Удаленный репозиторий на bitbucket
3. Локальный репозиторий сайта разработки
/home/bitrix/ext_www/dev.site.com или папка на другом сервере

Схема работы следущая:
1. Вся разработка ведется на сайте разработки
2. Все изменения отслеживаются командой

>cd /home/bitrix/ext_www/dev.site.com >git status

3. Все изменения фиксируются командами

>cd /home/bitrix/ext_www/dev.site.com >git add

и

>git commit

4. Все зафиксированные изменения выгружаются в удаленный репозиторий

>cd /home/bitrix/ext_www/dev.site.com >git push origin master

5. Зафиксированные изменения загружаются в репозиторий продакшен сайта

>cd /home/bitrix/www >git pull origin master

Готово!



10. Выводы и использованная литература
Быстро, всего за 9 шагов, можно настроить самую простую работу с репозиториями и сильно упростить себе жизнь.

По поводу работы с системой Git

• рекомендую ознакомится с книгой-документацией, очень понятная и полезная
  http://git-scm.com/book/ru/v1 или http://git-scm.com/book/ru/v2 (тут не все на русском)
  
• Великолепная шпаргалка по командам GIT:
  https://github.com/nicothin/web-develo...master/git
  

Ну и конечно же, гугл.

• Ежедневная работа с Git http://habrahabr.ru/post/174467/
  
• Моя шпаргалка по работе с Git http://eax.me/git-commands/
  
• Организация командной разработки интернет-проекта (с использованием Git и 1С-Битрикс) http://habrahabr.ru/post/219569/
  
• Ежедневный Git http://habrahabr.ru/post/28268/
  

Очень хороший комментарий от Ивана ниже
http://dev.1c-bitrix.ru/community/web...4#com62944

I) Как указали выше, папку .git лучше располагать на уровень выше корня сайта. Это не только понизит шансы утечки содержимого .git, но и позволит контролировать служебные механизмы, которым не место в корневом каталоге и подкаталогах сайта: скрипты для запуска по расписанию, unit-тесты и пр. II) Папку bitrix не стоит включать в .gitignore, так как если не контролировать ядро Битрикс, то: 1. Разработчикам будет уже недостаточно просто склонировать репозиторий для начала работы. Придется добывать недостающие файлы. Причем, если работа над проектом ведется несколько лет, его состояние редко позволит использовать "cp -r", как указано в статье. Как показывает опыт, вместо этого придется заниматься трудоемким избирательным копированием. 2. Разработчики бывают разными и сколько не запрещай, в команде обязательно найдется человек, который поправит что-нибудь в ядре. В этом случае, появляется шанс, что в продуктивную среду уйдет код, который приведет к аварии. Это возможно, если код активно использует измененное ядро, а тестирование функциональности проводилось только на копии этого разработчика. Если включить файлы ядра в систему контроля версий, то изменения в файлах ядра становится возможным отслеживать и автоматически запрещать на уровне перехватчиков (hooks). Также можно настроить отправку уведомлений таким разработчикам с напоминанием правил работы с Битрикс. 3. Недопустимыми правками часто не брезгуют и операторы заказчика. Если не контролировать файлы ядра, такие изменения в продуктивной среде становится трудно отследить. Хоть Битрикс и сделал для этого собственный инструмент, Git в таких случаях помогает гораздо надежней. 4. Если не контролировать ядро, актуализировать файлы на всех копиях разработки после обновления Битрикс может стать очень затруднительно. Особенно, когда число таких копий приближается к сотне. 5. Порой, очередное обновление Битрикс приводит к ошибкам в существующей функциональности. Git показывает пришедшие с обновлением изменения, что существенно облегчает поиск проблем в таких случаях. 6. Не существует ни одной объективной причины, почему ядро нужно исключать из контроля версий. Многие опасаются, что производительность Git существенно упадет из-за количества файлов в каталоге bitrix. Это напрасное опасение — практика показывает, что Git прекрасно справляется с этой задачей. III) Не стоит использовать сторонние сервисы (BitBucket, GitHub и прочие) для чужих коммерческих проектов. Это часто противоречит требованиям NDA, может стать причиной утечек кода, а также, учитывая последние законодательные тенденции, и вовсе однажды оказаться незаконным. В качестве отрицательного примера можно привести блокировку GitHub на несколько дней в начале декабря. Некоторым компаниям это едва ли не парализовало работу. При этом, для того чтобы сделать центральный репозиторий, достаточно выбрать подходящий сервер (желательно внутри сети) и набрать там команду git init --bare. И все. В итоге, получается полноценный репозиторий, доступ к которому всегда находится под полным контролем. Кроме того, собственный центральный репозиторий позволяет гибко управлять обвесом: выбирать любимые протоколы, веб-интерфейсы, системы контроля доступа и рабочие процессы.

Шпаргалка по командам

В этом параграфе приведена сухая шпаргалка по командам Git. Я далеко не спец в этой системе контроля версий, так что ошибки в терминологии или еще в чем-то вполне возможны. Если вы видите в этом разделе ошибку, отпишитесь, пожалуйста, в комментариях.

Создать новый репозиторий:

git init project-name

Если вы планируете клонировать его по ssh с удаленной машины, также скажите:

git config --bool core.bare true

… иначе при git push вы будете получать странные ошибки вроде:

Refusing to update checked out branch: refs/heads/master
By default, updating the current branch in a non-bare repository
is denied, because it will make the index and work tree inconsistent
with what you pushed, and will require 'git reset --hard' to match
the work tree to HEAD.

Клонировать репозиторий с удаленной машины:

git clone git@bitbucket.org:afiskon/hs-textgen.git

Если хотим пушить один код в несколько репозиториев:

git remote add remotename git@gitlab.example.ru:repo.git

Добавить файл в репозиторий:

git add text.txt

Удалить файл:

git rm text.txt

Текущее состояние репозитория (изменения, неразрешенные конфликты и тп):

git status

Сделать коммит:

git commit -a -m "Commit description"

Сделать коммит, введя его описание с помощью $EDITOR:

git commit -a

Замержить все ветки локального репозитория на удаленный репозиторий (аналогично вместо origin можно указать и remotename, см выше):

git push origin

Аналогично предыдущему, но делается пуш только ветки master:

git push origin master

Запушить текущую ветку, не вводя целиком ее название:

git push origin HEAD

Замержить все ветки с удаленного репозитория:

git pull origin

Аналогично предыдущему, но накатывается только ветка master:

git pull origin master

Накатить текущую ветку, не вводя ее длинное имя:

git pull origin HEAD

Скачать все ветки с origin, но не мержить их в локальный репозиторий:

git fetch origin

Аналогично предыдущему, но только для одной заданной ветки:

git fetch origin master

Начать работать с веткой some_branch (уже существующей):

git checkout -b some_branch origin/some_branch

Создать новый бранч (ответвится от текущего):

git branch some_branch

Переключиться на другую ветку (из тех, с которыми уже работаем):

git checkout some_branch

Получаем список веток, с которыми работаем:

git branch # звездочкой отмечена текущая ветвь

Просмотреть все существующие ветви:

git branch -a # | grep something

Замержить some_branch в текущую ветку:

git merge some_branch

Удалить бранч (после мержа):

git branch -d some_branch

Просто удалить бранч (тупиковая ветвь):

git branch -D some_branch

История изменений:

git log

История изменений в обратном порядке:

git log --reverse

История конкретного файла:

git log file.txt

Аналогично предыдущему, но с просмотром сделанных изменений:

git log -p file.txt

История с именами файлов и псевдографическим изображением бранчей:

git log --stat --graph

Изменения, сделанные в заданном коммите:

git show d8578edf8458ce06fbc5bb76a58c5ca4a58c5ca4

Посмотреть, кем в последний раз правилась каждая строка файла:

git blame file.txt

Удалить бранч из репозитория на сервере:

git push origin :branch-name

Откатиться к конкретному коммиту (хэш смотрим в «git log»):

git reset --hard d8578edf8458ce06fbc5bb76a58c5ca4a58c5ca4

Аналогично предыдущему, но файлы на диске остаются без изменений:

git reset --soft d8578edf8458ce06fbc5bb76a58c5ca4a58c5ca4

Попытаться обратить заданный commit:

git revert d8578edf8458ce06fbc5bb76a58c5ca4a58c5ca4

Просмотр изменений (суммарных, а не всех по очереди, как в «git log»):

git diff # подробности см в "git diff --help"

Используем vimdiff в качестве программы для разрешения конфликтов (mergetool) по умолчанию:

git config --global merge.tool vimdiff

Отключаем диалог «какой mergetool вы хотели бы использовать»:

git config --global mergetool.prompt false

Отображаем табы как 4 пробела, например, в «git diff»:

git config --global core.pager 'less -x4'

Создание глобального файла .gitignore:

git config --global core.excludesfile ~/.gitignore_global

Разрешение конфликтов (когда оные возникают в результате мержа):

git mergetool

Создание тэга:

git tag some_tag # за тэгом можно указать хэш коммита

Удаление untracked files:

git clean -f

«Упаковка» репозитория для увеличения скорости работы с ним:

git gc