Ինչպես օգտագործել Git-ը AI-ով ստեղծված հավելվածի հետ

AI-ով ստեղծված հավելվածը Git-ի հետ օգտագործելու համար նախագիծը միացրեք Git պահոցին, commit արեք յուրաքանչյուր աշխատող փոփոխությունից հետո, գրեք մեկ տողով հաղորդագրություն, որ ասում է, թե ինչ է փոխվել, և գաղտնի տվյալները պահեք .gitignore-ից դուրս։ Ռիսկային աշխատանքի համար օգտագործեք ճյուղ, եթե ուրիշը փոխել է կոդը՝ նոր հրահանգ տալուց առաջ արեք pull, իսկ երբ AI-ն ինչ-որ բան կոտրի, վերադարձեք վերջին աշխատող commit-ին՝ այն շերտավորելու փոխարեն։

Git-ը տարբերակների կառավարման համակարգ է. պատմություն այն բոլոր պահպանված տարբերակների, որ ունի ձեր կոդը։ GitHub-ը կայք է, որը առցանց պահում է Git պահոցները։ Եթե սրանք նոր են ձեզ համար, սկսեք GitHub-ի ներկայացումից։ Այս ուղեցույցը վերաբերում է այն սովորություններին, որոնք Git-ը օգտակար են դարձնում, երբ կոդի մեծ մասը գրում է AI-ն։

Ինչու Git-ը ավելի կարևոր է AI-ի հետ

AI-ն մեկ հերթում կարող է փոխել քսան ֆայլ։ Դա արագ է, բայց նաև նշանակում է, որ մեկ հրահանգը կարող է աննկատ կոտրել այն, ինչ երեկ փորձարկել եք։ Git-ը տալիս է՝

• Վերադարձի ուղի։ Ցանկացած commit արված տարբերակ կարելի է վերականգնել։
• Փոփոխությունների գրանցում։ Կարող եք տեսնել, թե հրահանգը ճշգրտ ո՛ր ֆայլերին և տողերին է դիպել։
• Պատճեն կառուցիչից դուրս։ Ձեր կոդը գտնվում է այնտեղ, որ դուք եք վերահսկում։
• Ստանդարտ հանձնում։ Ցանկացած մշակող, հարթակ կամ գործիք կարող է աշխատել Git պահոցից։

Քայլ 1. Միացրեք պահոց

Ստեղծեք պահոց (սովորաբար մասնավոր) GitHub-ում կամ նմանատիպ ծառայությունում և միացրեք ձեր նախագիծը դրան։ Git-ը աջակցող AI կառուցիչների մեծ մասը դա անում է կարգավորումների էջում՝ «Connect GitHub» կոճակով։ Եթե ձերը չունի, կարող եք կոդը արտահանել և ինքներդ ուղարկել, կամ մեկ անգամ խնդրել մշակողին կարգավորել։

Առաջին ուղարկումից առաջ համոզվեք, որ պահոցն անտեսում է այն, ինչ չպետք է այնտեղ լինի։

Ստուգիր .gitignore ֆայլը։ Համոզվիր, որ այն բացառում է .env ֆայլերը, node_modules-ը, build-ի արդյունքի թղթապանակները և ցանկացած գաղտնի տվյալ պարունակող ֆայլ։ Ասա, թե ինչ ես ավելացրել։

Քայլ 2. Commit արեք յուրաքանչյուր աշխատող փոփոխությունից հետո

Commit-ը հաղորդագրությամբ պահպանված պատճեն է։ Կարևոր սովորությունը սա է. commit արեք, երբ ինչ-որ բան աշխատում է, նախքան հաջորդն ուզելը։

1. Խնդրեք մեկ փոփոխություն։
2. Ստուգեք այն նախադիտման մեջ։
3. Եթե աշխատում է, արեք commit (կամ համաժամեցում) հաղորդագրությամբ։
4. Այնուհետև անցեք առաջ։

