Kaip naudoti Git su DI sukurta programėle

Kad naudotumėte Git su DI sukurta programėle, prijunkite projektą prie Git saugyklos, įrašykite kiekvieną veikiantį pakeitimą, parašykite vienos eilutės žinutę, nurodančią, kas pasikeitė, ir paslaptis laikykite už ribų naudodami .gitignore. Rizikingiems darbams naudokite šaką, prieš vėl duodami užklausą atsisiųskite pakeitimus, jei kodą pakeitė kas nors kitas, o kai DI ką nors sugenda, grįžkite prie paskutinio gero įrašo, o ne rašykite naują užklausą ant esamos netvarkos.

Git yra versijų valdymas: kiekvienos išsaugotos kodo versijos istorija. GitHub yra svetainė, kurioje Git saugyklos laikomos internete. Jei tai dar nauja, pradėkite nuo ko yra GitHub. Šis gidas skirtas įpročiams, kurie padaro Git naudingą, kai didžiąją kodo dalį rašo DI.

Kodėl Git su DI svarbesnis

DI per vieną kartą gali pakeisti dvidešimt failų. Tai greita, bet tai reiškia, kad viena užklausa gali tyliai sugadinti tai, kas vakar veikė. Git suteikia:

• Būdą grįžti. Bet kurią įrašytą versiją galima atkurti.
• Pakeitimų įrašą. Galite tiksliai matyti, kuriuos failus ir eilutes užklausa palietė.
• Kopiją už kūrimo įrankio ribų. Jūsų kodas laikomas ten, kur turite kontrolę.
• Standartinį perdavimą. Bet kuris kūrėjas, platforma ar įrankis gali dirbti su Git saugykla.

1 žingsnis: prijunkite saugyklą

Sukurkite saugyklą (paprastai privačią) GitHub ar panašioje paslaugoje ir prijunkite projektą prie jos. Dauguma DI programėlių kūrimo įrankių, palaikančių Git, tai daro nustatymų puslapyje mygtuku „Connect GitHub“. Jei jūsų įrankis to neturi, galite eksportuoti kodą ir įkelti jį patys arba paprašyti kūrėjo nustatyti tai vieną kartą.

Prieš pirmą įkėlimą įsitikinkite, kad saugykla ignoruoja tai, ko joje neturi būti:

Patikrink .gitignore failą. Įsitikink, kad jame yra .env failai, node_modules, kompiliavimo rezultatų aplankai ir visi failai su paslaptimis. Pasakyk, ką pridėjai.

2 žingsnis: įrašykite po kiekvieno veikiančio pakeitimo

Įrašas (commit) yra išsaugota kopija su žinute. Svarbiausias įprotis: įrašykite, kai kažkas veikia, prieš prašydami kito dalyko.

1. Duokite užklausą vienam pakeitimui.
2. Patikrinkite peržiūroje.
3. Jei veikia, įrašykite (arba sinchronizuokite) su žinute.
4. Tada judėkite toliau.

Maži įrašai reiškia, kad kai kas nors sugenda, žinote, kuris pakeitimas tai padarė, ir jo atšaukimas neišmeta kito darbo.

3 žingsnis: rašykite žinutes, kurias vėliau galėsite perskaityti

Gera žinutė vienoje eilutėje pasako, kas pasikeitė ir kodėl:

• Gerai: Add CSV export to the orders page
• Gerai: Fix booking form rejecting times after 6pm
• Nenaudinga: update, changes, fix stuff

Galite paprašyti DI jas parašyti:

Apibendrink pakeitimus nuo paskutinio įrašo vienoje eilutėje, pradėk veiksmažodžiu, iki 70 simbolių.

4 žingsnis: naudokite šakas rizikingiems darbams

Šaka yra atskira darbo linija. Galite išbandyti kažką šakoje, o jei neveikia, ją atsisakyti, nepaliesdami pagrindinės versijos.

Naudokite šaką, kai:

• Pakeitimas didelis (perdarymas, naujas mokėjimo srautas, duomenų bazės pakeitimas).
• Kitas žmogus dirba su ta pačia programėle.
• Norite, kad kas nors peržiūrėtų pakeitimą prieš jį paleidžiant.

Kai darbas atliktas ir išbandytas, jis sujungiamas (merge) atgal į pagrindinę šaką. GitHub'e tai paprastai daroma per pull request — puslapį, kuriame rodomi pakeitimai peržiūrai. Jei jūsų įrankis sinchronizuoja tik vieną šaką, šakas GitHub'o pusėje gali tvarkyti kūrėjas.

5 žingsnis: saugiai atšaukite

