Programmēšana

27 būtiski padomi Git un GitHub lietotājiem

Kaut arī Git lietotājiem ir desmitiem darba sākšanas rokasgrāmatu, no kuriem izvēlēties, un GitHub piedāvā vairākas savas rokasgrāmatas, joprojām nav viegli atrast noderīgu padomu kopumu izstrādātājiem, kuri vēlas gudrāk strādāt ar Git un GitHub. Labosim to.

Tiem no jums, kuriem Git vai GitHub nav sveši, nākamie daži punkti sniegs jums pietiekamu pamatu, lai saprastu padomus. Šī raksta beigās mēs uzskaitīsim apmēram duci noderīgu resursu.

Git ir izplatīta versiju kontroles sistēma, kuru sākotnēji Linuss Torvalds uzrakstīja 2005. gadā Linux kodola kopienai un ar tās palīdzību. Es neesmu šeit, lai jūs pārdotu vietnē Git, tāpēc es jums saudzēšu spielu par to, cik tas ir ātrs, mazs, elastīgs un populārs, taču jums tas jāzina, kad klonējat Git repozitoriju (īsi “repo”) , jūs savā datorā iegūstat visu versiju vēsturi, nevis tikai momentuzņēmumu no vienas filiāles vienlaikus.

Git sāka kā komandrindas rīks, kas atbilst tā izcelsmei Linux kodola kopienā. Jūs joprojām varat izmantot komandrindu Git, ja vēlaties, bet jums tas nav jādara. Jo īpaši, ja kā mitinātāju izmantojat GitHub, varat izmantot bezmaksas GitHub Desktop klientu operētājsistēmā Windows vai Mac. No otras puses, Git komandrinda darbosies jebkuram resursdatoram, un tā ir iepriekš instalēta lielākajā daļā Mac un Linux sistēmu.

Tikai jūs varat izlemt, vai jums ērtāk izmantot komandrindu vai vietējo klientu ar grafisko lietotāja saskarni. Ja jums patīk GUI, papildus GitHub klientam (Windows un Mac), iespējams, vēlēsities apsvērt SourceTree (Windows un Mac, bezmaksas), TortoiseGit (tikai Windows, bezmaksas) un Gitbox (tikai Mac, 14,99 USD). Vai arī varat izmantot redaktoru vai IDE, kas iekšēji atbalsta Git (sk. Padomu Nr. 11).

Git / GitHub padoms Nr. 1: Klonējiet gandrīz visu

GitHub un citās publiskajās Git krātuvēs ir pieejami daudzi interesanti projekti, kurus varat brīvi klonēt savā datorā. Kāpēc jūs vēlaties to darīt? Viens iemesls ir iemācīties kaut ko par kodēšanas stilu, praksi un rīkiem interesējošā valodā, ieskaitot apņemšanās žurnāla komentēšanas stilu (sk. Padomu Nr. 4). Otrs iemesls ir uzzināt, kā konkrētais projekts sasniedz savus mērķus. Trešais iemesls, ja licencēšana ļauj jums to darīt un ir jēga jūsu mērķiem, būtu projekta iekļaušana savos centienos vai produktā. Starp citu, vēlreiz pārbaudiet licenci, lai vēlāk nerastos problēmas ar atbilstību.

Definīcija git klons no rokasgrāmatas lapas:

Klonē krātuvi jaunizveidotajā direktorijā, izveido attālinātas izsekošanas zarus katram klonētā repozitorija atzaram (redzams, izmantojot git filiāle -r), kā arī izveido un pārbauda sākotnējo filiāli, kas ir izveidota no klonētā repozitorija pašreiz aktīvās filiāles.

Pēc klona klajums git atnest bez argumentiem atjauninās visas attālās izsekošanas filiāles un a git pull bez argumentiem attālā galvenā filiāle tiks apvienota arī ar pašreizējo galveno filiāli, ja tāda ir.

Git / GitHub padoms Nr. 2: velciet bieži

Viens no vienkāršākajiem veidiem, kā padarīt sev haosu ar Git (un patiesi, ar jebkuru versiju kontroles sistēmu), ir ļaut failiem izkļūt no sinhronizācijas. Ja jūs git pull bieži jūs atjaunināsiet repo kopiju un jums būs iespēja apvienot mainīto kodu ar citu izmaiņām, kamēr apvienošana ir viegli saprotama un izpildāma - ideālā gadījumā, kad tas ir tik vienkārši, ka to var izdarīt automātiski. Šī padoma sekas ir skatīties jūsu projekta statusu. Daudzi Git klienti automātiski parādīs, kad jums būs jāatjaunina, lai saglabātu jaunāko informāciju.

Git / GitHub padoms Nr. 3: apņemieties agri un bieži

