✉️ Saņem šito visu e-pastā. Tā vietā, lai palaistu garām kaut ko no tā, ko es rakstu savā blogā, tagad vari pierakstīties un saņemt e-pastā visu, ko es te rakstu. Tas nav bieži.

← Uz sākumu

Šķēršļpārvare

2014. gada 24. jūlijā, 33 komentāri

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.

Tu atbildi augstāk redzamajam komentāram. Atcelt

Gravatar eses

2014. gada 24. jūlijā, plkst. 15:21

Vai tad tas nav pašsaprotami?

Gravatar laacz Autors

2014. gada 24. jūlijā, plkst. 15:57

Tiem, kas tikai sāk ar VCS ņemties sporta pēc (neviens to neliek darīt, pieraduma nav) ar šādu problēmu saskaras bieži.

Gravatar PiRX

2014. gada 24. jūlijā, plkst. 15:56

Tiešām ir tādi izstrādātāji, kā apraksti? Ok, es varbūt esmu samaitāts, bet mans pieradums ir izmantot VKS kā advancētu "undo" mehānismu.

Gravatar laacz Autors

2014. gada 24. jūlijā, plkst. 15:57

Skatīt manu atbildi eses.

Gravatar Papuass

2014. gada 24. jūlijā, plkst. 16:13

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.

Gravatar laacz Autors

2014. gada 24. jūlijā, plkst. 16:13

Iespējams. Es pats lietoju gan komandrindu, gan Tortoise GIT.

Gravatar Mārtiņš

2014. gada 24. jūlijā, plkst. 18:43

Tiesa. Ja ir jāizprot rīka implementācija, lai viņu lietotu, tad kaut kas nav kārtībā. Git diemžēl slimo ar šo problēmu.

Gravatar laacz Autors

2014. gada 24. jūlijā, plkst. 19:21

Man gan šķiet, ka ar git daudz kas ir vislabākajā kārtībā. Tas, kas nav, to arī parasti nelieto (piemēram, submoduļi).

Gravatar Mārcis

2014. gada 25. jūlijā, plkst. 16:24

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.

Gravatar koko

2014. gada 24. jūlijā, plkst. 19:04

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

Gravatar briiC

2014. gada 26. jūlijā, plkst. 01:28

ja vēl pie commit nav ko rakstīt, tad izmanto šo $(wget -q http://whatthecommit.com/index.txt -O -) paņemts no reddita

Gravatar Ivars

2014. gada 25. jūlijā, plkst. 14:01

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.

Gravatar laacz Autors

2014. gada 25. jūlijā, plkst. 14:15

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.

Gravatar Kirils

2014. gada 25. jūlijā, plkst. 16:44

atsevišķš branch produkcijai un uz tā hooks

Gravatar laacz Autors

2014. gada 25. jūlijā, plkst. 17:15

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.

Gravatar Ansis

2014. gada 28. jūlijā, plkst. 23:45

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 :(

Gravatar laacz Autors

2014. gada 29. jūlijā, plkst. 00:15

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.

Gravatar Ansis

2014. gada 29. jūlijā, plkst. 14:47

Paldies. Tad tomēr key fīča ir decentralizēti merge.

Gravatar Vilx-

2014. gada 31. jūlijā, plkst. 03:24

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.

Gravatar Ansis

2014. gada 31. jūlijā, plkst. 16:52

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

Gravatar ogre

2014. gada 4. augustā, plkst. 17:17

"aizmirst par rebase "

Ir kāda KVS, kur es varu vakarā izdzēst sev atmiņu no darba lietām un nākošajā rītā atkal visu uzreiz saprast pa minūti?

Gravatar RameX

2014. gada 29. jūlijā, plkst. 11:22

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.

Gravatar laacz Autors

2014. gada 29. jūlijā, plkst. 12:45

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.

Gravatar RameX

2014. gada 29. jūlijā, plkst. 13:47

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)

Gravatar laacz Autors

2014. gada 29. jūlijā, plkst. 14:18

10 GB repo nav problēma, ja vien nav pirmā klone jātaisa. Pārējais ir inkrementi (gan branchi, gan tagi, gan komiti). Un, jā, pie nepareizas lietošanas arī git nepalīdzēs :))

Gravatar RameX

2014. gada 29. jūlijā, plkst. 14:30

mhm

un baigias prieks clonēt 10 Gigs ja nepieciešama viena mapīte ar 150kb saturu :D

Gravatar laacz Autors

2014. gada 29. jūlijā, plkst. 14:32

Noteikti, ka nav.

Gravatar Ansis

2014. gada 29. jūlijā, plkst. 15:19

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 :)

Gravatar laacz Autors

2014. gada 29. jūlijā, plkst. 15:30

Bet, ja godīgi, es neredzu nepieciešamību glabāt katru branču savā mapē. Čekauts notiek ļoti ātri, lai varētu mierīgi slēgāties šurpu turpu.

Ja nu gribās katrā direktorijā savu branču, tad <a href="http://stackoverflow.com/a/6270727/211131" rel="nofollow">var darīt arī šādi</a> (<a href="https://github.com/dansmith65/git/blob/master/contrib/workdir/git-new-workdir-win" rel="nofollow">uz win gan ir cits skripts</a>).

Gravatar Vilx-

2014. gada 31. jūlijā, plkst. 03:33

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.

Gravatar Lidotājs

2014. gada 30. jūlijā, plkst. 11:20

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

Gravatar Warez

2014. gada 30. jūlijā, plkst. 18:54

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.

Gravatar sd

2014. gada 19. augustā, plkst. 14:00

git ir hipsteru modes kliedziens, absurdi sarežģīts, nepraktisks un bezjēdzīgs

http://steveko.wordpress.com/2012/02/24/10-things-i-hate-about-git/