Ինչպե՞ս եք սովորաբար կատարում կոդի commit-ները։

Ես օգտագործում եմ ստանդարտացված հանձնառու ձևաչափ, հաճախ հիմնված է Conventional Commits-ի վրա: Սա ապահովում է համահունչություն և ավտոմատացնում որոշ գործընթացներ, օրինակ՝ փոփոխությունների օրագրի ստեղծում:

Հանձնառուի սովորական ձևաչափը՝

<տիպ>[(տարածք)]: <նկատում>

[<մարմին>]

[<նշում>]

• <տիպ>: Պարտադիր: Նշում է փոփոխության տիպը (օրինակ՝ feat նոր ֆունկցիաների համար, fix սխալների համար, docs փաստաթղթերի փոփոխությունների համար, style ձևաչափի համար, refactor վերափոխման համար, test թեստերի ավելացման համար, ci CI/CD փոփոխությունների համար):
• (տարածք): Ընտրովի: Նշում է ծրագրի այն հատվածը, որը ազդել է փոփոխությունը (օրինակ՝ (կոմպոնենտ: կոճակ), (ծառայություն: հաստատում))։
• <նկատում>: Պարտադիր: Կարճ և հստակ նկարագրություն փոփոխությունների մասին՝ հրամանի ձևով (օրինակ՝ "ավելացնել կոճակ", "ուղղել վավերացման սխալը")։
• <մարմին>: Ընտրովի: Ավելի մանրամասն բացատրություն փոփոխությունների, պատճառների և կոնտեքստի մասին։ Բաժանվում է դատարկ գծով նկարագրից։
• <նշում>: Ընտրովի: Օգտագործվում է սովորաբար BREAKING CHANGE նշելու համար՝ նկարագրելով, թե ինչու է այս փոփոխությունը խախտում հետագա համատեղելիությունը կամ հղումներ առաջադրանքներին (օրինակ՝ Closes #123)։

Օրինակներ՝

feat: ավելացնել մոդալ պատուհանի կոմպոնենտ

fix(վավերացում): ուղղել էլփոստի վավերացման սխալը գրանցման ձևում

Հիմա էլփոստը ճիշտ վավերացվում է RFC 5322 ստանդարտի համաձայն։

Closes #45

refactor(կոմպոնենտ: կոճակ): թարմացնել ոճերը և բարելավել հասանելիությունը

Կոմպոնենտի ոճերի վերականգնում՝ համապատասխանեցնելու դիզայնային համակարգին։
Հասանելիությունը բարելավվել է ARIA ատրիբուտների ավելացմամբ։

Սա օգնում է թիմին ավելի լավ հասկանալ փոփոխությունների պատմությունը, արագացնել կոդի վերանայումը և պարզեցնել ավտոմատացված գործընթացները։