Kas ir GitHub? Versiju kontrole bez programmēšanas zināšanām

GitHub ir tīmekļa vietne, kur glabā programmatūras projektu kodu kopā ar pilnu vēsturi, tāpēc vari redzēt katru izmaiņu, labot kļūdas un strādāt pie viena projekta kopā ar citiem cilvēkiem. Tas balstās uz Git — bezmaksas programmatūru, kas laika gaitā fiksē projekta failu momentuzņēmumus. Git glabā vēsturi; GitHub ir tiešsaistes mītne, kur šī vēsture tiek kopīgota, dublēta un pārrunāta.

Ja veido ar MI, GitHub galvenokārt nozīmē divas lietas: savas koda kopijas paturēšanu ārpus rīka, kurā to izveidoji, un nodošanu izstrādātājam formātā, ar kuru viņš jau strādā.

Kāpēc tas svarīgi, veidojot ar MI

MI lietotņu veidotājs ļoti ātri raksta un maina daudz koda, un ne visas izmaiņas ir uzlabojumi. Versiju kontrole palīdz to darīt droši.

• Droši atsaukt. Katra saglabātā izmaiņa ir momentuzņēmums. Ja MI kaut ko salauž, atgriezies pie pēdējās labās versijas.
• Īpašumtiesības. Kods tavā GitHub kontā paliek tavs, ja maini rīku, pārtrauc maksāt par kādu no tiem vai vēlies otru viedokli.
• Darbs ar izstrādātājiem. Gandrīz katrs izstrādātājs ikdienā lieto Git. Repozitorijs ļauj viņam pārskatīt, ko MI uzrakstīja, to labot un nosūtīt izmaiņas atpakaļ.
• Izvietošana citur. Daudzas hostinga platformas var izvietot lietotni tieši no GitHub repozitorija.

Ikdienas analoģija: izsekotās izmaiņas un kopīgs disks

Iedomājies dokumentu ar ieslēgtām izsekotajām izmaiņām, kas glabājas kopīgā diskā.

• Git ir izsekotās izmaiņas: katrs labojums tiek ierakstīts kopā ar to, kas to izdarīja, kad un kāpēc, un vari atgriezties pie jebkuras versijas.
• GitHub ir kopīgais disks: dokuments atrodas tiešsaistē, citi var saņemt kopiju, un ir vieta komentāriem un apstiprinājumiem.
• Zars (branch) ir kā kopijas saglabāšana ar nosaukumu „melnraksts — jaunā cenu sadaļa”, lai varētu eksperimentēt, nepieskaroties versijai, uz kuras visi paļaujas. Ja eksperiments izdodas, to ieliec atpakaļ.

Atšķirība no dokumenta ir mērogā. Lietotne ir simtiem failu, un Git tos visus izseko kopā, tāpēc momentuzņēmums ir visa projekta stāvoklis vienlaikus.

Git un GitHub termini, ar kuriem sastapsies

Divas lietas vērts uzsvērt. Pirmkārt, Git vēsture pēc dizaina ir pastāvīga: ja parole ir iekļauta commit un nosūtīta, vēlāka dzēšana to no vēstures nenoņem. Otrkārt, commit ir tikpat noderīgs, cik ir tā ziņojums. „Labo dubultu ieskaitu, kad divi cilvēki rezervē vienlaikus” palīdz vēlāk; „atjauninājums” nepalīdz.

Darba piemērs: MI veidotas lietotnes nodošana frīlanseram

Ar MI lietotņu veidotāju izveidoji klientu portālu. Tas strādā, bet vēlies, lai frīlanseris pievieno sarežģītu integrāciju ar tavu grāmatvedības programmatūru.