Apņemšanās ir detalizēts projekta atjauninājums, kas ietver vienu vai vairākas izmaiņas vienā vai vairākos failos. Iedomājieties to kā pabeigta darba vienības ierakstu, ko var attiecināt uz projektu vai noņemt no tā kā par loģisku kopumu. Veiciet visas veiktās loģiskās izmaiņas pat pirms to pārbaudīšanas. Saistības attiecas tikai uz jūsu vietējo repozitoriju. Skatiet padomus Nr. 4 un 5 par šī padoma sekām.

Definīcija git apņemties no rokasgrāmatas lapas:

Tiek saglabāts pašreizējā indeksa saturs jaunā saistībā kopā ar žurnāla ziņojumu no lietotāja, kurā aprakstītas izmaiņas.

Git / GitHub padoms Nr. 4: komentējiet savas saistības tāpat kā citi komentētu viņu

Ir 10 veidu kodētāji: tie, kas komentē savas saistības, un tie, kas to nedara. (Vecs joks. Padoms: kādu pamatu es izmantoju?)

Es brīvi atzīstu, ka esmu uzlīmētājs labām žurnāla ziņām. Es izveidoju savus krātuves, lai pieprasītu ziņojumus par katru apņemšanos, un man ir zināms, ka es izsūtīju kaitinošas vēlu nakts ziņas, kad apņemas piezemēties ar žurnāliem pēc kārtas "xx". Ja esat izstrādātājs, kurš domā, ka (1) kodam vajadzētu runāt pašam par sevi, un (2) rindas komentāri ir daudz svarīgāki par izmaiņu žurnāliem, mēģiniet klonēt vēl nekad neredzētu krātuvi un identificēt nesen veiktas saistības, kas, iespējams, izraisīja jaunāko izdevumu, kas tika publicēts, neizlasot visu kodu. Kā redzat, precīzi apņemšanās žurnāli ir divkārši plus labi.

Git / GitHub padoms Nr. 5: nospiediet, kad tiek veiktas izmaiņas

Sliktākā ar Git saistītā kļūda, par kuru man jebkad ir bijusi nelaime, uzzināt, notika, kad ārpakalpojumu uzņēmums pārgāja no Subversion, bet nemācīja savus izstrādātājus par atšķirību starp izplatīto avotu kontroli un centralizēto avotu kontroli. Aptuveni mēnesi vēlāk projekts izstrādāja dīvainas kļūdas, kuras, šķiet, neviens nevarēja izsekot. Ikdienas stand-up sanāksmēs izstrādātāji, kas ir atbildīgi par nepareizi rīkojušās lietojumprogrammas apgabalu, protestētu: "Es to laboju pirms divām nedēļām!" vai apsūdzēt citu izstrādātāju, ka viņš netraucē ievilkt izmaiņas, kuras viņi bija tik rūpīgi reģistrējuši.

Galu galā kāds identificēja problēmu un visiem izstrādātājiem iemācīja, kā un kad grūst viņu saistības: Īsāk sakot, ikreiz, kad apņemšanās tiek veiksmīgi pārbaudīta vietējā būvē. Tad uzņēmums veica divu dienu ilgu apvienošanās festivālu, pirms varēja izveidot un izvietot atjaunināto, integrēto produktu.

Git / GitHub padoms Nr. 6: Branch filiāle

Viena no lielākajām priekšrocībām, ko Git piedāvā salīdzinājumā ar dažām citām versiju kontroles sistēmām, ir tā, ka apvienošana parasti darbojas labi, vismaz daļēji tāpēc, ka Git automātiski izvēlas labāko kopīgo senču, ko izmantot apvienošanai. Lielākajai daļai programmatūras izstrādātāju savos projektos jāsāk veidot filiāles biežāk. Tam vajadzētu būt ikdienas ikdienas gadījumam, nevis par satrauktu visu stratēģiju sapulces tematu. Iespējams, ka tad, kad filiāles projekts būs pabeigts, pieņemts un gatavs pāriet uz galveno projektu, apvienošana neradīs nepārvaramas problēmas.

Es zinu, ka tas ir jāpielāgo, it īpaši, ja esat iestrēdzis uzņēmumā, kas kontrolē pirmkodu ar CVS. Bet pamēģini. Tas ir daudz labāk nekā tas, ka klienti nejauši redz jūsu nepabeigto eksperimentālo kodu, kad bagāžnieka projekts ir jāpublicē kļūdainas kļūdas dēļ. (Šajā rakstā ir labi izskaidrota sazarošana un apvienošana.)

Git / GitHub padoms Nr. 7: uzmanīgi sapludiniet

Kaut arī apvienošanās ar Git parasti darbojas labi, ja jūs to darāt, nedomājot, jūs laiku pa laikam varat saskarties ar grūtībām. Pirmais solis ir pārliecināties, ka jums nav neizpildītu izmaiņu. No apvienot rokasgrāmatas lapa:

Pirms ārēju izmaiņu piemērošanas jums pašiem vajadzētu būt labā formā un paveikt vietējā līmenī, tāpēc konfliktu gadījumā tas netiks aplaupīts. Skatīt arī git-atlicināt.