Փոքր commit-ները նշանակում են, որ երբ ինչ-որ բան կոտրվի, կիմանաք, թե որ փոփոխությունն է դա արել, և դրա չեղարկումը չի ջնջի մյուս աշխատանքը։

Քայլ 3. Գրեք հաղորդագրություններ, որ հետո կկարդաք

Լավ հաղորդագրությունը ասում է, թե ինչ է փոխվել և ինչու, մեկ տողով․

• Լավ՝ Add CSV export to the orders page
• Լավ՝ Fix booking form rejecting times after 6pm
• Անօգուտ՝ update, changes, fix stuff

Հաղորդագրությունները կարող եք AI-ին խնդրել գրել․

Ամփոփիր վերջին commit-ից հետո կատարված փոփոխությունները մեկ տողով, սկսելով բայով, 70 նիշից պակաս։

Քայլ 4. Օգտագործեք ճյուղեր ռիսկային աշխատանքի համար

Ճյուղը առանձին աշխատանքային գիծ է։ Կարող եք ինչ-որ բան փորձել ճյուղի վրա և, եթե չստացվի, լքել այն՝ առանց հիմնական տարբերակին դիպչելու։

Օգտագործեք ճյուղ, երբ՝

• Փոփոխությունը մեծ է (վերադիզայն, նոր վճարման հոսք, տվյալների բազայի փոփոխություն)։
• Ուրիշ մեկը աշխատում է նույն հավելվածի վրա։
• Ցանկանում եք, որ մեկը վերանայի փոփոխությունը, նախքան այն թողարկվի։

Աշխատանքը ավարտվելուց և փորձարկվելուց հետո այն միաձուլվում է հիմնական ճյուղի հետ։ GitHub-ում դա սովորաբար տեղի է ունենում pull request-ի միջոցով՝ էջ, որը ցույց է տալիս փոփոխությունները վերանայման համար։ Եթե ձեր կառուցիչը համաժամեցնում է միայն մեկ ճյուղ, ճյուղերը GitHub-ի կողմից կարող է կառավարել մշակողը։

Քայլ 5. Հետ վերադարձեք անվտանգ

Երբ հրահանգը կոտրում է հավելվածը, դիմադրեք ցանկությանը՝ ևս հինգ անգամ նոր հրահանգ տալ դրա վրա։ Վերադարձեք վերջին աշխատող տարբերակին և փորձեք ավելի հստակ հրահանգ։

• Կառուցիչում․ օգտագործեք դրա checkpoint կամ վերականգնման գործառույթը, եթե այն կա։
• Git-ում․ git revert-ը ստեղծում է նոր commit, որ չեղարկում է հին մեկը՝ պահպանելով պատմությունը։ Դա անվտանգ ընտրություն է, երբ կոդը արդեն քաշվել է ուրիշների կողմից։
• Խուսափեք git push --force-ից համօգտագործվող ճյուղում, եթե ճշգրտորեն չգիտեք, թե ինչու։ Այն վերագրում է պատմությունը բոլորի համար։

Եթե վստահ չեք, հարցրեք․

Վերջին փոփոխությունը կոտրեց մուտքի էջը։ Ցույց տուր, թե նախորդ commit-ի համեմատ որ ֆայլերն է այն փոխել, և բացատրիր, թե յուրաքանչյուր փոփոխություն ինչ էր անում։ Առայժմ ոչինչ մի փոխիր։

Քայլ 6. Pull արեք նախքան հրահանգ տալը

Եթե մշակողը կամ մեկ այլ գործիք փոխում է կոդը GitHub-ում, AI կառուցիչը դա չգիտի, մինչև դուք այդ փոփոխությունները pull-ով չբերեք։ Հին կոդի վրա հրահանգ տալը բերում է կոնֆլիկտների և կորած աշխատանքի։

