AMcoder - javascript, python, java, html, php, sql

Git merge - կծկե՞լ, թե՞ չկծկվել:

Ես ներկայումս աշխատում եմ git-ի օգտագործման ուղեցույցների կիրառման վրա՝ բավականին բարդ զարգացման միջավայրում, և թեև կարծում եմ, որ հիմունքները բավականին լավ են կարգավորվել, կա մի հարց, որի մասին ես կցանկանայի որոշակի ներդրում ունենալ, եթե դա ընդհանրապես հնարավոր է: Սա այնքան էլ զուտ տեխնիկական հարց չէ, քանի որ այն ավելի շատ այն մասին է, թե առկա տարբերակներից որն է առավել նպատակահարմար:

Հիմնականում ես հակված եմ մի համակարգի, որը սերտորեն արտացոլում է ընդհանուր «git flow» կառուցվածքը (http://nvie.com/posts/a-successful-git-branching-model/), որոշ բացառություններով այն հարմարեցնելու մեր զարգացման միջավայրին: Կարճ ասած:

  • Նախագիծը կունենա առնվազն «զարգացող» և «վարպետ» մասնաճյուղ
  • «վարպետը» կպարունակի արտադրության պատրաստի վերջին կոդը
  • «զարգացնելը» կպարունակի վերջին միավորված կոդը
  • Ցանկացած այլ բան կլինի «feature/ticket{number}» կամ «hotfix/ticket{number}» մասնաճյուղում
  • Գործառույթների ճյուղերը կստեղծվեն «զարգացումից», թեժ շտկման ճյուղերը՝ «վարպետից»
  • Մասնաճյուղի անվանման համարը միշտ կհամապատասխանի տոմսի համարին մեր սեփական փոփոխության/վրիպակների համակարգում
  • Առանձնահատկությունները կարող են փորձարկվել առանձին, բայց նաև համակցված՝ կառուցելով համապատասխան մասնաճյուղ կամ միաձուլելով այն՝ նախ «զարգացնելու» համար:

Մինչ այժմ դա իսկապես օգնել է մեզ պարզեցնել մեր զարգացումը և կանխել նախագծերի միջև հակասությունները: Մի մանրուք, որն այստեղ որոշակի բանավեճ է առաջացրել. Արդյո՞ք մենք պետք է միավորենք առանձնահատկությունների/տոմսերի ճյուղերը իրենց համապատասխան ծագման մեջ «--squash» տարբերակով: Ես որոշ չափով սրա երկրպագու եմ, և ինչն ինձ դուր է գալիս դրա մեջ.

  • Զարգացման համար git log-ը մնում է մաքուր և ընթեռնելի, բոլոր commit-ները պարզապես կնշեն ճյուղի սկզբնական անունը (որը մեզ ասում է, թե արդյոք դա թեժ ուղղում էր, թե հատկանիշ, և տոմսի համարը)
  • Նույնիսկ սկզբնական հատկանիշը կամ թեժ շտկման ճյուղը ջնջելուց հետո, միաձուլումը չի կարող հետագայում որևէ շփոթություն առաջացնել

Հնարավոր է, որ այս պատճառները բավարար չափով լավ չլինեն, և գուցե լավ պատճառներ կան այս սցենարում «--squash» չօգտագործելու համար: Մտքեր կա՞ն:

git merge version-control
18.11.2014

Պատասխանները:


1

[S]պե՞տք է միաձուլենք գործառույթների/տոմսերի ճյուղերը իրենց համապատասխան ծագման մեջ --squash տարբերակով:

Ամեն ինչ կախված է նրանից, թե որքան նուրբ եք ցանկանում, որ ձեր ռեպո պատմությունը լինի: Հիշեք, որ տարբերակի վերահսկումը, commit հաղորդագրությունների միջոցով, կոդային փաստաթղթերի ձև է: Կամա թե ակամա ճզմելը, իհարկե, լավ պրակտիկա չէ: Դա կարող է լավ լինել թեժ շտկման մասնաճյուղի համար, բայց հազվադեպ է էական գործառույթների ճյուղի համար:

Որպես անալոգիա, պատկերացրեք, եթե դուք ինձանից խնդրեիք տրամադրել իմ Lost DVD տուփը (այսինքն՝ դուք կլոնավորել եք իմ ռեպո), և ես ձեզ տամ տուփը, առանց DVD-ների, և ասեմ ձեզ.

Ահա, պարզապես կարդացեք շարքի ամփոփագիրը հետևի շապիկին։ Դա պետք է ձեզ բավականաչափ պատմի սյուժեի մասին:

Այսպիսով, ամեն դեպքում, խեղդեք ձեր պարտավորությունները, երբ ցանկանում եք ազատվել միջանկյալ քայլերից, որոնք անտեղի մանրամասն են կամ բավականաչափ ինքնամփոփ, բայց ոչ այնքան, որ դա մթագնի ձեր պահեստի էվոլյուցիան:

(Ես այս հարցն ավելի մանրամասն քննարկում եմ այս Twitter թեմայում):

18.11.2014
  • Դա իմաստ ունի: Ես չեմ խոսում ցանկացած ճյուղ կուրորեն ճզմելու մասին, իհարկե: Սա հատկապես վերաբերում է այն, ինչ մենք համարում ենք տոմսերի մասնաճյուղեր: Իմ հիմնական նկատառումն այն է, որ այն թույլ է տալիս ինձ ապահովել, որ յուրաքանչյուր commit, որն այն վերածում է հիմնական կոդը, կունենա commit հաղորդագրություն, որը հստակ նշում է, թե որ տոմսի համարն է խոսքը: Բացի այդ, քանի որ այստեղ տեսածս տոմսերի մեծամասնությունը սովորաբար չի պահանջում շատ մեծ թվով պարտավորություններ ուղղելու համար, ես շատ պատճառ չեմ տեսել պահպանել յուրաքանչյուր միջանկյալ քայլը, երբ այն փորձարկվի, հաստատվի և նորից միացվի: 19.11.2014
  • Կարծում եմ՝ մենք նույն հարթության վրա ենք: Ես տեսնում եմ պարտավորությունների հաղորդագրություն ունենալու բողոքարկումը, որտեղ հստակ նշվում է համապատասխան տոմսի համարը. և դուք իրավացի եք, որ տոմսերի մեծամասնության համար այդքան շատ պարտավորություններ չեն պահանջվում, ուստի այնքան էլ մանրուքները չեն կորչի ճզմման մեջ: Կարծում եմ՝ ձեր հարցի պատասխանը շատ է կախված իրավիճակից։ Ամփոփելով՝ դդմիկ, բայց խորաթափանցությամբ։ 19.11.2014
  • Կամ ամենևին էլ մի կծկվեք և համոզվեք, որ տոմսի համար եք տեղադրել յուրաքանչյուր հաղորդագրության մեջ: Կամ փոխեք ձեր գործիքակազմը, որպեսզի այն կարողանա այլ տեղից եզրակացնել տոմսի համարը: 09.11.2019
  • @jub0bs իսկ եթե դուք սեղմում եք, ասենք, գեղեցիկ մանրամասն commit հաղորդագրությունը, և ստորատակի վրա թողնում եք հղում այն ​​մասնաճյուղից, որտեղից դուք սեղմել եք: Այս կերպ դուք կարող եք ունենալ լավ պատվիրված պատմություն ձեր մշակման մեջ, և եթե ցանկանում եք ավելի շատ մանրամասներ ստուգել, ​​կարող եք ստուգել գործառույթի մասնաճյուղի պատմությունը 13.01.2020
  • @JordanKanchelov Սա դեռ կխանգարի ինձ հետ շրջել ատոմային փոփոխությունները: Դրա համար ես նախընտրում եմ չկտրվել։ 16.01.2020
  • Տեղական մասնաճյուղում արագ WIP-save պարտավորությունները վերացնելու համար կարող եք git rebase -i HEAD~N (տես այստեղ): 27.11.2020

    • 2

    Մի խեղդվեք. փոքր պարտավորությունները օգտակար են հատկապես git bisect-ով սխալների հետագա հայտնաբերման համար, և, այնուամենայնիվ, դուք չեք ցանկանում շատ փոխել պատմությունը: Պարզապես օգտագործեք միաձուլման հանձնարարականը (git merge --no-ff)՝ պատմությունը կազմակերպված պահելու համար:

    18.03.2019
  • Սխալների հետագծումը դառնում է ավելի դժվար, ոչ թե հեշտ, երբ կան բազմաթիվ աղմկոտ անիմաստ միջանկյալ պարտավորություններ: Դուք ցանկանում եք համահունչ պարտավորություն կատարել, որը ներկայացնում է փոփոխությունների կտորներ, որոնք իմաստ կունենան բալի քաղել մի ճյուղից մյուսը: Նախագիծը պետք է կառուցվի և լինի խելամիտ վիճակում յուրաքանչյուր առանձին պարտավորություն կիրառելուց հետո: 24.03.2020
  • @Sammi. «Նախագիծը պետք է կառուցվի և լինի խելամիտ վիճակում յուրաքանչյուր առանձին պարտավորություն կիրառելուց հետո»: Համաձայնեցին. • «Սխալների հետագծումը դառնում է ավելի դժվար, ոչ թե հեշտ, երբ կան բազմաթիվ աղմկոտ անիմաստ միջանկյալ պարտավորություններ»: Ես ոչ թե անիմաստ պարտավորությունների կողմնակից եմ, այլ ավելի փոքր: Քանի որ git bisect-ն օգտագործում է commit-ը որպես հստակության միավոր, ավելի փոքր (իմաստալից) հանձնառությունները դարձնում են սխալների հետագծումը հեշտ: Ես համաձայն եմ, որ յուրաքանչյուր պարտավորություն պետք է լինի համահունչ հայտնի-լավ վիճակ, բայց երբեմն դա նշանակում է փոխել միայն 3 տող կոդ: 25.03.2020
    • Նոր նյութեր
    Օգտագործելով Fetch Vs Axios.Js-ը՝ HTTP հարցումներ կատարելու համար
    JavaScript-ը կարող է ցանցային հարցումներ ուղարկել սերվեր և բեռնել նոր տեղեկատվություն, երբ դա անհրաժեշտ լինի: Օրինակ, մենք կարող ենք օգտագործել ցանցային հարցումը պատվեր ներկայացնելու,..
    Տիրապետել հանգստության արվեստին. մշակողի ուղեցույց՝ ճնշման տակ ծաղկելու համար
    Տիրապետել հանգստության արվեստին. մշակողի ուղեցույց՝ ճնշման տակ ծաղկելու համար Ինչպե՞ս հանգստացնել ձեր միտքը և աշխատեցնել ձեր պրոցեսորը: Ինչպես մնալ հանգիստ և զարգանալ ճնշման տակ...
    Մեքենայի ուսուցում բանկային և ֆինանսների ոլորտում
    Բարդ, խելացի անվտանգության համակարգերը և հաճախորդների սպասարկման պարզեցված ծառայությունները բիզնեսի հաջողության բանալին են: Ֆինանսական հաստատությունները, մասնավորապես, պետք է առաջ մնան կորի..
    Ես AI-ին հարցրի կյանքի իմաստը, այն ինչ ասում էր, ցնցող էր:
    Այն պահից ի վեր, երբ ես իմացա Արհեստական ​​ինտելեկտի մասին, ես հիացած էի այն բանով, թե ինչպես է այն կարողանում հասկանալ մարդկային նորմալ տեքստը, և այն կարող է առաջացնել իր սեփական արձագանքը դրա..
    Ինչպես սովորել կոդավորումը Python-ում վագրի պես:
    Սովորելու համար ծրագրավորման նոր լեզու ընտրելը բարդ է: Անկախ նրանից, թե դուք սկսնակ եք, թե առաջադեմ, դա օգնում է իմանալ, թե ինչ թեմաներ պետք է սովորել: Ծրագրավորման լեզվի հիմունքները, դրա..
    C++-ի օրական բիթ(ե) | Ամենաերկար պալինդրոմային ենթաշարը
    C++ #198-ի ամենօրյա բիթ(ե), Ընդհանուր հարցազրույցի խնդիր. Ամենաերկար պալինդրոմային ենթատող: Այսօր մենք կանդրադառնանք հարցազրույցի ընդհանուր խնդրին. Ամենաերկար palindromic substring...
    Kydavra ICAReducer՝ ձեր տվյալների ծավալայինությունը նվազեցնելու համար
    Ի՞նչ է ICAReducer-ը: ICAReducer-ն աշխատում է հետևյալ կերպ. այն նվազեցնում է նրանց միջև բարձր փոխկապակցված հատկանիշները մինչև մեկ սյունակ: Բավականին նման է PCAreducer-ին, չնայած այն..