Kokie gitų šakotieji modeliai jums tinka?

Mūsų kompanija šiuo metu naudoja paprastą kamieno / išleidimo / karštųjų pataisų prijungimo modelį ir norėtų patarti, kurie šakotieji modeliai geriausiai tinka jūsų įmonei ar kūrimo procesui.

  1. Darbo eigos / filialų modeliai

    Toliau pateikiami trys pagrindiniai šio reiškinio aprašymai, kuriuos aš mačiau, tačiau jie yra iš dalies prieštaringi arba nėra pakankamai toli, kad galėtume išspręsti vėlesnes problemas, su kuriomis susidūrėme (kaip aprašyta toliau). Taigi, mūsų komanda vis dar nėra labai didelė. Ar darai kažką geriau?

  2. Sujungti ir perkrauti (susieta ir nuosekli istorija)

    Jei kas nors pull --rebase arba laukia sujungimo su pagrindiniu pull --rebase kol jūsų užduotis bus baigta? Asmeniškai aš linkiu jungtis, nes jis išsaugo vizualinį iliustraciją, pagal kurią užduotis buvo pradėta ir baigta, ir aš netgi norėčiau merge --no-ff šiam tikslui. Tačiau jis turi ir kitų trūkumų. Be to, daugelis nesuprato naudingos susijungimo savybės - tai nėra komutatyvi (temos filialo sujungimas su kapitonu nereiškia kapitono sujungimo į temos šaką).

  3. Aš ieškau natūralaus darbo eigos

    Kartais įvyksta klaidų, nes mūsų procedūros nenustato konkrečios situacijos su paprastomis taisyklėmis. Pavyzdžiui, korekcija, reikalinga ankstesniems leidimams, žinoma, turėtų būti pagrįsta pakankamai pasroviui, kad ją būtų galima sujungti iki visų reikalingų šakų (ar pakanka naudoti šias sąvokas?). Tačiau atsitinka, kad pataisymas ją paverčia meistru, kol kūrėjas suvokia, kad jis turėtų būti dedamas toliau pasroviui, ir jei jis jau yra spaudžiamas (dar blogiau, sujungtas ar kažkas ant jo), tada likusi galimybė yra vyšnių pasirinkimas susijusius pavojus. Kokias paprastas taisykles naudojate? Taip pat yra vienos temos šakos nepatogumas, kuris būtinai pašalina kitas temos šakas (su sąlyga, kad jos yra šakotos iš bendros pradinės linijos). Kūrėjai nenori baigti funkcijos, kad pradėtų kitą jausmą, panašų į kodą, kurį jie ką tik parašė, nebėra

  4. Kaip išvengti konfliktų sujungimo (dėl vyšnių rinkimo)?

    Atrodo, kad teisingas būdas susivienijimo konfliktui sukurti yra paukščių vyšnios tarp šakų, ar jos niekada negali būti vėl sujungtos? Ar to paties įsipareigojimo panaudojimas grįš (kaip tai padaryti?) Bet kurioje šakoje galima išspręsti šią situaciją? Tai yra viena iš priežasčių, kodėl nedrįsta primygtinai reikalauti pagrindinio susijungimo srauto.

  5. Kaip suskaidyti į dabartinę pramonę?

    Mes suprantame, kad būtų puiku surinkti paruoštus integracijos sprendimus iš temų šakų, tačiau dažnai mūsų kūrėjų darbas nebuvo aiškiai apibrėžtas (kartais taip paprasta, kaip „išrinkimas“), o jei kai kurie kodai jau persikėlė į „skirtingus“, negalite išeiti iš ten, pagal pirmiau pateiktą klausimą? Kaip dirbate su savo filialų apibrėžimu / patvirtinimu / išleidimu / išleidimu?

  6. Žinoma, teisingos procedūros, pvz., Kodų peržiūra ir išleidimas , bus puikios.

    Bet mes tiesiog negalime išlaikyti dalykų, kad juos tvarkytume - bet kokius pasiūlymus? integracijos pramonės šakos, iliustracijos?

Toliau pateikiamas susijusių klausimų sąrašas:

Taip pat perskaitykite, ką „Plastic SCM“ rašo apie užduotį orientuotą kūrimą , ir jei „Plastic“ nėra jūsų pasirinkimas, ištarkite „nvie“ šakotojo modelį ir jo pagalbinius scenarijus .

350
12 апр. HiQ CJ nustatė balandžio 12 d 2010-04-12 14:23 '10, 14:23 PM 2010-04-12 14:23
@ 4 atsakymai

Labiausiai nerimą keliantis naujųjų DVCS kūrėjų bruožas turėtų būti skelbimo proceso supratimas:

  • galite importuoti (ištraukti / ištraukti) visus reikalingus nuotolinius repo
  • galite skelbti (spustelėti) bet kokią (be) repo, kurį norite

