Фото взято из pikabu.ru

Введение

Обучение в École 21 основано на двух типах проектов: индивидуальных и коллективных. Основная сложность отдельного проекта, будь то разработка консольного приложения или погружение в основы devops, — это задача самого проекта. При командной разработке возникает необходимость распределить задачи между участниками и выстроить удобную работу с общим репозиторием. В этой заметке я хочу описать, как мы настроили работу с репозиторием.

Равно

Помню, на отборочном интенсиве я в основном сосредоточился на коде и не изучал возможности системы контроля версий глубоко. Он знал только стандартную последовательность заклинаний: git add .git commit -m "commit message"git push origin developи не совсем понял, как это все работает. А в групповых проектах, в которых я участвовал, каждый работал в своей ветке, и тимлид либо копировал конечный код из наших веток в один набор, либо писал весь проект в одиночку, не обращая особого внимания на результаты разработки остальных членов команды.

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

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

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

  • работа в вашем агентстве и в вашем файле;

  • запускать скрипт в начале рабочего сеанса get;

  • запустите скрипт, прежде чем отправлять его в репозиторий getзатем создайте коммит и запустите скрипт update

  • финальная версия проекта собирается из общей ветки и переносится в ветку разработки (school prod)

ЧИТАТЬ   Центральный университет получил официальную лицензию

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

Выделите время и сядьте, чтобы обсудить тему ветки в гите и утилита sed. Оказалось, что все не так уж и сложно. Идея в том, что помимо личных веток есть ветка с общим буфером, в которой хранится код всех участников. Благодаря этому весь код попадает в ветки разработки. Таким образом, каждый участник имеет доступ к достижениям своих товарищей по команде. Эта концепция подразумевает, что:

  • каждый работает в своей ветке и пишет код только в своих файлах

  • перед началом рабочей сессии текущее состояние кода на удаленной общей ветке извлекается из локального репозитория разработчика:

$ git checkout common_branch        # переключаемся на общую ветку;
$ git pull                          # забираем последние изменения из удалённой
                                    # общей ветки;
$ git checkout developer_branch     # переключаемся обратно в личную ветку;
$ git merge common_branch           # сливаем полученные изменения
                                    # в личную ветку;
$ git push origin developer_branch  # пушим эти изменения на удалённую
                                    # личную ветку.
  • перед пушем ваших изменений в личную ветку выполняется последовательность команд из пункта 2, затем общая ветка дорабатывается изменениями кода разработчика:

$ последовательность команд из п.2
$ git add .
$ git commit -m "commit message"    # создаём коммит;
$ git checkout common_branch        # переключаемся на общую ветку;
$ git merge developer_branch        # сливаем свой коммит в общую ветку;
$ git push origin common_branch     # пушим этот коммит на общую удалённую ветку;
$ git checkout developer_branch     # переключаемся на личную ветку;
$ git push origin developer_branch  # пушим этот коммит на личную ветку.

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

ЧИТАТЬ   «Сдаю максимум тысячу»: места для участия в Парижском полумарафоне начинают продавать по завышенным ценам
Скрипт get_remote_common_branch.sh
#!/bin/sh

CUR_BRANCH=$(git branch | grep "*" | sed 's/* //')
COMMON_BRANCH=duslar

git checkout $COMMON_BRANCH
git pull
git checkout $CUR_BRANCH
git merge $COMMON_BRANCH
git push origin $CUR_BRANCH
Скрипт update_remote_common_branch.sh
#!/bin/sh

CUR_BRANCH=$(git branch | grep "*" | sed 's/* //')
COMMON_BRANCH=duslar

git checkout $COMMON_BRANCH
git merge $CUR_BRANCH
git push origin $COMMON_BRANCH
git checkout $CUR_BRANCH
git push origin $CUR_BRANCH

Теперь, чтобы отправить свой код в репозиторий, вместо двенадцати команд достаточно ввести четыре:

$ sh get_remote_common_branch.sh
$ git add .
$ git commit -m "commit message"
$ sh update_remote_common_branch.sh

Или, может быть, вообще можно обойтись одной строкой в ​​терминале?

Я задал себе этот вопрос на третьем групповом проекте, когда начал каждый раз печатать эти четыре строчки. Что, если мы организуем вызов функции внутри скрипта get_from_common_remote_branch() Или update_common_remote_branch() в зависимости от клавиши командной строки, и для функции push_to_user_remote_branch() также повесить сообщение проверки?

Изучив некоторую информацию о bash-скриптинге, я разобрался, как организовать вызов определенной функции внутри скрипта и как читать аргументы командной строки. Соответственно теперь для работы нужно запускать скрипт с ключом -g (--get)чтобы увидеть текущий статус проекта, или -u (--update) с сообщением коммита в кавычках, чтобы подтолкнуть ваши изменения.

Скрипт duslar.sh
#!/bin/sh

function get_from_common_remote_branch() {
  echo "\033[33m$COMMON_BRANCH\033[32m remote branch last stage getting\033[0m"
  git checkout $COMMON_BRANCH
  git pull  # get latest commit from remote common branch
  git checkout $USER_BRANCH
  git merge $COMMON_BRANCH
  git push origin $USER_BRANCH
}

function push_to_user_remote_branch() {
  echo "\033[33m$USER_BRANCH\033[32m committing and pushing to remote\033[0m"
  shift
  git add .
  git commit -m "$USER_BRANCH: $*"
  git push origin $USER_BRANCH
}

function update_common_remote_branch() {
  echo "\033[33m$COMMON_BRANCH\033[32m remote branch updating\033[0m"
  git checkout $COMMON_BRANCH
  git merge $USER_BRANCH
  git push origin $COMMON_BRANCH
  git checkout $USER_BRANCH
  git push origin $USER_BRANCH
}

function usage() {
  echo "$0: illegal option -- $1"
  echo "usage: sh $0 [--help][-h][man] [--get][-g] [--update \"commit message\"][-u \"commit message\"]"
}

function man_print() {
  echo "
  Team working script.

  usage: sh $0 [--help][-h][man] [--get][-g] [--update \"commit message\"][-u \"commit message\"]

  Use options [--get][-g] for getting $COMMON_BRANCH remote branch last stage.

  Use options [--update][-u] with your commit message (in quotes!) for updating your own and $COMMON_BRANCH remote branches.
  "
}

USER_BRANCH=$(git branch | grep "*" | sed 's/* //')  # sed is Stream EDitor
COMMON_BRANCH=duslar
if [ $1 = --get ] || [ $1 = -g ]
then
  get_from_common_remote_branch
elif [ $1 = --update ] || [ $1 = -u ]
then
  get_from_common_remote_branch
  push_to_user_remote_branch $*
  update_common_remote_branch
elif [ $1 = --help ] || [ $1 = -h ] || [ $1 = man ]
then
  man_print
else
  usage $1
fi

вместо заключения

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

ЧИТАТЬ   Решетников назвал четыре новых приоритета в развитии МСБ

равно

Source

От admin