Kai užklausa sugadina programėlę, pasipriešinkite norui duoti dar penkias užklausas ant jos. Grįžkite prie paskutinės geros versijos ir pabandykite aiškesnę užklausą.

• Kūrimo įrankyje: naudokite jo kontrolinio taško arba atkūrimo funkciją, jei ji yra.
• Git: git revert sukuria naują įrašą, kuris atšaukia senesnį, išsaugodamas istoriją. Tai saugus pasirinkimas kodui, kurį kiti gali jau buvo atsisiuntę.
• Venkite git push --force bendrojoje šakoje, nebent tiksliai žinote, kodėl. Tai perrašo istoriją visiems.

Jei nesate tikri, paklauskite:

Paskutinis pakeitimas sugadino prisijungimo puslapį. Parodyk, kokius failus jis pakeitė, palyginus su ankstesniu įrašu, ir paaiškink, ką kiekvienas pakeitimas darė. Kol kas nieko nekeisk.

6 žingsnis: prieš duodami užklausą atsisiųskite pakeitimus

Jei kūrėjas ar kitas įrankis pakeičia kodą GitHub'e, DI kūrimo įrankis to nežino, kol nepritraukiate tų pakeitimų su pull. Užklausa senam kodui sukelia konfliktus ir prarastą darbą.

• Atsisiųskite pakeitimus kiekvienos sesijos pradžioje.
• Susitarkite, kas ką redaguoja, ir venkite, kad abi pusės tuo pačiu metu redaguotų tuos pačius failus.
• Jei gaunate merge conflict (du pakeitimai toms pačioms eilutėms), paprašykite kūrėjo ar DI jį išspręsti ir paaiškinti pasirinkimą.

Pavyzdinės užklausos

Prieš pradedant: kas pasikeitė saugykloje nuo mano paskutinės sesijos? Apibendrink įrašus.

Atlik kitą pakeitimą atskirai: pridėk mygtuką „Duplicate“ prie kiekvienos sąskaitos. Nieko kito nekeisk, kad galėčiau jį įrašyti atskirai.

Patikrink, ar Git'e nėra API raktų, slaptažodžių ar .env failų, įskaitant ankstesnius įrašus. Pateik tik failų pavadinimus, ne reikšmes.

Dažnos klaidos

• Paslapčių įrašymas. Kai raktas patenka į Git istoriją, jis tampa viešas, net jei failą vėliau ištrinate. Pakeiskite raktą.
• Vienas didelis įrašas per savaitę. Negalite atšaukti vieno pakeitimo neatšaukdami visų.
• Žinutės „update“. Istorija tampa beverte ieškant, kas sugedo.
• Darbas su pasenusiu kodu. Prieš dirbdami atsisiųskite pakeitimus, jei kas nors kitas redaguoja.
• Klaidos taisymas su force-push. Tai gali ištrinti kitų žmonių darbą. Vietoj to atlikite revert.
• node_modules įrašymas. Jis didelis ir vis tiek atkuriamas iš lock failo.

Kontrolinis sąrašas

• Projektas prijungtas prie privačios saugyklos.
• .gitignore ignoruoja .env, node_modules, kompiliavimo rezultatus ir paslaptis.
• Įrašau po kiekvieno veikiančio pakeitimo.
• Įrašų žinutės vienoje eilutėje aiškiai nurodo, kas pasikeitė.
• Dideli ar rizikingi pakeitimai eina į šaką ir yra peržiūrimi.
• Prieš duodamas užklausą atsisiunčiu pakeitimus, jei kodą redaguoja kas nors kitas.
• Atšaukiu naudodamas kontrolinius taškus arba git revert, o ne force-push.
• Bet kuris raktas, kuris kada nors buvo įrašytas, yra pakeistas.

Git Mythex platformoje

Mythex išsaugo git kontrolinį tašką po kiekvieno sėkmingo agento veiksmo, o Revert to this point grąžina projektą į jį — tai kūrimo įrankio pusės atšaukimas, aprašytas 5 žingsnyje. Žr. Iterate without rebuilding.

Pro plane GitHub sync prijungia saugyklą iš projekto nustatymų, kad galėtumėte įkelti ir atsisiųsti pakeitimus, o export atsisiunčia projektą be paslapčių ir node_modules. Žr. GitHub, export, and import. Prieš perduodant projektą kūrėjui prijungti GitHub labai supaprastina perdavimą — žr. kaip dirbti su kūrėju su DI sukurta programėle ir kaip eksportuoti ir savarankiškai talpinti DI sukurtą programėlę.

Klausimai