Работни процеси на Git: Пребазиране на публикувани/споделени клонове

Нашият екип по време на работа с ентусиазъм възприе работен процес за пребазиране, но може би сме се увлекли малко, което е смисълът на този въпрос: вие сте съдията.

Използването на pull --rebase сега е безсмислено за мен. Имаме обаче и големи разклонения с функции, върху които работят много хора. Периодично искаме да внасяме промени, които се случват на master. Конвенционалната мъдрост би ни накарала да се слеем, тъй като това е споделен клон. Въпреки това, в нашата мания за пребазиране, ние решихме да пребазираме тези клонове. Разбира се, това изисква сътрудничеството на всички. Работният процес протича по следния начин:

1) Rebaser се координира с всички, за да се увери, че всички са чекирани и изпратени в клона на функцията, след което ги моли да не извършват повече работа по този клон, докато не изчистят всичко.

2) Rebaser пребазира клона на функцията към master, изтрива клона на отдалечената функция (git push origin :feature) и след това избутва новия, пребазиран клон на функция (git push origin функция)

3) Rebaser има всеки fetch, който актуализира техния клон на функция, след което изтрива техния локален клон на функция (git branch -D функция), след което създава нов локален клон на функция, който проследява отдалечения клон на функция. След това всички получават всичко ясно.

Този работен процес работи, отчасти защото сме малка група и прекъсванията в работата са малки. Притеснявам се обаче, че научаваме лоши навици на Git (пребазиране на споделен клон) или че работният процес няма да се мащабира добре.

От друга страна, историята на нашето хранилище е прекрасна.

Какво мислите, гурута на Git? Играем ли си с огъня или разклащаме разумен работен процес?

АКТУАЛИЗАЦИЯ:

Изминаха две години, откакто първоначално зададох въпроса и оттогава работният ни процес се промени. Все още правим рутинно git pull --rebase, така че това не се е променило. Това е здрав разум и предотвратява всички грозни, объркващи минисливания. (Ние поддържаме предимно синхрон, така че има малко разходи за git pull --rebase).

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

Нашето решение има няколко компонента:

• Главният клон е "девствен". Тематични клонове се обединяват и след като го направят, тематичният клон се оттегля. С други думи, сливането на тематичен клон в означава, че тази работа е готова за производство и сега е част от главния клон. Разглеждайки нашата история на версиите, е много ясно какво се случва: тематични клонове се обединяват в главния и това е.

• Използваме интеграционни клонове за еднократна употреба, когато е необходимо. Например, ако имаме тематични клонове A, B и C и никой от тях не е готов за интегриране в master, но трябва да ги тестваме заедно, ние просто създаваме QA клон (обикновено извън master) и след това се сливаме A, B и C в. В даден момент QA клонът се изтрива или използва повторно. Въпросът е, че той не е предназначен да бъде постоянен по никакъв начин и няма същите ограничения като главния клон (можете да се сливате във вашите тематични клонове толкова пъти, колкото искате). Ако историята стане твърде объркваща, можете просто да изтриете QA клона и да започнете отначало (подход, който открихме за много естествен).

• При сливане винаги използвайте git merge --no-ff. Това е толкова огромен обрат от нашата мания за „линейна история на ангажименти“ от преди две години, че заслужава коментар. Сега, след като се отпуснахме по отношение на линейната история на ангажименти и видяхме, че сливанията са добри и полезни, започнахме да разчитаме на тематичните разклонения, които са действителни разклонения извън главния , а не просто поредица от ангажименти, които в крайна сметка стават едно с master. git merge --no-ff гарантира, че винаги има ангажимент за сливане, дори когато не е необходимо.

• Имаме добре разбрана конвенция за съобщения за ангажименти и разклонения и, което е по-важно, тя прави кръстосани препратки към нашата система за проследяване на проблеми. Нашата система за проследяване на проблеми използва числови номера на проблеми и за всяка функция (или дефект) имаме номер на проблема (1234, например). Ако работите върху този проблем, бихте създали разклонение _1234 и да започнете всяко съобщение за ангажиране с "_1234: doing blah blah". Може да изглежда малко обсебващо, но наистина работи добре за нас и значително намали/елиминира объркването.

• Използвайте git обвивка, за да насърчите адхезията на работния процес. Това е нещо, върху което в момента работим, но осъзнахме, че е напълно необходимо, за да предотвратим прости и разбираеми грешки, като разклоняване на грешното нещо (наскоро претърпяхме пълна катастрофа, когато разработчик създаде тема, разклонена от еднократна употреба QA клон: този тематичен клон беше одобрен да се активира, беше обединен...и куп чейнджъри, които не бяха одобрени да се активират, бяха засмукани). Нашата git обвивка ще изисква потвърждение всеки път, когато правите нещо необичайно (като създаване на клон от нещо друго освен master, създаване на клон без име _NNNN, извършване на ангажимент, който не започва с _NNNN и т.н.). Понякога се налага да правим тези неща, така че обвивката не го пречи, но предпазва хората случайно да направят нещо, което не трябва.