Репозиторий, Ветка, Merge Request
Категории: Инструменты
Этот спринт содержит технические детали процесса разработки. Поэтому, дам вам дополнительные примеры, на которые вы можете обратить внимание. Посмотреть, как выглядит репозиторий, что пишут разработчики (как они пишут - вы уже видели).
Покажу примеры проектов на платформах для хранения кода - GitHub и Gitlab. Этими платформами может пользоваться кто угодно, при условии если код будет полностью открыт для просмотра, чтобы можно было его изучать и улучшать
- Репозиторий - это место, где хранится код продукта. В рамках продукта, таких репозиториев может быть много. Вы можете перейти по ссылке, посмотреть реальный проект, как организована структура кода и почитать его :)
- Разработчики ведут разработку в разных ветках. Ветка - это отдельная версия кода, которая может развиваться независимо (например, чтобы создать фичу) и после того, как она закончена - она может быть слита в основную ветку. Жизнь кода в ветке принято показывать в виде графа. Вот пример одной из веток кода:)
- Процесс слияния одной ветки с другой - называние Pull Request или Merge Request (в зависимости от платформы). Пример одного Pull Request’a. Разработчики описывают суть изменений, обмениваются опытом с другими разработчиками, вместе улучшают код и получаю одобрение (Approve). Если Pull Request апрувнут - его можно завершить и код попадет в основную ветку (попробуйте найти из какой ветки и в какую будет перемещен код в этом pull request’e?)
- Когда разработчик хочет зафиксировать состояние кода - он делает Коммит (Commit). Коммит - это порция кода, которая изменяет текущее решение. Фактически, каждый коммит отражает состояние продукта в отдельный момент времени. Коммитов может быть бесконечное множество. Как правило, все коммиты делаются в свою ветку и после Pull request’a переносятся в основную ветку. Вот пример нескольких коммитов в одном Pull Request’e
- Когда кто-то находит баги в коде - разработчики создают Issues. Где так же, как и вы, описывают условия найденного бага, ожидаемое состояние и результат. Вот хороший пример. По каждому Issue идет обсуждение, фиксируются исправления.
- Работа команд в таких публичных проектах ведется на досках, где собраны все issues, с которые идет сейчас работа. Хороший пример доски. Как видите, колонки отличаются от предложенного вам в теории, поскольку команда в конечном итоге, сама решает какой процесс она будет использовать и какие этапы будут использовать. Еще один пример доски команды JetBtrains в Youtrack - больше напоминает то, о чем мы рассказываем в курсе.
И последнее, компания gitlab, разрабатывает продукт GitLab и они придерживаются принципа открытости. Например, они в онлайне проводят их встречи - ретроспективы, планирования или решение инцидентов. Все записи доступны на youtube. Вот пример того, как команда проводит синхронизацию недельную или standup (3 минуты). Все ссылки на английском, извините :)
Все посты написаны мной. Если вам интересно узнать больше, подписывайтесь на мою рассылку о менеджменте. Один-два раза в месяц я пишу статьи о разных аспектах проектного управления или менеджмента в целом. Или вы можете просто написать мне :)