laacz.lv

Kaspara F. neoficiālā mājaslapa (Anno 1997)

Šķēršļpārvare

Sveiks, izstrādātāj. Tagad es tev pateikšu, ka zinu, ka tu nelieto versiju kontroli. Nejau tāpēc, ka nevēlies, bet gan tāpēc, ka nesanāca…

Noteikti esi pamēģinājis, bet kādā brīdī noslinkoji un pēc tam jau izmaiņas ir savākušās tik daudz, ka tā īsti nevari sadalīt pa smukiem individuālām izmaiņām. Es nākšu talkā ar to, kas man ir – padomu. Neesi perfekcionists. Tas ir tavs kods, tu aizmirsi, esi vecis (vecene) – atzīsti. Tas īsti nav iemesls neturpināt konkrētā projektiņa ietvaros lietot versiju kontroli.

Saņemies un izdari git commit -m “All the changes I forgot. Deal with it.”. Viss, lieta darīta. Tālāk jau vari mēģināt palēnām atkal. Ja aizmirsīsi vai noslinkosi vēlreiz, iesit sev imagināru vai reālu pļauku (whatever works for you), mazliet nokaunies un izdari šo vēlreiz. Ar laiku versiju kontrole izstrādes ciklā iedzīvosies pati no sevis.

Kas attiecas uz strādāšanu pie vairākām lietām vienlaicīgi, git branch ir tavs draugs. Bet par to citreiz.

P.S. Jā, zinu, ka esmu centies rakstīt par git un tā arī neko neesmu uzrakstījis. Tagad es centīšos vēl.

Papuass

Varbūt vaina ir rīkos? Ja nepatīk komandrinda, nu jau ir pieejama kaudze feiniem grafiskajiem rīkiem. Pats šobrīd aktīvi lietoju Atlassian SourceTree, var mierīgi iztikt bez skatīšanās manuālī par katru komandu.

Mārcis

Arī nesen sāku lietot SourceTree. Ļoti ērti un lietotājam draudzīgi. Tiesa ne visus failu saprot un spēj atrisināt konfliktus. Piemēram, Xcode projektu failus nesaprot.

koko

No problemo… Kopš pieliku st git pļurgenu, arī git komandas ir iegājušās ikdienā ļoti bieži un, protams, branči ir osam!

Jāatzīst, ka commit logs reizēm (kad klients cimperlīgs un visādi sīkumi jālabo) ir pabriesmīgs un pat rupjšs

Ivars

Starpcitu, varbūt Laacz ir saskāries ar tādu lietu kā remote code deployment?
Uz maciem ir Capistrano, bet varbūt uz Windozes arī ir kāds smuks un ērts consoles rīks tam?

P.S.
Zinu, zinu, Capistrano var caur Žõ uzlikt arī uz Win, bet tas nav variants.

laacz

Nope, uz Win neesmu deployojis. Pagaidām mazajiem projektiņiem deploy notiek tīri no specifiska brenča ar post-receive hūku. Principā – continuous deployment. Lielu man, savukārt, sen jau vairs nav.

laacz

Lieliem projektiem tas var nederēt, jo ne vienmēr izmaiņas skar to, kas ir versiju kontrolē. Piemēram, datubāze bez atbalsta kodā (papildus indekss vai cita sistēmai), utt. Uz hūka var uzkarināt visu, kas nāk no VCS, bet ne viss nāk no turienes.

Ansis

Kāpēc git? Mani ļoti interesē katra savējais kāpēc.

Es sev nespēju nopamatot git lietderību. Vai tiešām kādam reāli vajag merdžus pa zariem un repozitorijiem?

Man katra sastapšanās ar git vai hg ir kā vizīte pie zobārsta :(

laacz

Kāpēc ne? Viena nianse – gits ir jāsaprot. Tas nav vienkāršs (galu galā, autors ir jocīgs), kā arī decentralizācija tīri konceptuāli liek ieviest jaunas lietas. Bet, ko es noteikti varu pateikt – apgūšana atmaksājas. Ieteiktu apgūt Git pamatus (procesus, terminoloģiju, ar hands on workshopu) un dažādo iespējamo workflowu konceptus. Gan patērētā laika ziņā, gan iespēju ziņā tas vēlāk atmaksāsies ar uzviju.

Kas man patīk? Git ir decentralizēts – darbā pull, [work], push un tad arī, ja vajag, mājās var pull, [work], push. Vari strādāt un komitot bez servera.

Jebkuras izmaiņas ir tikai pointeris un delta. Vietas, resursu un trafika ietaupījums milzīgs. Ja neskaita milzīgas merges, kas tīši vai netīši gadās, ja aizmirst par rebase :)

