Делай добро - вернется

Фабрика добра
и конвейер благотворительности,
основанный на вашем доверии и поддержке !

Прошу помочь

О фонде Прошу помощи Как помочь Вы помогли Новости

текст «ОТЕЦ ТВОЙ, ВИДЯЩИЙ ТАЙНОЕ, ВОЗДАСТ ТЕБЕ ЯВНО» Обратиться в фонд

Спасите ребенка

9897

Сбор для школ

Git на VM Bitrix

Реквизиты Фонда

Назначение платежа: Благотворительное пожертвование на уставную деятельность

Получатель: БФ "МАТРОНУШКА

р/с: 40703810356000000790

ИНН:7720935233

КПП:772001001

ОРГН:1247700556619

Банк:ПОВОЛЖСКИЙ БАНК ПАО СБЕРБАНК

к/с: 30101810200000000607

БИК:043601607

ОКОПФ:70401

ОКФС:50

НО:7720

ПФР:087401074164

ОКТМО:45312000000

ОКВЭД:64.99

Делай добро - вернется

Раздел не найден.

Оказывается контроль версий с 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"

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 шагов, можно настроить самую простую работу с репозиториями и сильно упростить себе жизнь.

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

Обновить гит

yum install git

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

git config --global user.email ***@****.com

git config --get user.email посмотреть под каким емайлом зарегистрирован

Установите имя пользователя Git:

git config --global user.name "*****"

Убедитесь, что вы правильно установили имя пользователя Git:

git config --global user.name

> ******

ssh-keygen -t rsa -C ***@******.ru создать ключ

$ ssh-keygen

Generating public/private rsa key pair.

# путь до ключей, в скобках путь по умолчанию

Enter file in which to save the key (/Users/ifireice/.ssh/id_rsa):

# пароль для ключей, при задании пароля в консоли не отображается ничего, даже звёздочки

# если нажать Enter, ничего не вводя, пароль будет пустым

Enter passphrase (empty for no passphrase):

# повторите пароль

Enter same passphrase again:

# после появится сообщение такого вида

Your identification has been saved in /Users/ifireice/.ssh/id_rsa

Your public key has been saved in /Users/ifireice/.ssh/id_rsa.pub

The key fingerprint is:

SHA256:Zu+HkZPC4ZP0veRmVjuKgylVvljHBNO8mHs+ieFFPvs ifireice@ifireice-osx

The key's randomart image is:

+---[RSA 3072]----+

| o |

| o o |

| = . |

| o + + |

| +S* X |

| oB.@ X . |

| . O.# * . |

| . +.*.% o |

| . o*.+E. |

+----[SHA256]-----+

отетить yes а не y
Бинго, ключи сгенерированы: в заданной директории появятся два файла, id_rsa и id_rsa.pub.

Теперь надо добавить публичный ключ в аккаунт на GitHub:

# выведите содержимое публичного ключа в консоль

$ cat ~/.ssh/id_rsa.pub

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQDDJfHIi73sKd6cqm3RwKuY1zl46aAaE6X9Gp

/6zJiY3BiJj95oJjPdpfpPhVFWLIbmT8zFAtOLbX9N4C3b0enHUzgMacP/Kl4AbrAkhLqaua9iD

VNxxiTVxADG1M5525oc/eAvx7y0pXIb9ouWdYJSKa8/TUYFhWlCzV2quY9SA0FaMs7eY41+KWYpG.....

tA0oGxv+7WmXQmQzleLIRG13KQ+VAbL2vabdPcRoGuZavh0smOr/GtVSnLdspZ5RgONMSPWlF2I1YHMR

Q7CIKPs= ifireice@ifireice-osx

Скопируйте ключ от символов ssh-rsa и до конца файла и вставьте его в ваш аккаунт на GitHub

сюда записать ключ «SSH keys»

https://github.com/settings/ssh здесь ключи, сюда его занести

git remote rm origin удалить гитхаб

git remote –v  проверить куда отдаеться инфа

git remote add origin https://github.com/***/****.git        создать свой путь

cd /home/bitrix/www перейти в папку битрикс

git --version узнать версию гитхаба

ssh -T git@github.com проверить подключение по ssh и узнать имя пользователя в гип хабе

Ошибки

Hi имя пользвателя! You've successfully authenticated, but GitHub does not provide shel

access.

При использовании HTTPS с GIT распространен ряд ошибок. Обычно они указывают на то, что у вас старая версия GIT или нет доступа к репозиторию.

Репозиторий, который вы пытаетесь получить, должен существовать в GitHub.com, а в URL-адресе учитывается регистр.

Чтобы узнать URL-адрес локального репозитория, можно открыть командную строку и ввести

git remote -v проверьте путь

пример как изменить

$ git remote -v
# View existing remotes
> origin  https://github.com/ghost/reactivecocoa.git (fetch)
> origin  https://github.com/ghost/reactivecocoa.git (push)

$ git remote set-url origin https://github.com/ghost/ReactiveCocoa.git
# Change the 'origin' remote's URL

$ git remote -v
# Verify new remote URL
> origin  https://github.com/ghost/ReactiveCocoa.git (fetch)
> origin  https://github.com/ghost/ReactiveCocoa.git (push)

проверьте регистр С с  разный путь

----


Теперь, проверьте, запущена ли служба SSH, с помощью следующей команды:

$ sudo systemctl status sshd

Если по какой-либо причине служба SSH не работает для вас, вы можете запустить ее с помощью следующей команды:$ sudo systemctl start sshd

Теперь разрешите доступ к портам SSH через брандмауэр с помощью следующей команды:

$ sudo firewall-cmd —add-service = ssh —permanent

и сохранить изменения команду не помню,

---------------------------------

очему не работает SSH для GitHub?

Ситуация:
В консоль вхожу, набираю
ssh -T git@github.com
Получаю ответ: Hi *****! You've successfully authenticated, but GitHub does not provide shell access.
Connection to ssh.github.com closed.
Далее делаю push:

git push origin master
fatal: HttpRequestException encountered.
   Произошла ошибка при отправке запроса.
Username for 'https://github.com':

Скорей всего у вас origin ведет на https, такое может быть, если вы проект клонили через

git clone https://github.com/somerepo
а не через
git clone git@github.com:somerepo
Проверьте через
git remote -v
Сменить можно через
git remote set-url origin git@github.com:somerepo

Мигание

Пожертвуйте, на богоугодные дела!

Блаженны милостивые, ибо они помилованы будут!

Михаил/13 лет/ДЦП/Полностью сохранен интеллект/Собирает на мечту "Встать с коляски"

История Помочь >>>

Мигание

Пожертвуйте, на богоугодные дела!

Блаженны милостивые, ибо они помилованы будут!

Тематические страницы

Event-Driven Architecture в контексте микросервисов: основные паттерны | Николай Голов, ManyChat

Годовые отчеты о деятельности фонда Поступившие пожертвования

Куда пошли ваши деньги —

Дорогие друзья! Примите нашу искреннюю благодарность и признательность за щедрость, за участливое неравнодушие, за солидарность. Огромное спасибо! Вы сделали пожертвование и хотите знать, что стало с вашими деньгами – куда конкретно пошли ваши деньги, кому именно помогли. Раздел ВАШИ ДЕНЬГИ как раз об этом, знакомьтесь .....

Куда пошли ваши деньги —