1. Pievieno projektu jaunam privātam GitHub repozitorijam un nosūti. Repozitorijā tagad ir kods un tā vēsture.
2. Pārbaudi, kas tajā ir. Atver repozitoriju GitHub. Tajā nevajadzētu būt .env failam un nevienai API atslēgai kodā. Noslēpumi paliek tavas platformas iestatījumos, un ar izstrādātāju tos dalies atsevišķi, ja vispār — skat. vides mainīgie un noslēpumi.
3. Uzaicini frīlanseri kā līdzstrādnieku tikai uz šo repozitoriju.
4. Viņš strādā zarā, piemēram, accounting-sync, veic commit pa ceļam un, kad pabeidz, atver pull request.
5. Tu pārskati pull request. Pat bez koda lasīšanas vari izlasīt aprakstu, pārbaudīt, kuri faili ir mainījušies, un uzdot jautājumus komentāros.
6. Sapludini, kad esi apmierināts, un tad atnes izmaiņas atpakaļ savā veidotājā, lai tu un MI turpinātu no jaunās versijas.

Šajā procesā vari tieši redzēt, kas mainījies, un to atsaukt, ja vajag. Tieši tāda ir versiju kontroles vērtība vienā darbplūsmā. Ja vēl pārdomā, vai vispār iesaistīt izstrādātāju, skat. izstrādātāja samaksāšana vai veidošana ar MI.

Biežākās kļūdas un maldīgi priekšstati

• „GitHub un Git ir viens un tas pats.” Git darbojas arī bez GitHub; citas platformas, piemēram, GitLab un Bitbucket, arī mitina Git repozitorijus.
• „GitHub palaidīs manu lietotni.” GitHub glabā kodu. Lietotnes palaišana publikai ir tīmekļa hostings, atsevišķs pakalpojums (lai gan dažas platformas var izvietot no GitHub).
• Noslēpumu iesūtīšana. Visbojājošākā un visbiežākā kļūda. Izmanto .gitignore .env failiem un nomaini jebkuru atslēgu, kas jebkad ir nosūtīta.
• Tikai viens zars un nekādu ziņojumu. Der solo eksperimentiem, bet dod commit skaidrus ziņojumus, un riskantām lietām izmanto zarus.
• Rediģēšana divās vietās vienlaikus. Ja maini kodu GitHub un MI veidotājā, nesinhronizējot starp tām, rodas konflikti. Vienlaikus rediģē vienā vietā un pirms pārslēgšanās sinhronizē.
• Domāt, ka privāts repozitorijs ir pilnīga visa dublēšana. Tajā ir kods, nevis tavas datubāzes saturs vai augšupielādētie faili. Tiem vajag savu dublēšanu.

Ko lūgt savam MI veidotājam

• „Pievieno .gitignore, kas izslēdz .env, atkarību mapes un būvējuma izvadi.”
• „Uzraksti README, kas izskaidro instalēšanu, nepieciešamos vides mainīgos (tikai nosaukumus) un to, kā palaist lietotni.”
• „Pievieno .env.example ar katra mainīgā nosaukumu un bez reāliem datiem.”
• „Katrai izmaiņai izmanto skaidrus, aprakstošus commit ziņojumus.”

Šie četri pieprasījumi rada repozitoriju, ko izstrādātājs var pārņemt minūtēs. Lai pārvietotu lietotni uz saviem serveriem, skat. kā eksportēt un pašmitināt MI veidotu lietotni, un lai to nostiprinātu pirms reāliem lietotājiem, — MI prototipa pārvešana uz produkciju.

GitHub un Mythex

Mythex katrā plānā vēsturi glabā tavā vietā: pēc katras veiksmīgas aģenta kārtas tas saglabā kontrolpunktu, kas ir Git momentuzņēmums, uz kuru var atgriezties. Pro plānā vari pieslēgt GitHub un nosūtīt vai atnest projektu ar savu repozitoriju vai lejupielādēt visu projektu kā arhīvu; noslēpumi un instalētās atkarības eksportā netiek iekļautas. Šeit GitHub ir koda sinhronizēšanai, nevis pierakstīšanās Mythex. Skat. GitHub, eksportu un importu dokumentācijā un cenu lapu, kur redzams, ko ietver katrs plāns.

Jautājumi