2. Работа с ветками
Last updated
Last updated
2.1. Для каждой задачи создаётся отдельная ветка
2.2. Перед созданием своей ветки необходимо переключиться на основную ветку проекта master, получить последние изменения с центрального репозитория, после чего создать свою ветку из master ветки
2.3. feature/xxxx ветки создаются для работы над поставленными задачами, где xxxx - номер задачи
2.4. hotfix/dd-mm-yyyy_hh-mm ветки создаются для исправления ошибок, обнаруженных самим разработчиком, без постановки задачи
2.5. Если поставлено несколько задач, которые связаны с одной и той же частью сайта (например с новостями сайта), то они точно так же выполняются в отдельных ветках, а не в одной
Git хранит историю разработки проекта, разбивая её на некоторые ключевые точки - коммиты. В самом простом случае, история развития проекта выглядит как ряд ключевых точек, которые следуют друг за другом и объединены в одну линию
Но так же он позволяет отклониться от основной линии разработки и продолжить работу в отдельной ветке, независимо от основной. Это и называется ветвлением. Фиолетовые и зеленые линии — это ветки.
По окончанию работы в отдельной ветке, ее можно будет слить обратно в основную, и все коммиты, сделанные в отдельной ветке так же появятся и у основной.
В нашей работе так же используется ветвление, где главная ветка называется master. Код из этой ветки располагается на боевых сайтах.
Работа над задачами же происходит в отдельных, feature ветках, которые создаются ответвлением из master.
Так же есть ветка develop, код которой располагается на тестовых (dev) версиях сайтов. Если задача подразумевает обязательное тестирование, то прежде чем код будет залит в master ветку, он вначале заливается в develop и проверяется на тестовом сайте.
Если бы над проектом работал всего один человек, то ему было бы достаточно всего одной ветки - master. Но у нас над одним проектом может работать сразу несколько разработчиков, и работа в одной ветке будет крайне неудобной.
Во первых, прежде чем отправить свой коммит в GitLab, придется сначала получить все последние изменения от других разработчиков. Во вторых, после получения изменений могут возникнуть конфликты (если два или более разработчиков правили один и тот же файл), который нужно будет обязательно разрешить. И только потом можно повторить команду и отправить свой коммит в GitLab. Не слишком ли много действий для отправки всего одного коммита?
Чтобы уменьшить количество таких столкновений и не мешать друг другу работать, каждый разработчик должен работать в отдельной ветке.
Почему для каждой задачи нужна отдельная ветка, вместо того, чтобы работать в одной? Попробуем разобраться. Допустим, разработчику поставлено три задачи:
1001 Изменение верстки шаблона у компонента новостей
1002 Исправление ошибок в футере сайта
1003 Редактирование страницы "о компании"
Разработчик создал одну ветку и решил все три задачи выполнить в ней. Он уже выполнил задачу 1001 по изменению верстки шаблона, исправил ошибки в футере по задаче 1002 и сейчас работает над задачей 1003, редактирует страницу "о компании".
Внезапно, заказчику стало нужно, чтобы задача по исправлению ошибок в футере (1002) срочно оказалась на боевом сайте. Если сейчас слить ветку разработчика с основной веткой сайта (master), то мы окажемся в ситуации, когда задача по изменению верстки (1001) попадет на боевой сайт раньше времени, да еще и страница "о компании" (1003) там будет в ужасном виде, так как разработчик еще не закончил над ней работу.
Кроме этого, в процессе работы было изменено много файлов (так как сразу три задачи решаются в одной ветке), а прежде чем код будет доставлен на боевой сайт, он должен пройти Code Review. В таком большом объеме кода проверяющий может просто утонуть и легко пропустить потенциальную ошибку, которая может поломать сайт.
Поэтому, чтобы таких ситуаций не возникало, и проверяющему было легче ревьюить код, на каждую задачу необходимо создавать свою, отдельную ветку.
master), получить последние изменения с центрального репозитория, после чего создать свою ветку из master веткиВетки для решения задач создаются путём ответвления от главной ветки проекта — master. Поэтому, вначале необходимо убедиться, что мы находимся на главной ветке, а если нет, то переключиться на неё — git checkout master
Так же стоит получить последние изменения — git pull origin master. Если этого не сделать, то есть вероятность, что вы будете работать с устаревшим кодом и вносить в него правки. А когда зальете изменения в GitLab и создадите Merge Reauest, то с удивлением обнаружите множество конфликтов, которые вам же и придется разрешать.
feature/xxxx ветки создаются для работы над поставленными задачами, где xxxx - номер задачиДля создание своей ветки можно воспользоваться командой git checkout -b feature/xxxx которую необходимо выполнить находясь на ветке master.
Номер задачи можно указан как на самой карточке в planfix, так и в самой задаче
hotfix/dd-mm-yyyy_hh-mm ветки создаются для исправления ошибок, обнаруженных самим разработчиком, без постановки задачиЕсли возникла такая ситуация, что был обнаружен баг, который вы хотите подправить, но отдельной задачи для его исправления нет, то можно создать ветку hotfix
git checkout -b hotfix/dd-mm-yyyy_hh-mm, где dd-mm-yyyy - текущий день, месяц и год, а hh-mm — текущие час и минуты. Возможно, вариант с датой и временем не самый лучший, однако, это сделано для того, чтобы два разработчика случайно не создали две ветки с одинаковым названием.
Ранее, ветки hotfix просто нумеровались - hotfix/1, hotfix/2, hotfix/3... Но при такой системе возникали ситуации, когда два разработчика, работая над одним и тем же проектом, отправляли одну и ту же ветку hotfix/1 в GitLab. Кто отправил раньше — тому повезло и она заливалась, кто отправил позже — очень жаль. Приходилось переименовывать ветки с hotfix/1 на hotfix/2 и пробовать отправить снова, но могло опять не повезти, ибо ветка hotfix/2 тоже могла существовать. К тому же, при таком именовании один разработчик мог затереть изменения другого разработчика, что и случалось.
Может возникнуть ситуация, когда будет поставлено несколько задач, которые будут связаны друг с другом. Например по редактированию одного и того же файла, допустим шаблона для страницы новостей:
1001 Разработать новый шаблон для компонента вывода новостей
1002 Выводить на странице детальной новости рекламный блок
1003 Выводить на странице списка новостей рекомендации статей из блога
То есть, для того, чтобы приступить к выполнению задачи 1002 (вывести рекламный блок на странице детальной новости) сначала нужно
завершить работу над задачей 1001 (разработать новый шаблон страницы новостей)
пройти Code Review
слить ветку задачи 1001 с главной веткой,
И только после этого можно будет создать новую ветку из главной для выполнения задачи 1002. Процесс получается не очень быстрым, но он необходим для того, чтобы проверяющий на Code Review не утонул в большом количестве изменений в коде. Если вам попались такие связанные задачи, то можно попросить проверяющего пораньше выполнить проверку и слить вашу ветку с веткой master, чтобы можно было продолжить работу.