Branchus pats aktīvi izmantoju arī individuāli strādājot – ja ir jauna fīča vai nopietnāks refaktorings, jauns brančs un done. Kad vajag hotfiksu, develop (vai mazākos projektos – master) čekauts (hfx brančus pats gan neizmantoju). Kad pierod, ir diktiņ ērti un nav vairs īsti skaidrs – kā savādāk. Branchi ir pati sāls, tos nevajag krāt kā sīpola leijerus, protams, bet būt viena branča attālumā no galvenā zara ir pilnīgi normāli un lieliska lieta.

Bez branchiem noteikti jāsaprot arī stash steks.

Ir, protams, sanācis piedzīvot arī merge hell, bet tam ir divas izejas – kurš nu kuram patīk labāk. Pirmais ir klasiskais `rebase`, kur ir jāiegaumē tik pāris pamatformulas – rebāzē tikai to, kas nav iekš HEAD. Pēc tam jau viss ir ff un lieta cepurē. Otrs variants – pull requestu ceļš. Tas nozīmē, ka uz svarīgajiem brančiem (master, piemēram) var pushot tikai daži cilvēki vai bots.

Īsāk sakot – jā, ar gitu ir jāpacīnās un tas ir jāapgūst. Bet, kad tas reiz ir izdarīts, viss kļūst skaists un saulains. Bet šausmu stāstus stāstīt var par jebko.

Vilx-

Cik es palasījos, decentralizētie merge bija tikai daļa no sāls. Pārējie labumi ir:

– Viegli strādāt ar zariem. Laacz to ne īsti labi izstāstīja. SVN’ā, piemēram, ja uztaisa jaunu zaru, tad jāčeko vēlreiz ārā citā folderī. GITs savukārt ar zariem strādā vienā un tajā pašā folderī (working kopijā). Tu vienkārši pārslēdzies starp viņiem ar vienu īsu komandu. Galu galā – zari arī ir lokāli, un centrālajam serverim par Taviem lokālajiem zariem nav nekādas darīšanas. Rezultātā, zarošana tiešām kļūst par ikdienišķu lietu, un praktiski jebko gribās taisīt zarā, jo tā var netraucēti strādāt pie vairākām lietām vienlaicīgi, kā arī ērti atmest visas izmaiņas, ja eksperiments nesanāca.
– Var izvēlēties, kuras rindiņas no faila iekomitēt. Šī fīča gan nav visiem GUI klientiem. Principā, GIT dara tā, ka Tu vispirms “savāc kopā” komitu, un tikai tad to reāli komito. Un šim “savāktajam komitam” nav īpašas saistības ar Tavu working kopiju. Piemēram, Tu vari izdarīt izmaiņas failā, tad ielikt tās proto-komitā, tad reverot failu, un tad iekomitēt sagatavoto komitu, kurā izmaiņa vēl būs palikusi. Utml.
– Var modificēt vēsturi! Tas, manuprāt, ir visspēcīgākais visā klāstā. Atšķirībā no SVN, kurā Tu vienkārši lineāri visu komito iekšā, un pēc tam no komita tikt vaļā vairs nevar, GITs ļauj “rediģēt” vēsturi (nosacīti, ar zvaigznīti, garš stāsts). Tu vari vairākus komitus apvienot vienā, vai vienu sadalīt vairākos, manīt secību, utml. Rezultātā projekta vēsture vairs nav obligāti trulas izmaiņas hronoloģiskā secībā, bet to ir iespējams piekārtot un padarīt par normālu “stāstu”, kas nākotnē daudz labāk palīdzēs atšķetināt, kas kur kad kā un kāpēc. Protams, lai to izmantotu, ir jābūt pietiekoši daudz disciplīnai. Ja pagaidām pat komentāru pie komita pierakstīt ir slinkums, tad ar šo švaki būs. :)
– Darbs offline. Šis, protams, ir aktuālāks tad, ja esi brīvā darba režīma piekritējs, un patīk ar laptopu strādāt dažādās jaukās vietās, kur internets ne vienmēr vēl ir nonācis.
– Performance. Tā kā visas darbības ir lokālas (izņemot push/pull), tad tās, protams, notiek daudz ātrāk.

Ansis

Atradu ka git ļauj noklonēt tikai vienu zaru no remota SVN repozitorija. Varētu pamēģināt šādu git klonu izmantot tīri lai labāk organizētu savu lokālo izstrādi.

Reizēm pēc lielākas refaktorēšanas praktiski nav iespējams iekomitēt izmaiņas ar vienu komitu, kamēr atrisina visus konfliktus. Lokāls git klons varētu būt labs rīks sakārtot izmaiņas. Neforši procesa laikā salauzt centrālo buildu un traucēt kolēģiem

RameX

viena lieta ko es nemāku/nesparotu no git – nevaru izklonēt ārā konkrētu folderi – jāvelk viss repozitorijs(nu vismaz ne bez gemoroja). Vēl lieta ja ir lokālais git serveris tad tāpat 90% GUI klientu nav nokonfigurējami pie viņa pieslēgties, jo piedāvā autorizāciju tika ar github un bitbucket un ko nu tur vēl. Var jau būt ka man rokas par līku, bet tās ir lietas kas reāli kaitina un padara lieotšanu neērtu. Ar SVN tādā ziņā bija bik vienkāršāk.

