SCI-CD

h1. GIT WorkFlow

В ветку develop должны попадать уже проверенные изменения. Поэтому кидать в нее не утвержденные пулл реквесты смысла нет.

Поэтому предлагается для согласования создавать *в основном репозитории* новые feature-веткии и в них совместно работать.

Когда feature-ветка будет одобрена, она вливается в develop и удаляется.

Сценарий такой:

h2. Автор изменения

Создает в своем локальном репе ветку FEATURE на основе develop

Когда ветка готова к публикации:

<pre>

git checkout develop

git pull upstream develop

git checkout FEATURE

git rebase -i develop # объединять коммиты не обязательно

git push upstream FEATURE

</pre>

Сообщает участникам, что ветка FEATURE готова для тестирования

h2. Участник

Получив сообщение о необходимости обработки FEATURE

<pre>

git fetch upstream

git checkout -t upstream/FEATURE

</pre>

Получает ветку FEATURE, привязанную к upstream/FEATURE.

Из этой ветки, git push будет по умолчанию проталкивать в upstream/FEATURE.

Далее участник исследует/тестирует изменения.

и т.д.

Если участник исправляет код, то он сохраняет изменения в ветке FEATURE и делает

<pre>

git push

</pre>

h2. Завершение FEATURE

Когда будет принято решение влить изменения в develop, автор или кто-то еще с доступом к upstream:

<pre>

git checkout develop

git pull upstream develop

git checkout FEATURE

git rebase -i develop # объединяет коммиты, пишет анотацию

git checkout develop

git merge --no-ff FEATURE

git branch -d FEATURE

git push upstream develop

git push upstream --delete FEATURE

</pre>

h2. Полезные команды

Просмотр, какие коммиты еще не вошли в develop (или другую ветку относительно текущей)

<pre>

git cherry -v develop

</pre>

Подгрузка диапазона коммитов из другой ветки

<pre>

git checkout OTHER_BRANCH

git cherry-pick HASH..HASH

</pre>