Ясли 21: первые шаги в командной разработке

Введение

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

Peer-to-peer

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

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

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

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

• работай в своей ветке и в своей папке;

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

• перед пушем в репозиторий запускай скрипт get, потом создавай коммит и запускай скрипт update

• окончательный вариант проекта собирается из общей ветки и пушится на ветку develop (школьный prod)

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

Выделил время и сел разбираться с темой ветвления в Git и утилитой 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  # пушим этот коммит на личную ветку.

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

#!/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

#!/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) с сообщением коммита в кавычках, чтобы запушить свои изменения.

#!/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 подойдёт для реальной разработки, но на первых порах она нам позволила не думать о хранении и использовании командного кода и сосредоточиться на написании проектов.

peer-to-peer