Nuo šiol jūs galite laikytis kelių taisyklių, kad supaprastintumėte savo klausimus:

Dabar:

Darbo eigos / šakos modeliai :

Kiekviena darbo eiga palaiko išleidimo valdymo procesą ir yra skirta kiekvienam projektui.
Ką aš galiu pridėti prie darbo eigos, apie kurią kalbate: kiekvienas kūrėjas neturėtų sukurti funkcijos filialo, bet tik filialo „dabartinis dev“, nes tiesa, kad kūrėjas dažnai nežino, ką gamins: viena (nes ji pasirodė esanti pernelyg sudėtinga funkcija), o ne viena (nes ji nėra pasirengusi paleisti), kita funkcija (nes originalas buvo „morphed“) ...

Tik „integratorius“ turėtų sukurti „centrinio“ repo oficialius funkcijų filialus, kuriuos kūrėjai gali gauti perskirstydami / konsoliduodami savo funkciją atitinkančią savo darbo dalį.

Sujungti ir perkrauti (susietas ir nuoseklus pasakojimas) :

Man patinka mano atsakymas, kurį paminėjote („ Darbo eigos aprašymas naudojant vidinį vystymąsi “)

Aš ieškau natūralaus darbo eigos :

pleistrų atveju tai gali padėti susieti kiekvieną pleistrą su klaidų sekimo bilietu, kuris padeda kūrėjui prisiminti, kur (ty, kuriame skyriuje, ty specializuotame skyriuje "pataisymams") jis turėtų atlikti tokius pakeitimus.
Tada kabliukai gali padėti apsaugoti centrinį repo nuo sukrėtimų, gautų iš neaudituotų klaidų taisymų, arba nuo filialų, kurių negalima nuspausti. (nėra konkretaus sprendimo, visa tai turi būti pritaikyta prie jūsų aplinkos)

Kaip išvengti konfliktų sujungimo (dėl vyšnių rinkimo)?

Kaip atsakyme nurodė Jakub Narbski , vynuogių derlius prireikus turėtų būti rezervuotas retoms situacijoms.
Jei jūsų įrenginyje yra daug vyšnių rinkimo (t. Y. „Tai nėra neįprasta“), tada kažkas neveikia.

Ar tą patį pataisymą taikytumėte grįžtant (kaip tai padaryti?)

git revert turėtų pasirūpinti, bet tai nėra tobula.

Kaip suskaidyti į dabartinę pramonę?

Iki tol, kol pramonė toliau eis visur, kūrėjas turi reorganizuoti savo vykdymo istoriją (kai tik jis pagaliau mato, kad plėtra yra labiau apibrėžta ir stabilesnė):

  • kelis filialus, jei reikia (vienas pagrįstas aiškiai apibrėžta funkcija)
  • nuoseklus įsipareigojimas per vieną filialą (žr.

Ar teisingos procedūros, pvz., Kodų peržiūra ir išleidimas?

Integracijos filialai (specializuota integracija) gali padėti kūrėjui:

  • grąžinti jo / jos plėtrą ant šio nuotolinio integravimo filialo (traukti --rebase)
  • išspręsti vietoje
  • paspartinti vystymąsi į šį atpirkimo sandorių
  • pasitarkite su integratoriumi, kuris nesukelia painiavos;)
84
12 апр. Atsakymą pateikė VonC balandžio 12 d 2010-04-12 15:01 '10, 15:01, 2010-04-12 15:01

Manau, ir galbūt aš klystu, kad vienas iš nesuprantamų dalykų yra tai, kad jis yra išskirtinis. Tai labai skiriasi nuo to, kaip galite dirbti, nors galite imituoti SVN elgesį, jei norite. Problema yra ta, kad bet koks darbo srautas bus didelis, bet ir klaidinantis.

Jei turiu savo supratimą apie branduolio vystymąsi (daugiausia dėmesio skirsiu šiam tikslui), kiekvienas turi savo gitų saugyklą branduolio plėtrai. Yra viena saugykla, linux-2.6.git, kuri tarnauja „Torvalds“, kuri veikia kaip išleidimo saugykla. Žmonės klonuoja iš čia, jei nori pradėti kurti funkciją prieš filialą „išleidimas“.

Kitos saugyklos daro tam tikrą pažangą. Idėja yra klonuoti iš linux-2.6, šakutės tiek kartų, kiek norite, tiek, kiek turite „naują“ funkciją. Tada, kai jis yra pasirengęs, galite tai padaryti prieinamam žmogui, kuris, jūsų manymu, yra patikimas, kuris ištrauks šią temą iš savo saugyklos į savo ir sujungs jį į pagrindinę. Linux branduolyje tai vyksta keliais lygmenimis (patikimi leitenantai), kol ji pasiekia linux-2.6.git, ir tuo metu ji tampa „branduoliu“.