Skatīt arī padomu Nr. 8.

Pat ja tas viss iet uz dienvidiem a laikā apvienot, jums nav šļūtenes:

Ja mēģinājāt apvienot, kas izraisīja sarežģītus konfliktus, un vēlaties sākt no jauna, varat atjaunoties git sapludināt - aborts.

Turpmākā komanda apvienot parasti ir git mergetool, pieņemot, ka apvienošanai vēlaties izmantot GUI. Ja vēlaties izmantot vecās skolas metodi, varat rediģēt failus, kas ir pretrunā ar iecienītāko programmēšanas redaktoru, pilnībā noņemiet <<<<<<<, =======, un >>>>>>> rindas, saglabājiet pārskatītos failus un git pievienot katru failu, kuru labojāt.

Git / GitHub padoms Nr. 8: nolieciet pirms zaru maiņas

Programmatūras izstrādātāja darbplūsma reti ir lineāra. Lietotājiem ir žults ziņot par kļūdām, vadītājiem ir uzdrīkstēšanās noteikt prioritāti citām biļetēm, nevis tām, kuras izvēlējāties strādāt, un jūs pats varētu mainīt domas par to, ko vēlaties darīt.

Tur jūs esat ar trim failiem, kas paredzēti izlaišanai, un ceturto failu mainītā, bet nedarbojošā stāvoklī. (The git statuss komanda jums to visu pateiks, ja nejauši neatceraties savu atrašanās vietu.) Pēkšņi jums jāstrādā pie kļūdu labojuma ražošanas versijā. Jums ir jāpārslēdz filiāles tieši, bet nevarat. Jūsu darba katalogs ir netīrs, un jums ir divas stundas darba, ko nevēlaties zaudēt.

Enter git atlicināt. Voilà! Tagad visas jūsu izmaiņas ir saglabātas WIP (work in progress) filiālē, un jūs varat pārslēgties uz ražošanas filiāli no sava tīrā direktorija. Kad tas ir paveikts, pārslēdzieties atpakaļ uz vietu, kur bijāt piemērot git atlicināt.

Git / GitHub padoms Nr. 9: Izmantojiet kopsavilkumus, lai kopīgotu fragmentus un pastas

GitHub “kopsavilkumi” - koplietoti koda fragmenti - nav Git funkcija, taču tajos tiek izmantots Git. Visi kopsavilkumi ir Git krātuves, un GitHub Gist atvieglo to kopīgošanu. Gist varat meklēt publiskos kopsavilkumus pēc tēmas, programmēšanas valodas, statusa ar zvaigznīti un ar zvaigznīti atzīmētā statusa. Varat arī izveidot slepenus kopsavilkumus un kopīgot tos pēc URL.

Git / GitHub padoms Nr. 10: izpētiet GitHub

Daudziem interesantiem atvērtā koda projektiem ir GitHub krātuves. Pārlūkot GitHub nodrošina pārlūkošanas saskarni, lai atrastu dažus no tiem, taču galvenokārt ir vieglāk meklēšanas lodziņā ierakstīt dažus projekta nosaukuma burtus, lai atrastu tā repo. Piemēram, ierakstiet jq vai atpakaļ vai ang lai atrastu trīs galvenos atvērtā koda JavaScript ietvarus.

Git / GitHub padoms Nr. 11: Piedalieties atklātā pirmkoda projektos

Kamēr jūs pārlūkojat atvērtā koda projektus, kāpēc gan nepiedalīties tajos? Tas nav tik grūti, kā jūs domājat, un jūs daudz uzzināsiet. Piemēram, jūs varētu klonēt jquery / jquery (jQuery Core) projektu un pārlūkot README.MD. Netālu no augšdaļas redzēsiet:

Atklātā pirmkoda programmatūras izstrādes garā jQuery vienmēr veicina kopienas koda ieguldījumu. Lai palīdzētu jums sākt darbu un pirms sākat rakstīt kodu, noteikti rūpīgi izlasiet šīs svarīgās ieguldījumu vadlīnijas ...

Tam seko trīs saites. Pirmais no trim ļaus jums sākt darbu diezgan ātri. Ne katrs atvērtā koda projekts tik skaidri izklāsta plānu, bet viņi visi cenšas.

Izprot atšķirību starp līdzdalībnieku un saistību izpildītāju. Līdzstrādnieks ir parakstījis nepieciešamos līgumus un padarījis ieguldījumu pieejamu projektam. Pienācējs ir pilnvarots faktiski veikt piedāvāto ieguldījumu projekta krātuvē. Tā kā būs kavēšanās, kamēr iesācējs pārbaudīs jūsu ieguldījumu, un jūs nevēlaties saistīt savu galveno filiāli, pirms izmaiņu pieprasījuma izsūtīšanas jums jāveic izmaiņas citā filiālē (sk. Padomu Nr. 6) (sk. Padomu Nr. 16).

$config[zx-auto] not found$config[zx-overlay] not found