Git: Контроль версий в процессе работы программиста

Как на самом деле организован процесс работы от получения задачи до заливки на хостинг, и почему «ревью кода» — это лучшее что может случиться в жизни каждого программиста)

Постановка задачи

Вы должны знать к моменту начала работы 1) какая функциональность должна быть реализована 2) где 3) с помощью чего. Чем больше у Вас опыт тем менее подробный будет описательный момент, но в начале решение задачи должно быть однозначным и для Вас, и для заказчика / менеджера / клиента

Плохой пример: картинки на сайте неправильного размера

Хороший пример: картинки на сайте (урл, скриншот с обведенной картинкой) в некорректном размере — правильный размер 600 на 300 пикселей. Проверить обрезку картинок, если такой картинки нет — создать, если она есть, но используется неправильно / не используется — починить шаблон (если программист первый раз в проекте — то даже стоит указать файл шаблона).

Для больших команд удобно использовать таск менеджеры (любые! главное чтобы все в команде считали его удобным или как минимум не страдали при использовании), для маленьких — хотя бы общий документ в гугл-доках.

Выкачка репозитория

Если программист первый раз работает с проектом — ему нужно создать локальную копию, для этого используем git clone, например git clone https://user@bitbucket.org/user/repo.git. У Вас чудестным образом появится папка с проектом (можно еще тестовую базу туда ложить, чтобы программист локально мог развернуть сайт только из репозитория.

Актуальное обновление

Если программист уже работал (у него есть репозиторий), то выкачиваем все актуальные обновления git pull.

Наш вариант — вариант с одной веткой

Мы работаем в одноветочной схеме (можно почитать про различия и опыт монстров вроде http://blog.bronevichok.ru/2015/04/26/engineering-at-booking.com.html). Это означает что в главной ветке репозитория всегда рабочий код, а личные ветки и их использование — личное дело каждого.
Поэтому при желании делаем ветку, при маленькой задаче — вообще не переживаем. Начали работать и сделали все как надо (пофиксили шаблон правильно, если брать задание примера)

Сохранение работы

Поработав и проверив свой код — делаем сохранение git commit. В комментариях кратко описываем что было сделано (например, номер задачи, заголовок или описание исправленного бага). Просто сохраненный результат никто еще не видит — Вы можете подумать и еще что-то исправить, сделать несколько сохранений.

Отправка работы

Вы хотите чтобы все получили Ваш код? пора его отправлять! Для этого вторая команда — git push. Если Вам прилетела ошибка — значит кто-то успел изменить репозиторий между Вашей последней выкачкой и этим моментом, поэтому в начале делаем опять синхронизацию (пулл), проверяем нет ли конфликтов (клиент поругается определенным образом, как решать такое — в следующих заметках), и отправляем снова.

Авторазвертывание

У нас на многих проектах (большинстве) настроено автоматическое развертывание из репозитория на тестовый сайт, поэтому идем туда и смотрим как работает все на последних данных и «вживую». Еще тут чуть тестирования автоматического приплетется — но это тоже позже в заметках «Автоматическое тестирование простыми словами»). Ни на одном живом сайте нельзя делать авторазвертывание без тестирования!!!! (см. картинку)

Ревью

Мы используем Битбакет как основной внешний сервер для репозиториев, поэтому с удовольствием постановщик задачи / старший программист / просто второй программист (привет парному программированию) читает Ваши изменения и прямо там может указать ошибки. Поверьте — нет ничего лучше, чем развитие на живом примере и в живом коде. Чтение чужого кода поможет Вам узнать логику приложения, а чтение Вашего — найти незамеченные Вами проблемы или улучшить общий стиль/архитектуру проекта.

Оставить комментарий

XHTML: Вы можете использовать такие теги: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> <pre lang="" line="" escaped="" cssfile="">