Работа с ветками

Долгоживущие ветки

Так как в Git применяется простое трехстороннее слияние, ничто не мешает многократно объединять ветки в течение длительного времени. То есть у вас может быть несколько постоянно открытых веток, применяемых для разных этапов цикла разработки. Содержимое некоторых из них будет регулярно вливаться в другие ветки.

Многие разработчики, использующие Git, придерживаются именно такого подхода, оставляя полностью стабильный код только в ветке master. При этом существует и параллельная ветка с именем develop или next, служащая для работы и тестирования стабильности. После достижения стабильного результата ее содержимое вливается в ветку master. Эта ветка develop используется для вливания в нее завершенных задач из тематических веток (временных веток наподобие feature/issue-53), чтобы гарантировать, что эти задачи проходят тестирование и не вносят ошибок.

По сути, вы рассматриваете указатели, перемещающиеся по линии фиксируемых нами изменений. Стабильные ветки находятся в нижнем конце истории коммитов, а самые свежие наработки — ближе к ее верхней части.

В общем случае можно представить набор рабочих накопителей, в котором наборы коммитов перемещаются на более стабильный уровень только после полного тестирования.

Число уровней стабильности можно увеличить. В крупных проектах зачастую появляется ветка proposed или pu (proposed updates), объединяющая ветки с содержимым, которое невозможно включить в ветку develop или master.

Фактически каждая ветка представляет собственный уровень стабильности. Как только он повышается, содержимое сливается в ветку, расположенную ниже. Разумеется, можно и вообще обойтись без долгоживущих веток, но зачастую они имеют смысл, особенно при работе над большими и сложными проектами.

Тематические ветки

А вот такая вещь, как тематические ветки, полезна вне зависимости от величины проекта.

Тематической называется временная ветка, создаваемая и используемая для работы над конкретной функциональной возможностью или решения сопутствующих задач. Скорее всего, при работе с другими системами контроля версий вы никогда ничего подобного не делали, так как там создание и слияние веток это затратные операции. Но в Git принято много раз в день создавать ветки, работать с ними, сливать их и удалять.

Пример тематических веток вы видели в предыдущих разделах, когда создавали ветки feature/issue-53 и bugfix/bug-135. Для каждой из них было выполнено несколько коммитов, после чего сразу же после слияния с основной веткой они были удалены. Такая техника позволяет быстро и радикально осуществлять переключения контекста. Работа разделена по уровням, и все изменения в конкретной ветке относятся к определенной теме, а значит, во время просмотра кода проще понять, что и где было сделано. Ветку с внесенными в нее изменениями можно хранить минуты, дни или даже месяцы, и выполнять ее слияние, только когда это действительно требуется, независимо от порядка создания веток в рамках проекта и порядка работы с ними.

Предположим, вам больше нравится второй вариант решения задачи (feature/issue-91v2), а ветку feature/dumbidea вы показали коллегам, и оказалось, что там содержится гениальная идея.

Фактически вы можете удалить ветку feature/issue-91 (потеряв коммиты fcdbe86 и e1de40a) и слить две другие ветки.

После этого история будет выглядеть так.

Более подробно допустимые варианты рабочих схем для проектов рассматриваются в разделе Распределенный Git, поэтому перед выбором схемы обязательно прочитайте эту главу. Важно помнить, что во время всех этих манипуляций ветки полностью локальны. Ветвления и слияния выполняются только в репозитории Git, связь с сервером не требуется.