laacz

Protams, ka nevar vienu folderi “noklonēt”, jo versiju kontrolē konkrētā versija attiecas uz visu versionēto failu kopumu. Tas man šķiet loģiski.

Kas attiecas uz lokālo GIT serveri, rīki, kurus es lietoju uz Windows (git command line, git noklusētie GUI rīgi, TortoiseGIT) – visi ļauj noklonēt kaut pašu vellu – sākot ar URL (http, https, ssh) un beidzot ar direktoriju. Gitam nav nepieciešams kāds konkrēts serveris, tas darbojas caur jebkuru normālu protokolu.

RameX

tajā brīdī kad repozitorijs ir 10 Gigas :D tas jau ir svarīgi (pietam kods ir modulārs katra mape ir atsevišķs standalone modulis (kāpēc nav katram modulim savs repozitorijs – do not ask me, es pie ieviešanas klāt nebiju)

Ansis

Problēma nav pārāk liela, ja tas ir viens eksmplārs uz developera datora. Problēma sākas ja es gribu uz savas mašīnas glabāt kādas 10 beidzamās versijas (brančus) katru savā mapē. Sanāktu taisīt 10 pilnus clone, kur katrs clone būtu uzswitchots uz noteiktu branču.
SVN checkout mape vienai versijai ir tuvu Gb. Repozitorijā ~150000 komitu.

Tā pati problēma buildmašīnā.

Pilnīgi nekā nespēju iedomāties pāreju uz GITu.

P.S. Internetā emu lasījis par sparse checkout sākot ar git 1.7, bet tā arī nav izdevies saprast kā to izdarīt.

P.P.S. Merge funkcijas, gan gitam sapnis salīdzinājumā ar SVN :)

Vilx-

Nepareizi domā. Branchi SVN un branchi GIT ir divas dažādas lietas.

Pirmkārt, SVN gadījumā “repozitorijs” normālos apstākļos satur daudzus projektus, un katrs pie sevis izčeko tikai pāris folderīšus, ar kuriem tad pats arī strādā. GITā viens projekts == 1 repozitorijs. SVN’ā repozitorijs ir viens liels resns un centrāls. GIT’ā repozitoriji mētājas apkārt pa lab’ un pa kreis’.

Otrkārt, katram repozitorijam ir piesieta 1 working direktorija, kas ir turpat blakus. Var būt arī 0, ja to nevajag (piem. uz kaut kāda servera), bet nekad vairāk par 1. Ja arī repozitorijā ir daudzi zari, working direktorija tik un tā ir tikai 1. Un ir komandas, ar kuru palīdzību Tu pārslēdz – kurš zars šobrīd attēlojas working direktorijā. GIT tad attiecīgi pamodificē working direktorijas saturu, lai tas atbilstu zaram.

Treškārt, ja repozitoriju klonē nevis no servera, bet no lokāla repozitorija tajā pašā diska partīcijā, tad tiek izmantoti afigenna daudzi hardlinki, kā rezultātā ekstra aizņemtā vieta ir praktiski tikai tik, cik vēl vienai working kopijai.

Lidotājs

LOL 10GB? Minēšu – tur tiek glabātas uzceptās exe’s un DLL faili? Ko jūs tur programmējat – operētājsistēmu? Nu kā var 10GB repozitoriju uztaisīt?! :D

Normāli būtu jābūt tā, ka visi “dependencies” tiek iekļauti automātiski (NuGet, ja C# projekts; Composer, ja PHP projekts)… Vai vismaz nodalīt dependencies submodulī (git submodule) kā saistīto repozitoriju – tad, ja ir vajadzība, var likt nokačāt to…
Galvenais – git’ā turēt tikai SAVU kodu, jo, ja iekļausi visus “dependencies”, repozitorijs uzblīdīs strauji.

Par to foldera izvilkšanu vari pamēģināt izlasīt šeit: http://stackoverflow.com/a/13738951

Un vēl vari noklonēt tikai dažus pēdējos commit’us, ja Tev nevajag pilnīgi VISU vēsturi:
git clone –depth=1

Warez

Nu kamon, normālus projektus tiešām neesi redzējis?
Strādāju pie projekta kur source ir ~1GB. Output ir ~300MB bootojams image fails.
Netiek gan lietots git, bet iedomājos, ka git repo mierīgi varētu savākties ap 10GB.
Visi projekti taču nav php weblapiņas.

Iesniegt savu viedokli

Atruna par moderāciju. Daži vārdi, var gadīties, ka ir iz melnās listes (viagra and stuff). Tādi komentāri tiek aizturēti, pirms parādās lapā. Ja Tavs komentārs neparādās uzreizi, būs vien jāpagaida, līdz es jamo izlasīšu. Protams, ka paturu tiesības sev netīkošos komentārus dzēst, iemeslu neminot.