Вступление
Данная статья не руководство к действию. Компания, где я работаю, часто использует подряд и аутстафф-разработчиков, что бы временно усиливать команды и данный посыл это опыт без шовного взаимодействия. Для разработчиков, которые работают в продукте она вообще бесполезна
В любом технологическом процессе должна присутствовать стандартизация и унификация. Без неё бы не создавались доступные по бюджету товары и услуги
Не судите по статье, что в компании, где я работаю, из стеков технологий используется только Bitrix. Так сложилось, что порог вхождения в Bitrix не особо высок. Это и достижение Bitrix и его недостаток. И именно с Bitrix разработчиками чаще всего приходится решать проблемы с системой контроля версий
Я знаю, что GIT не единственная система контроля версий. Плюс-минус все работает одинаково. Когда новый человек приходит в компанию, то при наличии опыта работы с любой системой контроля версий не составляет труда переключиться на GIT. Мы используем именно GIT
В данной статье я перечисляю лишь самые часто встречающиеся вопросы, которые мы стандартизировали под свои нужды. Именно так они наиболее быстро доходят до разработчиков из распределённых команд. Синхронизация работы команды - вот чего мы добиваемся
Одним только собесом не решить проблемы, которые возникают при работе с системой контроля версий
Git, как технология, прост в изучении — вменяемому разработчику требуется несколько часов и доступ к документации, чтобы понять базовые принципы его работы. Но в реальной жизни — теории недостаточно. Поэтому IT-компании создают простые пошаговые инструкции, чтобы новички быстро и безболезненно вливались в работу, старички работали единообразно и предсказуемо, а тимлиды могли легко управлять этим процессом.
Зачем и о чем эта статья?
В статье поделюсь опытом работы с системой контроля версий. Если ждете руководство по Git-у или пересказ документации — лучше обратиться к первоисточнику. Я же расскажу проблемах, с которыми приходится сталкиваться в реальной командной работе над проектом, при вовлечении новых разработчиков в проект и о том, как эти проблемы решаются в компании где я работаю. Наверняка в студиях, занимающихся заказной разработкой, особенно где присутствуют проекты на техподдержке, введены подобные правила работы.
Проблема первая — время
Нет проблемы обучить (выращивать) штатных сотрудников внутри компании или сторонних подрядчиков. Но на изучение регламента, установку-настройку-выполнение требований требуется определенное количество часов. Хорошо, когда сотрудник или подрядчик постоянный — потратили один раз время и дальше спокойно работаем годами. А если у вас регулярно возникают задачи, для выполнения которых достаточно 4 часов работы разово нанятого фрилансера? Если он привык работать с GIT-ом, проблем нет. Если не умеет/не понимает или спорит, что с GIT тратится еще больше часов — приходится порой тратить больше времени на объяснение, чем на рабочую задачу.
Проблема вторая — у каждого свои привычки
Любой разработчик знает, что существуют задачи (особенно, если ты работаешь один как фрилансер или в небольшой студии, в которой «один проект — один ответственный») когда можно работать без гита. Свои релизы такой разработчик «колхозит» — переименовывает файлы с префиксом даты предрелизного состояния или вставляет надписи «old». Бороться с этим бесполезно. В рамках собственных проектов каждый волен сам решать, как поступить.
Проблемы начинаются, когда эти привычки «вольного художника» входят в соприкосновение с суровыми реалиями большой командной разработки. И тут роль и задача тимлида — не столько донести регламент, сколько убедить в самой необходимости им пользоваться. Расписывать можно долго, но кто не сталкивался — не поверит, кто сталкивался, тот и так поймет.
Я все еще часто слышу упреки разработчиков: «Ну ты же не говорил, как именно надо сделать». Для этого и нужен регламент — определить и зафиксировать принятые правила игры. Предупредить претензии и обиды сотрудников, которых вывели с проекта, или работу которых не принимают.
Любой регламент — это результат опыта. Поскольку у большинства распределенных команд проблемы и ошибки схожи — схожи будут и регламенты. А значит, вынося во внешний мир собственный — можно подтолкнуть «общественное бессознательное» в нужную сторону, и, хотя бы отчасти, решить проблему времени на изучение регламента.
Перед началом работы
Исторически сложилось, что все свои проекты мы ведем на GitLab и «переезжать» куда-то со своими репозиториями не планируем — во-первых, это сложно осуществить в рабочих проектах, где много команд, во-вторых нам просто нравится Гитлаб. Если у вас другая система — это не критично, общие требования идентичны.
Тимлид проекта перед началом работ должен убедиться, что у всех разработчиков есть доступ к удаленному репозиторию проекта.
Штатные сотрудники компании получают доступ ко всем репозиториям. Подрядчикам мы выдаем доступ к конкретным репозиториям, только на срок реализации проекта. Здесь тимлиду нужно не забыть выставить сроки предоставления доступа, т.к. 101% после сдачи проекта забудем удалить доступ подряда.
Алгоритм настройки Git
На общем хосте main (предпрод, тестовая площадка) должна быть включена ветка stage. ВАЖНО! Ветка master используется только для боевого хоста.
Используйте только \n для перехода на новую строку. (укажите в редакторе + в настройке гита)
IDE и редакторы позволяют в настройках выставлять нужный символ конца строки, но неопытные разработчики нередко забывают, что и Git при определенных настройках (автоформатирование при коммите) может его изменить. Если часть команды работает на MacOS, часть на Linux, а часть на Windows — велика вероятность, что в какой-то момент что-то пойдет не так. А потому в регламент мы внесли требование принудительно указывать в IDE и в настройках Git-а единый символ конца строки.
Проверьте, чтобы .gitignore был правильно настроен:
/bitrix/
/bitrix
/upload/
/upload
/local/
/local/vendor/
/web.config
/.htaccess
/robots.txt
/*.xml
*.swp
*.logВ .gitignore добавлены помимо папок /bitrix/ и /upload/ так же файлы /bitrix и /upload, т.к. на площадках для разработки это симлинки. Файл .gitignore может быть изменен и дополнен в зависимости от потребностей проекта.
в GIT не должны попадать отладочные скрипты, логи, медиафайлы регистрируемые в БД и др.
Пункт от капитана Очевидность, но тот, кто сталкивался с необходимостью почистить репо от «это случайно залетело» — обязательно его оценит. В общем, лишний раз напомнить об этом в регламенте — точно не помешает.
Заведите правило: 1 разработчик — 1 хост. Если на проекте должно одновременно работать несколько разработчиков, то количество хостов на проекте должно быть равно количеству разработчиков + 1 (общий хост на который сливаются все изменения)
За личным хостом следит сам разработчик, за общим — тимлид. Это позволит всегда держать руку на пульсе как общего состояния проекта, так и индивидуальных задач каждого разработчика.
Все наработки сначала вливаются в stage, а затем в master. Ничего не должно вливаться сразу в master. Все новые ветки для выполнения новых задач начинаются от текущего stage, если прямо не указано иного (бывают ситуации, в которых лучше ветвиться от master).
Доставкой изменений на бой занимается тимлид на проекте или его старший программист проекта. Также неплохо было бы настроить CI/СD
В нашем полном регламенте помимо тех, кому дано право изменять боевой сервер — прописано и разрешенное для деплоя время. Мы исключили возможность обновлений перед выходными в конце дня, а плановый деплой разрешен только в первой половине рабочего дня. Причины очевидны — если что-то пойдет не так, нужно иметь запас времени на то, чтобы откатиться. Разбираться в причинах можно и потом, но восстановить работоспособность проекта нужно сразу.
Важное замечание: регламент написан для командной работы в нашей компании, но большую часть требований легко можно доработать под себя, даже если вы одиночка-фрилансер. Умение работать по заранее установленным правилам — полезная привычка, которая позволит не забыть важные шаги. Кроме того, это может оказаться серьезным плюс при трудоустройстве или сотрудничестве с другими организациями.
Подготовка к переносу наработок на предпрод для проверки
После выполнения наработок необходимо сделать git pull в текущую ветку из ветки stage (в некоторых случаях master) удаленного основного репозитория и тем самым предотвратить появление конфликтов в удаленном репозитории. Затем пушить ветку с наработками git push в свою же ветку удаленного репозитория
В принципе — ничего нового в этом пункте нет, стандартное предупреждение и разрешение конфликтов в Git-е. Но тимлиду имеет смысл разъяснить этот пункт, особенно если исполнитель удаленный и еще не привык к общим требованиям. За время, что он работал над задачей — в ветке stage могли появиться изменения от других разработчиков, и безопаснее разрешить конфликты в локальной ветке до того, как очередная порция изменений будет запушена в удаленный репозиторий.
В удаленном репозитории нужно создать мерж реквест в stage на тимлида или старшего на проекте, если он отвечает за сливания.
Если на текущем проекте есть отдельный чек-лист — разработчик должен заполнить его, если нет — отметить в комментарии к задаче ссылку на merge request (в некоторых случаях коммит) с наработкой и описанием. Отписать тимлиду или старшему на проекте, если он отвечает за сливания, чтобы проверил работу и принял merge request, либо отправил на доработку.
После того, как все замечания устранены и мерж реквест принят, смотрим работу на основной (тестовой) площадке.
Про ветки и коммиты
Правила именования веток
Даже один только этот пункт — позволяет выработать очень полезную привычку давать веткам имена, которые понятны всем участникам разработки. Название должно содержать номер задачи, в рамках которой выполняется работа и пункт чек-листа. То есть при выполнении задачи, ветка будет выглядеть следующим образом:
ih(os)/номерЗадачи/краткоеОписаниеЗадачи
Ih — значит inhouse, штатный сотрудник
os — outstaff-подрядчик
54361 — обязательно указываем номер задачи
краткоеОписаниеЗадачи — это 2 - 4 слова.
Пример правильно названной ветки:
ih/54361/fixCatalogStyles
В случае, если работа по какой-то причине не привязана к конкретной задаче, именование следующее:
ih(os)/годмесяц/краткоеОписаниеЗадачи
Пример альтернативно названной ветки если нет задачи под неё:
ih/2107/checkoutRefactoring
Правила именования коммитов
Именование коммита должно отражать суть проделанной работы. В наименовании коммита должен присутствовать номер задачи и номер пункта данной задачи.
Пример:
«54361-1 import elements to offers iblock»
где 54361 номер задачи и через тире номер пункта (если в задаче есть отдельные пункты, которые можно считать как самостоятельный функционал).
Правила форматирования кода перед выполнения задачи
Если вам приходится работать с существующим кодом в файле и этот код не правильно отформатирован, то в случае, когда мы будем делать доработку и отформатируем весь код файла, в коммите будет не понятно — что именно изменилось.
Для того, чтобы избежать этой проблемы, надо:
Отформатировать этот файл перед выполнением работ, согласно регламенту написания кода (в PHPStorm можно комбинацией клавиш [CTRL] + [ALT] + L) и закоммитить, при этом в настройках PHPStorm должны стоять верные настройки PSR и версия PHP.
Указать в коммите, что это форматирование
Начать выполнять работу только после коммита с форматированием
Правила работы с версткой и стилями
В нашей компании бэкендеры не правят стили и верстку прямо в back-end минуя исходник верстки. Для работы с версткой используется отдельный репозиторий. Сперва фронтенд-разработчик правит верстку именно в файлах верстки, только потом backend-разработчик ее натягивает. Таким образом исходник верстки всегда актуален.
Перенос наработок на бой
Когда выполненную задачу нужно переносить на бой, алгоритм аналогичен тому, что применялся при деплое изменений на предпрод.
Еще немного про ветки и переносы
Новая ветка должна актуализироваться каждый раз перед стартом выполнения задачи и в нее из ветки предпрода может подтянуться то, что еще нельзя переносить.
Так как в проектах существует очередь правок и у них может быть продолжительное время приемки функционала, для каждого переноса необходимо:
В выполненном пункте задачи перечислить все коммиты (хеши), которые к нему относятся. Также можно помечать коммиты тегом. (Есть и другие способы ничего не терять при переносе. Я выбрал именно перечисление коммитов, потому что для большинства разработчиков он наиболее понятен).
Чтобы предотвратить появление конфликтов и багов из-за пересечений в коммитах. Осуществлять перенос на бой нужно цельными логически завершенными блоками, а не отдельными его частями.
Перенос надо осуществлять релизными ветками, в которые вливаются все коммиты с наработками, вида:
release/20210408, где 20210408 — сегодняшняя дата
Если мы не хотим вливать целую ветку, а хотим подтянуть только один коммит, то можно воспользоваться командой:
git cherry-pick коммит
Если переносимого коммита нет в вашем локальном git, то надо сперва подтянуть изменения из других веток к себе
git fetch origin
git fetch — забирает данные в ваш локальный репозиторий, но не вливает их в вашу ветку. То есть коммиты из других веток придут к вам на площадку, но так же останутся в других ветках. В итоге удобно мержить и проводить код-ревью используя IDE.
Дополнение, которое может облегчить жизнь
Иногда приходит проект от заказчика, где под GIT загнали все файлы, включая те, которых там вообще быть не должно. К боевому сайту нет доступа и какие-либо изменения по этим файлам категорически нельзя отправлять в репозиторий. Например, robots.txt, sitemap.xml и другие файлы и каталоги.
Что бы выкрутится из этой ситуации мы на своих площадках, можем делать так:
Перестать отслеживать изменение одного файла:
git update-index --assume-unchanged <file>
Перестать отслеживать целую директорию:
git ls-files -z <dir>/ | xargs -0 git update-index --assume-unchanged
После этого GIT не будет реагировать на какие-либо изменения в этом файле или директории.
Чтобы отменить это поведение, выполните следующее:
Для файла:
git update-index --no-assume-unchanged <file>
Для директории:
git ls-files -z <dir>/ | xargs -0 git update-index --no-assume-unchanged
В процессе разработки есть проблема не только с тем, что кто-то не знает как работать с GIT, но и с тем, что все делают, как им нравится, или кажется, что так правильнее. Основной позыв этой статьи — стандартизация/унификация основных проблемных мест при работе с GIT в процесса разработки. Нельзя допускать ситуацию «кто в лес, кто по дрова».
