Reklāma
Būdami tīmekļa izstrādātāji, mēs bieži strādājam vietējās attīstības vietnēs, un pēc tam vienkārši augšupielādējiet visu, kad esam to paveikuši. Tas ir labi, ja runa ir tikai par jums, un izmaiņas ir mazas, bet, ja jums ir darīšana ar vairāk nekā vienu persona, kas strādā pie kaut kā vai liela projekta, kurā ir daudz sarežģītu komponentu, tas vienkārši nav iespējams. Tas ir, kad mēs pievērsīsimies tā dēvētajai versiju kontrolei.
Šodien es runāšu par atvērtā pirmkoda versiju kontroles programmatūru ar nosaukumu Git. Tas ļauj vairāk nekā vienai personai droši strādāt pie viena un tā paša projekta, netraucējot viens otram, taču tas ir arī daudz vairāk.
Kāpēc jāizmanto versiju kontroles programmatūra?
Pirmkārt un galvenokārt, vārdam tas to vajadzētu atdot. Versiju kontroles programmatūra ļauj jums iegūt projekta “versijas”, kas parāda izmaiņas, kas laika gaitā tika veiktas kodā, un vajadzības gadījumā ļauj atgriezties, un atsaukt šīs izmaiņas. Tikai šī spēja - salīdzināt divas versijas vai mainīt izmaiņas - padara to par diezgan nenovērtējamu, strādājot pie lielākiem projektiem.
Jūs, iespējams, kaut kādā brīdī esat to izdarījis pats, ietaupot projekta kopijas dažādos punktos, lai jums būtu rezerves kopija. Versiju kontroles sistēmā tiks saglabātas tikai izmaiņas - ielāpa fails, ko varētu lietot vienai versijai, lai tā būtu tāda pati kā nākamā versija. Ar vienu izstrādātāju tas ir pietiekami.
Bet ko darīt, ja projektā strādā vairāk nekā viens izstrādātājs? Tas ir tad, kad rodas ideja par centralizētu versiju kontroles serveri. Tie jau sen ir standarts, saskaņā ar kuru visas versijas tiek glabātas uz centrālā servera, un atsevišķi izstrādātāji izrakstās un augšupielādē izmaiņas atpakaļ uz šo serveri. Ja kādreiz esat apskatījis Wikipedia lapas rediģēšanas vēsturi, jums būs labs priekšstats par to, kā tā darbojas reālās pasaules scenārijā:
Šādas sistēmas priekšrocības ir tādas, ka izmaiņas var veikt vairāki izstrādātāji, un tad katras izmaiņas var attiecināt uz konkrētu izstrādātāju. Negatīvie ir tas, ka viss tiek saglabāts attālā datu bāzē, tas nozīmē, ka, serverim samazinoties, izmaiņas nevar veikt. un ja tiek pazaudēta centrālā datu bāze, katram klientam ir tikai tā versija, kurā viņi strādāja.
Tas mūs ved uz Gitu un citiem tā sauktajiem izplatītas versiju kontroles sistēmas. Šajās sistēmās klienti ne tikai pārbauda pašreizējo failu versiju un strādā no tām - viņi atspoguļo visu versiju vēsturi. Katram izstrādātājam vienmēr ir pilnīga visa kopija. Joprojām tiek izmantots centrālais serveris, bet, ja notiek vissliktākais, visu joprojām var atjaunot no jebkura klienta, kuram ir jaunākās versijas.
Git īpaši darbojas, uzņemot failu momentuzņēmumus; ja faili konkrētā versijā paliek nemainīgi, tā vienkārši saista ar iepriekšējiem failiem - tas visu uztur ātri un elastīgi.
Varētu jūs arī interesēt uzzināt, ka Git tiek izmantots, lai pārvaldītu un attīstītu kodols linux kodola - pamata celtniecības bloks, uz kura ir būvēti visi Linux distros.
Kas ir Github?
Lai gan jūs pats varat palaist savu Git serveri lokāli, Github ir gan attālais serveris, gan izstrādātāju kopiena, gan grafiska tīmekļa saskarne jūsu Git projekta pārvaldīšanai. To var bez maksas izmantot ne vairāk kā 5 publiskajām krātuvēm - tas ir, kad ikviens var apskatīt vai dabūt jūsu kodu - ar zemu izmaksu plāniem privātiem projektiem. Es ļoti iesaku reģistrēties bezmaksas kontam, lai jūs varētu sākt spēlēt ar saviem projektiem vai likt kādam citam citu.
Dakšas un sazarojumi
Šie ir Git pieredzes pamatjēdzieni, tāpēc pievērsīsim laiku, lai izskaidrotu atšķirību.
Jūs, iespējams, esat dzirdējis darbu “dakša”, strādājot ar linux distros. Ja esat pazīstams ar multivides centra lietotni Plex, jūs zināt, ka tā sākotnēji bija līdzīga atvērtā avota dakša Xbox multivides centrs Aeon Nox 3.5: skaista un pielāgojama tēma XBMCIestatiet multivides centru tieši tā, kā vēlaties. Aeon Nox 3.5 ir jaunākā versija, kas, iespējams, ir labākā XBMC tēma, un tā ir reta kombinācija: skaista ... Lasīt vairāk . Tas vienkārši nozīmē, ka kādreiz pagātnē daži izstrādātāji paņēma XBMC kodu un nolēma iet ar savu ceļu; kas kļuva par Pleksu.
Tas, protams, ir pilnīgi atļauts, ja projekts ir atvērts avots - ar to jūs varat ņemt kodu, darīt visu, ko vēlaties. Izmantojot Git, ja jūs uzskatāt, ka jūsu veiktās izmaiņas ir pietiekami labas, lai jūs atgrieztos “master” projektā, jūs var autoram iesniegt “pieprasījuma pieprasījumu”, lūdzot viņu atgriezt jūsu izmaiņas oriģinālā projekts. Tas ļauj simtiem tūkstošu izstrādātāju jebkurā brīdī strādāt pie projekta, no kuriem nevienam nav jābūt Nepieciešams, lai tie tiktu apstiprināti piekļuvei kodam - viņi vienkārši kopē kodu, veic izmaiņas un pieprasa, lai tie atkal tiek ievietoti kodā meistars. Protams, sākotnējā projekta īpašnieks pats izlemj, vai pieņemt izmaiņas vai nepieņemt.
Sazarojums ir kaut kas, ko projektā veic autorizētie izstrādātāji. Tas ļauj jums viegli nodalīt noteiktas problēmas vai funkcijas un strādāt ar tām, nesalaužot pamatfailus. Kad esat pārliecināts, ka jūsu filiāle ir izskatījusi problēmu, jūs to sapludināt atpakaļ galvenajā pārvaldē. Jebkurā brīdī var būt tik daudz zaru, cik vēlaties; viņi netraucē viens otram. Varat arī apvienot izmaiņas starp zariem, nepieskaroties galvenajam.
Šeit ir lieliska diagramma par darbplūsmas piemēru Vincents Driessens:
Nākamreiz mēs apskatīsim, kā izveidot funkcionējošu Git piemēru un veikt izmaiņas filiālēs. Versijas kontrole ir milzīga tēma. Šeit es sniedzu tikai īsu pārskatu, bet kā izstrādātājs, kurš ir pieradis tikai veikt izmaiņas un atsaukt tās, ja tās nedarbojas, visa ideja ir ienesusi prātā - es ceru, ka tā ir arī jūsu.
Vai esat pieredzējis izstrādātājs ar pieredzi Gitā? Vai jūs tikko sākat darbu un domājat, ka vēlaties doties prom? Skaņu komentāros!
Džeimsam ir mākslīgā intelekta bakalaura grāds, un viņš ir sertificēts CompTIA A + un Network +. Viņš ir galvenais MakeUseOf izstrādātājs un brīvo laiku pavada, spēlējot VR peintbolu un galda spēles. Kopš mazotnes viņš būvēja datorus.