Dabar čia, kur ji painioja. Filialų pavadinimai neturi būti nuoseklūs tarp saugyklų. Todėl galiu git pull origin master:vanilla-code ir gauti šaką iš origin vedlio mano saugyklos filiale, vadinamame vanilla-code . Nustačius, kad aš žinau, kas vyksta, tai tikrai nesvarbu - ji platinama ta prasme, kad visos saugyklos yra tarpusavyje susijusios, o ne tik perduodamos keliuose kompiuteriuose, pvz., SVN.

Taigi, atsižvelgiant į visa tai:

  • Manau, kad kiekvienas programuotojas priklauso nuo to, kaip jie daro savo šakutę. Viskas ko jums reikia, yra centrinė atminties tvarkymo saugykla ir kt. Bagažinė gali būti head . Išleidimai gali būti žymės arba šakos, o pataisymai tikriausiai yra filialai. Tiesą sakant, tikriausiai turėčiau problemų kaip filialų, kad galėtumėte juos išspręsti.
  • Būčiau susijungęs, ne iš naujo įdiegęs. Pavyzdžiui, jei jūs laikote saugyklą, ją klonuojate, einate ir atlikite kai kuriuos, o tada ištraukite iš savo origin , turbūt turėtumėte sukurti kitą filialą savo saugykloje ir sujungti paskutinį master į savo yourbranch , kad kažkas galėtų patraukite savo pakeitimus minimaliomis pastangomis. Mano patirtis rodo, kad labai retai reikia iš naujo įdiegti.
  • Manau, kad tai yra būdas suprasti, kaip git veikia ir ką jis gali padaryti. Tai užtruks šiek tiek laiko ir daug geros komunikacijos - aš tik pradėjau suprasti, kas atsitinka, kai pradėjau naudoti git su kitais kūrėjais ir net dabar, kai kuriuos dalykus, apie kuriuos nesu įsitikinęs.
  • Sujungimo klaidos yra naudingos. Žinau, aš žinau, jūs norite, kad visa tai veiktų, bet faktas yra tas, kad kodas pasikeičia, ir jums reikia derinti rezultatus su kažkuo, kuris veikia. Konfliktų sujungimas iš tikrųjų yra tik daugiau programavimo. Aš niekada neradau paprasto paaiškinimo, ką daryti su jais, todėl čia: atkreipkite dėmesį į sujungimo konfliktais esančius failus, eikite ir pakeiskite juos į tai, ką jie turėtų būti, git add . ir tada git commit .
  • Tačiau jis tinka. Kaip jau minėjau, kiekvienas „git“ naudotojo saugykla turi žaidimus, o šakos pavadinimai neturi būti vienodi. Pvz., Jei turite tarpinę saugyklą, galite taikyti pavadinimų schemą, tačiau jums nereikia kiekvieno kūrėjo tik išleidimo saugykloje.
  • Tai yra susijungimo etapas. Jūs jungiate tik išleidimo šakose ir tt, kai manote, kad kodas turėtų būti patikrintas / išlaikytas kokybės patikrinimas.

Tikiuosi, kad tai padės. Suprantu, kad VonC ką tik paskelbė labai panašų paaiškinimą ... Aš negaliu pakankamai greitai skambinti!

Pakeiskite keletą papildomų minčių, kaip naudoti „git“ komerciniuose nustatymuose, nes tai, atrodo, nurodo OP iš komentarų:

  • Išleidimo saugykla, kurią mes vadinsime product.git , yra prieinama keliems vyresniems programuotojams / technikams, atsakingiems už patį rūpestį pačiu produktu. Jie panašūs į kūrėjų vaidmenį OSS.
  • Šie programuotojai taip pat gali iš dalies dalyvauti kuriant naujas versijas, todėl jie taip pat gali koduoti save ir palaikyti įvairias saugyklas. Jie gali valdyti tarpines saugyklas, skirtas tikrai naujoms funkcijoms, ir jie taip pat gali turėti savo saugyklas.
  • Žemiau yra programuotojai, atsakingi už atskirų bitų kūrimą. Pavyzdžiui, kažkas gali būti atsakingas už vartotojo sąsają. Todėl jie tvarko UI.git saugyklą.
  • Toliau pateikiami tikrieji programuotojai, kurie tobulina funkcijas kaip visą savo dienos darbą.

