Ի՞նչ է GitHub-ը։ Տարբերակների կառավարումը ոչ ծրագրավորողների համար

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

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

Ինչու է կարևոր AI-ով կառուցելիս

AI հավելվածի կառուցողը արագ է գրում և փոխում մեծ քանակությամբ կոդ, և ոչ բոլոր փոփոխություններն են բարելավում։ Տարբերակների կառավարումը այն միջոցն է, որով դա անվտանգ եք դարձնում։

• Հետ վերադարձ առանց վախի։ Յուրաքանչյուր պահված փոփոխություն նկարահանված վիճակ է։ Եթե AI-ն ինչ-որ բան կոտրի, վերադառնում եք վերջին լավ վիճակին։
• Սեփականություն։ Ձեր սեփական GitHub հաշվում գտնվող կոդը ձերն է մնում, եթե փոխեք գործիքը, դադարեցնեք վճարել մեկի համար կամ ուզենաք երկրորդ կարծիք։
• Աշխատանք մշակողների հետ։ Գրեթե բոլոր մշակողներն օրական օգտագործում են Git։ Repository-ն թույլ է տալիս նրանց ստուգել, թե ինչ է գրել AI-ն, շտկել այն և փոփոխությունները հետ ուղարկել։
• Տեղակայում այլ տեղ։ Հյուրընկալման շատ հարթակներ կարող են տեղակայել ուղղակիորեն GitHub repository-ից։

Ամենօրյա անալոգիա՝ փոփոխությունների գրանցում և համատեղ սկավառակ

Պատկերացրեք փաստաթուղթ, որում միացված է փոփոխությունների գրանցումը (track changes), և որը պահվում է համատեղ սկավառակի վրա։

• Git-ը փոփոխությունների գրանցումն է․ յուրաքանչյուր խմբագրություն գրանցվում է՝ ով արեց, երբ և ինչու, և կարող եք վերադառնալ ցանկացած տարբերակի։
• GitHub-ը համատեղ սկավառակն է․ փաստաթուղթը գտնվում է առցանց, ուրիշները կարող են ստանալ պատճեն, և կա տեղ մեկնաբանելու և հաստատելու համար։
• Branch-ը նման է «նոր պատճենի՝ «նոր գնացուցակի բաժին» նախագիծ» պահելուն, որպեսզի փորձարկեք՝ առանց դիպչելու այն տարբերակին, որի վրա բոլորը հենվում են։ Եթե փորձը հաջողվի, միացնում եք հիմնականին՝ merge-ով։

Տարբերությունը փաստաթղթից մասշտաբն է։ Հավելվածը հարյուրավոր ֆայլեր է, և Git-ը դրանք բոլորը միասին է գրանցում, այնպես որ մեկ պատկերը նշանակում է ամբողջ նախագծի վիճակը միանգամից։

Git-ի և GitHub-ի տերմինները, որոնց կհանդիպեք

Երկու կետ արժե ընդգծել։ Առաջինը՝ Git-ի պատմությունը նախատեսված է մշտական լինելու համար․ եթե գաղտնաբառը commit արվել և push է եղել, հետագա commit-ում ջնջելը այն չի հեռացնում պատմությունից։ Երկրորդը՝ commit-ն օգտակար է այնքանով, որքանով նրա հաղորդագրությունը։ «Շտկել ամրագրման կրկնօրինակումը, երբ երկու մարդ միաժամանակ ամրագրում է» հետագայում օգնում է, «թարմացում»-ը՝ ոչ։

Օրինակ․ AI-ով կառուցված հավելվածը ազատ մշակողին հանձնելը

AI հավելվածի կառուցողով կառուցել եք հաճախորդների պորտալ։ Այն աշխատում է, բայց ուզում եք, որ ազատ մշակողը ավելացնի բարդ ինտեգրում ձեր հաշվապահական ծրագրի հետ։