• Pull արեք յուրաքանչյուր աշխատանքային նստաշրջանի սկզբում։
• Համաձայնեցրեք, թե ով ինչ է խմբագրում, և խուսափեք, որ երկու կողմն էլ միաժամանակ խմբագրի նույն ֆայլերը։
• Եթե ստանում եք merge conflict (նույն տողերի երկու փոփոխություն), խնդրեք մշակողին կամ AI-ին լուծել այն և բացատրել ընտրությունը։

Օրինակ հրահանգներ

Նախքան սկսելը. ի՞նչ է փոխվել պահոցում իմ վերջին նստաշրջանից հետո։ Ամփոփիր commit-ները։

Արա հաջորդ փոփոխությունը առանձին. ավելացրու «Duplicate» կոճակ յուրաքանչյուր հաշվի վրա։ Այլ բան մի փոխիր, որ այն առանձին commit անեմ։

Ստուգիր, որ Git-ում չկան հետագողված API բանալիներ, գաղտնաբառեր կամ .env ֆայլեր, ներառյալ նախորդ commit-ներում։ Հաղորդիր միայն ֆայլերի անունները, ոչ արժեքները։

Սովորական սխալներ

• Գաղտնի տվյալների commit անելը։ Երբ բանալին հայտնվում է Git պատմության մեջ, այն բացահայտվում է, նույնիսկ եթե ֆայլը հետո ջնջեք։ Փոխեք այն։
• Մեկ հսկայական commit շաբաթական։ Մեկ փոփոխությունը հետ վերցնել չեք կարող՝ առանց մյուսների հետ վերցնելու։
• «update» տիպի հաղորդագրություններ։ Պատմությունը անօգուտ է դառնում այն գտնելու համար, թե ինչն է կոտրվել։
• Հին կոդի վրա հրահանգ տալը։ Նախ pull արեք, եթե ուրիշը խմբագրում է։
• Սխալը ուղղելու համար force-push անելը։ Այն կարող է ջնջել ուրիշների աշխատանքը։ Փոխարենը revert արեք։
• node_modules-ի commit անելը։ Այն հսկայական է և այնուամենայնիվ վերստեղծվում է lock ֆայլից։

Ստուգացանկ

• Նախագիծը միացված է մասնավոր պահոցին։
• .gitignore-ը բացառում է .env-ը, node_modules-ը, build-ի արդյունքը և գաղտնի տվյալները։
• Commit եմ անում յուրաքանչյուր աշխատող փոփոխությունից հետո։
• Commit-ի հաղորդագրությունները մեկ տողով ասում են, թե ինչ է փոխվել։
• Մեծ կամ ռիսկային փոփոխությունները գնում են ճյուղ և վերանայվում են։
• Pull եմ անում նախքան հրահանգ տալը, երբ ուրիշը խմբագրում է կոդը։
• Հետ եմ վերադառնում checkpoint-ներով կամ git revert-ով, ոչ թե force-push-ով։
• Ցանկացած բանալի, որ երբևէ commit է եղել, փոխվել է։

Git Mythex-ում

Mythex-ը յուրաքանչյուր հաջող agent հերթից հետո պահում է git checkpoint, և Revert to this point-ը նախագիծը վերադարձնում է այդ կետին՝ կառուցիչի կողմից հետ վերադարձը, որ նկարագրված է 5-րդ քայլում։ Տե՛ս Iterate without rebuilding։

Pro պլանում GitHub sync-ը միացնում է պահոց նախագծի կարգավորումներից, որ կարողանաք push և pull անել, իսկ export-ը ներբեռնում է նախագիծը՝ առանց գաղտնի տվյալների և node_modules-ի։ Տե՛ս GitHub, export, and import։ Նախքան նախագիծը մշակողին հանձնելը GitHub-ը միացնելը հանձնումը շատ ավելի պարզ է դարձնում. տե՛ս ինչպես աշխատել մշակողի հետ AI-ով ստեղծված հավելվածի վրա և ինչպես արտահանել և ինքնուրույն տեղակայել AI-ով ստեղծված հավելվածը։

Հարցեր