Обединяването на развойния клон в главния не е това, което си представях

Ние използваме опростена версия на Git flow, където по-голямата част от работата ни отива директно върху разработката и само по време на пускането се сливаме обратно в master.

Току-що направихме първото си издание и като такъв това беше първият ми път, когато сливах разработка обратно в master, тъй като първо създадох главния клон в началото и разклоних разработката от него.

Това, което си представях, беше единичен ангажимент, обединен обратно към основния клон, по такъв начин, че ако по-късно извадя master в чиста папка, щях да видя само оригиналния комит и новия ангажимент за издание. Вместо това виждам цялата хронология на ангажиментите на клона за разработка в моята хронология на главния клон.

Разбирам защо е така. В края на краищата това са само 2 обединени клона и сливането с бързо превъртане напред просто би притиснало master до върха на моя клон за разработка. Но не е това, което си представях. Струва ми се странно да проверя главния клон и да мога да видя цялата история на цялата работа, довела до него от друг клон.

Откривам, че обмислям, в този случай, защо поддържаме както клоновете за разработка, така и за главния, ако така или иначе просто ще ги обединим заедно, ще видим една и съща история и ще използваме тагове, за да посочим освободени ангажименти (ние сме малка компания) ?

Така ли го правят повечето хора? Това правилно ли е (знам, че това е зареден въпрос)? Или хората се отнасят към master различно от всички други клонове и може би правят squash merge или no-ff merge, за да създадат по-чиста история на master клонове?


git merge branch master
person Dave Ludwig    schedule 08.09.2020    source източник
comment
git flow изисква сливания без превъртане напред. За да видите само историята на първия родител, добавете --first-parent към вашите заявки за история.   -  person jthill    schedule 08.09.2020

Отговори (1)


arrow_upward
2
arrow_downward

Ако използвате работен процес, вдъхновен от gitflow, вероятно искате да използвате опцията --no-ff при сливане.

git checkout master
git merge --no-ff dev

Това налага ангажимент за сливане, дори ако иначе би било възможно бързо превъртане напред, така че получавате

--- O ----------- M <--(master)
     \           /
      x -- x -- x <--(dev)

Въпреки това по подразбиране повечето git команди все още ще показват подробната история (включително dev ангажиментите), но можете да отмените това, като използвате опцията --first-parent.

git log --first-parent master

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

person Mark Adelsberger    schedule 08.09.2020
comment
Използването на --no-ff изглежда е точно това, от което имах нужда. Благодаря за информацията. - person Dave Ludwig; 09.09.2020