1. Միացրեք նախագիծը նոր մասնավոր GitHub repository-ին և push արեք։ Repository-ն այժմ պարունակում է կոդը և նրա պատմությունը։
2. Ստուգեք, թե ինչ կա դրա մեջ։ Բացեք repository-ն GitHub-ում։ Չպետք է լինի .env ֆայլ և API բանալիներ կոդում։ Գաղտնիքները մնում են ձեր platform-ի կարգավորումներում և, եթե անհրաժեշտ է, առանձին են փոխանցվում մշակողին, տես՝ միջավայրի փոփոխականներ և գաղտնիքներ։
3. Հրավիրեք մշակողին որպես համագործակից միայն այդ repository-ում։
4. Նա աշխատում է branch-ում, որը կոչվում է օրինակ՝ accounting-sync, commit է անում քայլ առ քայլ և բացում pull request, երբ ավարտում է։
5. Դուք ստուգում եք pull request-ը։ Նույնիսկ առանց կոդը կարդալու կարող եք կարդալ նկարագրությունը, տեսնել, թե որ ֆայլերն են փոխվել, և հարցեր տալ մեկնաբանություններում։
6. Միացրեք (merge), երբ գոհ լինեք, ապա pull արեք փոփոխությունները ձեր կառուցողի մեջ, որ դուք և AI-ն շարունակեք նոր տարբերակից։

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

Սովորական սխալներ և թյուրըմբռնումներ

• «GitHub-ը և Git-ը նույնն են»։ Git-ն աշխատում է առանց GitHub-ի․ GitLab-ը և Bitbucket-ը նույնպես հյուրընկալում են Git repository-ներ։
• «GitHub-ը կաշխատեցնի իմ հավելվածը»։ GitHub-ը կոդ է պահում։ Հավելվածը հանրության համար աշխատեցնելը վեբ հյուրընկալում է, առանձին ծառայություն, թեև որոշ հարթակներ կարող են տեղակայել GitHub-ից։
• Գաղտնիքների commit անելը։ Ամենավնասակար և ամենատարածված սխալը։ Օգտագործեք .gitignore՝ .env ֆայլերի համար, և փոխեք յուրաքանչյուր բանալի, որը երբևէ push է եղել։
• Միայն մեկ branch և առանց հաղորդագրությունների։ Միայնակ փորձերի համար բավարար է, բայց ամեն ռիսկային աշխատանքի համար տվեք հստակ հաղորդագրություններ և օգտագործեք branch-ներ։
• Միաժամանակ երկու տեղում խմբագրելը։ Եթե GitHub-ում և AI կառուցողում միաժամանակ եք փոխում կոդը առանց pull-ի, ստեղծվում են conflict-ներ։ Ընտրեք մեկ տեղ խմբագրելու համար և համաժամեցրեք նախքան փոխելը։
• Կարծել, որ մասնավոր repository-ն ամբողջի պահուստն է։ Այն պահում է կոդը, ոչ թե ձեր տվյալների բազայի պարունակությունը կամ բեռնված ֆայլերը։ Դրանք պետք է առանձին պահուստավորվեն։

Ինչ խնդրել ձեր AI կառուցողից

• «Ավելացրու .gitignore, որը բացառում է .env-ը, կախվածությունների թղթապանակները և build-ի արդյունքը։»
• «Գրիր README, որը բացատրում է, թե ինչպես տեղադրել, ինչ միջավայրի փոփոխականներ են պետք (միայն անունները) և ինչպես աշխատեցնել հավելվածը։»
• «Ավելացրու .env.example՝ բոլոր փոփոխականների անուններով և առանց իրական արժեքների։»
• «Յուրաքանչյուր փոփոխության համար օգտագործիր հստակ, նկարագրական commit հաղորդագրություններ։»

Այս չորս խնդրանքը repository է ստեղծում, որը մշակողը մի քանի րոպեում կարող է ընկալել։ Հավելվածը ձեր սեփական սերվերներին տեղափոխելու համար տես ինչպես արտահանել և ինքնուրույն հյուրընկալել AI-ով կառուցված հավելվածը, իսկ իրական օգտատերերի առաջ ամրացնելու համար՝ AI նախատիպը արտադրություն տանելը։

GitHub-ը և Mythex-ը

Mythex-ը պատմությունը պահում է ձեզ համար յուրաքանչյուր պլանում․ յուրաքանչյուր հաջող agent քայլից հետո պահում է checkpoint, որը Git-ի պատկեր է և որին կարող եք վերադառնալ։ Pro պլանում կարող եք միացնել GitHub-ը և push կամ pull անել նախագիծը ձեր սեփական repository-ի հետ, կամ ներբեռնել ամբողջ նախագիծը արխիվով․ գաղտնիքներն ու տեղադրված կախվածությունները բացառվում են արտահանումից։ Այստեղ GitHub-ը կոդի համաժամեցման համար է, ոչ թե Mythex-ում մուտք գործելու համար։ Տես GitHub, արտահանում և ներմուծում փաստաթղթերում և գնային էջը, թե յուրաքանչյուր պլան ինչ է ներառում։

Հարցեր