Работаем со связанными ветками в Git

Наткнулся на любопытную статью о работе с ветками в гите во время разработки фичи, и как это дело можно упростить. Но обо всём по порядку.

Автор предлагает делить работу над задачей на несколько логически связанных частей. Каждая часть оформляется в виде отдельной ветки и сопровождается merge request-ом. При этом каждая ветка бранчуется от предыдущей. Например, feature-xyz/part-2 от feature-xyz/part-1, а feature-xyz/part-3 от part-2. Получается такой стек из веток.

Такой подход позволяет упростить ревью – каждый MR охватывает минимальный объем изменений, и создать историю коммитов, которая позволит читать изменения кода по шагам, понимая логику их внесения.

И всё выглядит хорошо до тех пор, пока не нужно внести изменения в part-1 по результатам ревью, а потом влить эти изменения в ветки part-2 и part-3. Или когда в основной dev-ветке появятся изменения, нужно также их затащить во все свои маленькие веточки. Тут приходит на помощь rebase со всеми сопутствующими приседаниями.

Чтобы избежать приседаний, автор предлагает решение: использовать опцию --update-refs команды rebase. В этом случае при ребейзе самой последней вашей ветки git сам обновит все родительские ветки.

Что думаете за такой подход? Выглядит замороченно, плюс нужно иметь высокую культуру в команде, чтобы все следовали договорённостям. По ощущениям, если пилите что-то действительно сложное и большое, когда в проекте много участников и важно ориентироваться в изменениях – выглядит жизнеспособно.

#skills #teamwork