Comments 10
Есть несколько важных нюансов:
Решать конфликты можно только локально из-за бага Gitlab, который делает еще и бэкмерж.
Вся политика слетает в первую неделю, если нет update гит хуков, которые проверяют всё — именование, исходную и целевую ветку слияния. Проверить именование можно только простой регулярочкой, типа такой:
Чистить придется всё равно. Это можно сделать вручную через веб интерфейс, отсортировав бранчи по дате или простой коммандой в две строки:
Проверить всё ли ок по удаляемым веткам в for_delete_now.txt и не удалим ли мы лишнего и далее:
Такая схема очень быстро обрастает энтропией и ломается, если её не поддерживать.
К тому же гитлаб имеет очень странные баги, которые не исправляются годами и ломают некоторые моменты, например резолв конфликтов слияния, которые можно нормально сделать только локально, но сам МР только через веб, если нет руби. Пришлось переписывать МР на bash+curl через API что бы оно работало у разработчиков из CLI не затаскивая руби.
Для запроса на слияние разработчик разрешает конфликты слияния (в случае наличия)
Решать конфликты можно только локально из-за бага 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 не затаскивая руби.
0
Спасибо большое за ценные дополнения!
На счёт конфликтов — двояко: большая часть доступна для решения из GUI, но попадаются такие, которые можно решить только локально.
На счёт конфликтов — двояко: большая часть доступна для решения из GUI, но попадаются такие, которые можно решить только локально.
0
бекмерж не является багом как таковым. Это нормальный способ решения конфликтов, если ветка отводилась от той же ветки в которую сливается.
Лучше конечно они бы делали промежуточную ветку, где решался бы конфликт, но уж что имеем.
При чистке полезно бывает проверить, что ветка уже слита. Например так:
Удалять можно не git командами, а через GitlabAPI, в моем случае это оказалось быстрее раза в 3.
Лучше конечно они бы делали промежуточную ветку, где решался бы конфликт, но уж что имеем.
При чистке полезно бывает проверить, что ветка уже слита. Например так:
git branch --list --remotes origin/* --merged=origin/master
Удалять можно не git командами, а через GitlabAPI, в моем случае это оказалось быстрее раза в 3.
0
UFO just landed and posted this here
Ишью в трекере гитлабу соответствующие, надеюсь, созданы? Движение по ним есть ?
0
Приветствую!
По сути да — описание получившегося подхода.
Когда я брался за эту задачу, то стал искать готовые варианты модели работы с Git, включавшие бы в себя ревью кода, и мне они не попались. Поэтому, когда мы пришли к более-менее рабочему варианту, я систематизировал получившийся материал и решил поделиться.
З.Ы. Для контроля скинул текст паре человек на ревью — им показалось интересно :)
По сути да — описание получившегося подхода.
Когда я брался за эту задачу, то стал искать готовые варианты модели работы с Git, включавшие бы в себя ревью кода, и мне они не попались. Поэтому, когда мы пришли к более-менее рабочему варианту, я систематизировал получившийся материал и решил поделиться.
З.Ы. Для контроля скинул текст паре человек на ревью — им показалось интересно :)
0
Процесс GitFlow реализует, в целом, всё необходимое. Один момент, который мне пока не удалось решить это непрерывность разработки в некоторых случаях. Например, случай когда создаётся ветка с новым функционалом, потом он закончен и отправляется запрос на code review. Какое-то время занимает тестирование и проверка, потом только разработчик получает feedback. В это время разработчик конечно может продолжить работу и начать новую ветку с новым функционалом. Но возникают вопросы когда в новом функционале нужен код из предыдущей ветки, а он ещё согласовывается и проверяется. Из-за этого разработчику надо либо ждать, либо как-то пробовать начать работу с уже изменёнными файлами и потом заниматься решением конфликтов при слиянии. В итоге пока так и не придумали как такие случаи правильно решать. Может быть у кого-то уже был подобный опыт?
0
Был. Выходят по разному. Мне нравится вариант отведения новой фичи от старой.
тогда в реквесте новой фичи видно попала ли старая уже в dev или нет.
Но в других командах вижу что ведут «спринт-ветки» или что-то подобное, что в dev попадает уже бОльшим куском чем «одна фича».
Впрочем все равно это плохие кейсы, т.к. при провале Code-Review возможно придется исправлять и старую фичу и новую, на нее завязанную.
тогда в реквесте новой фичи видно попала ли старая уже в dev или нет.
Но в других командах вижу что ведут «спринт-ветки» или что-то подобное, что в dev попадает уже бОльшим куском чем «одна фича».
Впрочем все равно это плохие кейсы, т.к. при провале Code-Review возможно придется исправлять и старую фичу и новую, на нее завязанную.
0
Sign up to leave a comment.
Организация хранения кода в GitLab и интеграция код ревью в GitFlow