Организация хранения кода в GitLab и интеграция код ревью в GitFlow

[Ordinatus]

Есть несколько важных нюансов:

Для запроса на слияние разработчик разрешает конфликты слияния (в случае наличия)

Решать конфликты можно только локально из-за бага Gitlab, который делает еще и бэкмерж.

Вся политика слетает в первую неделю, если нет update гит хуков, которые проверяют всё — именование, исходную и целевую ветку слияния. Проверить именование можно только простой регулярочкой, типа такой:
^(refs\/heads\/)?(dev|master|private\/.+|feature\/.+|bugfix\/PX-[0-9]+|hotfix\/PX-[0-9]+|release\/[0-9]+\.[0-9]+\.[0-9]+(\.[0-9]+)?)

Здесь не лишним является установка флага удаления ветки после слияния – в противном случае количество веток может быстро разрастись до неприличных масштабов.

Чистить придется всё равно. Это можно сделать вручную через веб интерфейс, отсортировав бранчи по дате или простой коммандой в две строки:

for branch in $(git branch -r | grep -Ev \'origin/release\' | grep -Ev \'origin/master\'); do if [[ "$(git log $branch --after "60 day" | wc -l)" -eq 0 ]]; then echo $branch | sed -e \'s:origin/::g\' >> ../for_delete_now.txt; fi; done

Проверить всё ли ок по удаляемым веткам в for_delete_now.txt и не удалим ли мы лишнего и далее:

cat ../for_delete_now.txt | while read branch; do git push origin --delete $branch; done; git remote prune origin

Такая схема очень быстро обрастает энтропией и ломается, если её не поддерживать.
К тому же гитлаб имеет очень странные баги, которые не исправляются годами и ломают некоторые моменты, например резолв конфликтов слияния, которые можно нормально сделать только локально, но сам МР только через веб, если нет руби. Пришлось переписывать МР на bash+curl через API что бы оно работало у разработчиков из CLI не затаскивая руби.

[JenoOvchi]

Спасибо большое за ценные дополнения!
На счёт конфликтов — двояко: большая часть доступна для решения из GUI, но попадаются такие, которые можно решить только локально.

[koropovskiy]

бекмерж не является багом как таковым. Это нормальный способ решения конфликтов, если ветка отводилась от той же ветки в которую сливается.
Лучше конечно они бы делали промежуточную ветку, где решался бы конфликт, но уж что имеем.

При чистке полезно бывает проверить, что ветка уже слита. Например так:

git branch --list --remotes origin/* --merged=origin/master

Удалять можно не git командами, а через GitlabAPI, в моем случае это оказалось быстрее раза в 3.

[Ordinatus]

То ли у меня кривой инстанс (self-hosted не под моим управлением) то ли это баг, но API в этих эндпоинтах не стабилен.
Проверку на мерж не делаю, потому что если прошло 2 месяца с последнего коммита, то ветку так и так надо удалять.

[gecube]

Ишью в трекере гитлабу соответствующие, надеюсь, созданы? Движение по ним есть ?

[gecube]

JenoOvchi я силюсь и пытаюсь понять: какое тут ноу-хау? Или зря? Или это просто описание Вашего подхода (и не более)?

[JenoOvchi]

Приветствую!
По сути да — описание получившегося подхода.
Когда я брался за эту задачу, то стал искать готовые варианты модели работы с Git, включавшие бы в себя ревью кода, и мне они не попались. Поэтому, когда мы пришли к более-менее рабочему варианту, я систематизировал получившийся материал и решил поделиться.
З.Ы. Для контроля скинул текст паре человек на ревью — им показалось интересно :)

[chuvashin]

Процесс GitFlow реализует, в целом, всё необходимое. Один момент, который мне пока не удалось решить это непрерывность разработки в некоторых случаях. Например, случай когда создаётся ветка с новым функционалом, потом он закончен и отправляется запрос на code review. Какое-то время занимает тестирование и проверка, потом только разработчик получает feedback. В это время разработчик конечно может продолжить работу и начать новую ветку с новым функционалом. Но возникают вопросы когда в новом функционале нужен код из предыдущей ветки, а он ещё согласовывается и проверяется. Из-за этого разработчику надо либо ждать, либо как-то пробовать начать работу с уже изменёнными файлами и потом заниматься решением конфликтов при слиянии. В итоге пока так и не придумали как такие случаи правильно решать. Может быть у кого-то уже был подобный опыт?

[koropovskiy]

Был. Выходят по разному. Мне нравится вариант отведения новой фичи от старой.
тогда в реквесте новой фичи видно попала ли старая уже в dev или нет.
Но в других командах вижу что ведут «спринт-ветки» или что-то подобное, что в dev попадает уже бОльшим куском чем «одна фича».

Впрочем все равно это плохие кейсы, т.к. при провале Code-Review возможно придется исправлять и старую фичу и новую, на нее завязанную.