Taigi, kas atsitiks? Na, kiekvienas išeina kiekvieno dienos pradžioje iš „kylančiojo“ šaltinio, ty į išleidimo saugyklą (kuri taip pat gali turėti naujausią medžiagą iš ankstesnių kūrimo dienų). Visa tai daroma tiesiogiai. Jis bus suskirstytas į savo kapinyną, tikriausiai vadinamas „šeimininku“, arba galbūt, jei vadinate mane „paskutinis“. Tada programuotojas atliks tam tikrą darbą. Šis darbas gali būti kažkas, apie kurį jie nėra tikri, todėl jie kuria filialą, dirba. Jei tai neveikia, jie gali ištrinti filialą ir sugrįžti. Jei taip atsitiks, jie turės susivienyti į pagrindinį filialą, kuriame jie dirba. Mes sakysime, kad tai yra UI programuotojas, dirbantis su latest-ui , taigi jis atlieka git checkout latest-ui , o tada git merge abc-ui-mywhizzynewfeature . Tada jis kalba apie savo techninę vadovybę (lyderystę sąsajoje), atlikiau tokią užduotį, ištraukiau iš manęs. Taigi, git pull user-repo lastest-ui:lastest-ui-suchafeature-abc vartotojo sąsajos išėjimas yra git pull user-repo lastest-ui:lastest-ui-suchafeature-abc . Tada vartotojo sąsaja žiūri į šią temą ir sako, kad ji yra labai gera, aš ją sujungiau į „ ui-latest . Tada jis gali pasakyti visiems, kurie yra žemiau, traukti jį nuo savo ui-latest filialų ar bet kokio kito pavadinimo, kurį jie davė, ir todėl šią funkciją tiria kūrėjai. Jei komanda yra laiminga, vartotojo sąsajos vadovybė gali paprašyti testavimo vadovo pašalinti ją iš jos ir sujungti pakeitimus. Tai taikoma visiems (tolesniems pakeitimams), kurie ją tikrina ir siunčia klaidų ataskaitas ir tt Galiausiai, jei funkcija praeina bandymus ir tt, vienas iš geriausių techninių būdų gali jį sujungti į dabartinę programos darbo kopiją, po kurios visi pakeitimai nukreipiami atgal. Ir taip toliau.

Tai nėra „tradicinis“ darbo būdas, skirtas „bendraamžiams“, o ne „hierarchiniams“, pavyzdžiui, SVN / CVS. Tiesą sakant, kiekvienas turi prieigą, bet tik vietoje. Tai yra prieiga prie saugyklos ir saugyklos, kurią nurodote kaip išleidimo saugyklą, kuri leidžia naudoti hierarchiją.

21
12 апр. atsakymą pateikė vartotojo257111 12 balandis. 2010-04-12 15:07 '10, 15:07, 2010-04-12 15:07

Modelis, kurį naudoju su gerais rezultatais, yra:

„Palaimintas“ atpirkimas yra stumiamas ir traukiamas į / iš, iš esmės, į kliento-serverio topologiją.

Nėra jokių pirmaujančių šakų, todėl kūrėjas negali paspausti jokio kodo „pagrindinėje linijoje“.

Visi įvykiai vyksta temos temomis. Mes vadiname vardus, kad galėtume lengvai nustatyti, kas už tai atsakingas: jn / newFeature arba jn / issue-1234

Valdyba taip pat turi palyginimą tarp 1 ir 1 tarp filialų ir kanban / scrum kortelių.

Jei norite paleisti filialą, jis bus paspaudžiamas ant palaiminto atpirkimo, o kanbano kortelė bus pasirengusi peržiūrėti.

Tada, jei filialas yra priimamas žiūrint, jis yra išleidimo kandidatas.

Išleidimas įvyksta, kai gautų filialų rinkinys sujungiamas ir žymimas versijos numeriu.

Paspaudus naują žymę palaimintame atpirkime, atsirado naujas galimas naujų funkcijų pagrindas.

Kad išvengtumėte konfliktų, kūrėjai maloniai prašo atnaujinti (sujungti) jų nepatvirtintus filialus į naujausią leidimo žymą.

9
11 окт. John Nilsson atsakymas spalio 11 d 2011-10-11 14:28 '11 prie 14:28 2011-10-11 14:28

Asmeniškai aš bandau išsaugoti tik paruoštą išleidimo kodą pagrindiniame filiale.

Kai dirbau su nauja funkcija ar taisymu, tai darau filiale. Aš taip pat bandau bloką filiale. Jei viskas veikia gerai, tik tada aš sujungsiu / iš naujo įdiegsiu į pagrindinį.

Bandau naudoti bendras pavadinimo konvencijas, pavyzdžiui:

  • klaidų taisymas / rekursinis _loop
  • klaidų taisymas / sql _timeout
  • / Naujas _layout funkcija
  • funkcija / Advanced_search
2
21 дек. atsakymas pateikiamas xero 21 d. 2012-12-21 01:16 '12 at 1:16 2012-12-21 01:16

Kiti klausimai apie „ etiketes „ arba „ Ask a question“