Versiju kontrole un cīņa ar Git-veidīgajiem

Laikam ceturto reizi mēģināju saprast, kā darbojas Git rīki. Īsumā doma ir sekojoša: ja vecais projekta izmaiņu izsekošanas mehānisms bija ik pa laikam taisīt pilnu projekta kopiju un saarhivēt to, tad ar Git tīri teorētiski ir iespēja vienreiz saglabāt visu un tad, pēc vajadzības, saglabāt tikai izmaiņas. Atšķirība slēpjas faktā, ka nav jāglabā ļoti daudz kopiju, tu glabā tikai izmaiņas un sasaisti ar pārējiem failiem, kuri nav izmainīti.

Bez šaubām, man šī lieta šķiet pavisam vērtīga kaut vai tāpēc, ka tad varētu glabāt ne tikai mājaslapu un citu produktu izstrādes stadijas, bet, kas nav mazsvarīgi, Adobe Creative Suite programmu konfigurācijas failus un papildinājumus, kas, pēc būtības, arī ir nelieli teksta faili un mēdz ik pa laikam nobrukt. Tas būtu lielisks veids, gan kā atgriezties pie strādājošām versijām un eksperimentēt ar konfigurāciju pēc sirds patikas.

Nu labi, tagad ķeramies klāt pie problēmas. Problēma ir tajā, ka viss, kas saistīts ar Git metodēm, ir aprakstīts tādā gīku hiphopā, ka normāls cilvēks tur vispār neko nespēj saprast.

Iesākumam, no Bitbucket palīdzības lapas iesācējiem:

If you are new to hosting your code, code management with distributed version control systems (DVCS), or either Git or Mercurial, this Bitbucket 101 tutorial gives you a taste all of them. In this tutorial, you’ll first install both Git and Mercurial for your operating system. You’ll do some work using both Git and then Mercurial.

Ja tiktāl vēl kaut ko var savilkt kopā (lasi — pieņem, ka tie ir kaut kādi nosaukumi produktiem), tad iedziļinoties jēgā, vienkārši sāc jukt prātā. Parādās visādi Commits, Repo, Clone, Fork, Terminal utt. WTF?

Kas pats jocīgākais, nav neviena cilvēka, kas būtu spējis to visu skaidrot bez hiphopa. Tas ir aptuveni tāpat, kā pirmo reizi ieraudzīt jūras navigācijas karti un saņemt visas atbildes tikai jūras terminos. Un pat tad, ir vismaz jūras terminu skaidrojošā vārdnīca, galu galā.

Patiesībā gribētos elementāru aplikāciju, kas darītu pāris elementāras lietas un strādātu bez smadzeņu čakarēšanas.

Git darbības vēlamā principa prototips.
Git darbības vēlamā principa prototips (var tikt papildināts, bet bez hiphopa lietošanas).

Nepretendēju uz neko vairāk kā elementāru aptuveni šādu funkcionalitāti. Papildus varētu vēl būt tas, ka opcijās varētu norādīt, teiksim, reizi stundā paskatīties, vai nav bijušas izmaiņas un saglabāt tās automātiski.

Un pagaidām man tā pa lielam izskatās, ka ar to visu daudz vienkāršāk, bez stulba hiphopa spēs tikt galā Dropbox. Tas vismaz runā saprotamākā valodā un pieejams uz jebkura devaisa.

Bet nu cienījamie sarkanačaino cilts pārstāvji, es ļauju arī jums izteikties pēc sirds patikas.

17 doma par “Versiju kontrole un cīņa ar Git-veidīgajiem”

  1. Pirms dirst par kaut ko, varbūt beidzot painteresējies kas ir kas. Pietiktu ar versiju kontroles pamatbūtību. Pietiks čakarēt tautai smadzenes ar saviem tukšajiem rakstiem un dumjo spriedelēšanu.

  2. Nu re, vēl viens no tās pašas nometnes. Vismaz nevienu svešķermeni teikumos neielika un man viss bija skaidrs. Kāda tad ir versiju kontroles pamatbūtība, kas man nav skaidra?

  3. Ja, piekrītu ka esi izvēlējies lielgabalu lai šautu pa mušām. Git (un vispār versionēšanas sistēmas) nav īsti piemērotas tik triviāliem mērķiem. Protams tās var izmantot kaut kam tādam, bet tad būs vien jāiemācās gan terminoloģija, gan arī visi sistēmas sīkumi un smalkumi, kā arī vēlams draudzēties ar komandrindu, jo, vismaz priekš Git, Windows rīki nav vēl sasnieguši “lietotājs parastais” līmeni.

  4. Redzi, nav neviena savādāka rīka, ar kuru varētu normāli izsekot līdzi izmaiņām un iesaistīt izmaiņu veidošanā arī citus. Tā ir pamata problēma.
    Teiksim, ja man ir viens preferenču fails, kuru vajag izpētīt un paplosīt pašam, paralēli to arī piedāvājot paplosīt un papētīt citiem un normālā režīmā (nevis kopējot turpu šurpu ftp-lokāla direktorija-ftp) un mainot versiju numurus failiem, tad tas ir praktiski nereāli. Sanāk pašam kaut kādas mini-programmas rakstīt.
    Man šis šķiet piemērots, bet saprast, kā tas darbojas, ja neesi tajā iekšā, praktiski nereāli.

  5. Piekrītu. Lai gan esmu programmētājs, ar tehnoloģijām uz Tu un esmu lietojis citas versionēšanas sistēmas, arī mana pirmā pieredze ar Git izraisīja daudz WTF tipa jautājumus.
    Plusi Git/Mercurial sistēmām ir tāda ka Tev nevajag nekādu versionēšanas serveri lai to izmantotu. Principā to ko vajag ir pamatrīkus (kas, parasti, diemžēl ir komandrindas rīki), vai arī atrast kādu normālu GUI rīku.

  6. Principā ko Git/Mercurial dara ir izveido vienu mapi tajā mapē kuru vēlies versionēt, kur tad glabā visas izmaiņas un konfigurāciju, līdz ar to lai versionētu nevajag ne GitHub, ne BitBucket – tie ir nepieciešami, principā, tikai tāpēc, lai dalītos ar citiem.

  7. Tik tālu jau man tā kā ir skaidrs. Problēmas izraisa tieši pati darbošanās ar Git/Mercurial, kur neko, absolūti neko nevar saprast. Un ja vēl man tieši to dalīšanos ar citiem vajag, tad iestājas pilnīgs whatafaks.

  8. Un šo mapi, kuru versionēsi tad arī principā sauc par repo(zitoriju). Ja pamatā darbosies viens ar to visu, tad iesākumā pietiek zināt tikai pāris komandas – init, status, add, commit, push, pull, kaut gan labāk tomēr iesaku atrast normālu GUI rīku tam visam pasākumam – mazāk čakara.

  9. Un manā gadījumā versionēšanas serveris kā reiz ir vajadzīgs. Bet sanāk prasīt kādam no malas, lai man sakonfigurē datoru tā, lai tas viss darbotos.

  10. Ok, principā ir tā ka tur kur inicializē savu repozitoriju (mapē komanda git init) palaid komandu git status, kas parādīs kuri faili mapē ir izmainīti, kur tiek versionēti un kuri nē, tad ar git add var pievienot tos, kurus vēlies versionēt un ar git commit noversionēt. Lai parādītu/izstāstītu sīkāk, diemžēl pat komentāri par īsu :D, vieglāk būtu parādīt, kad konkrēta situācija/jautājums parādās.

  11. Tāpēc par serveri izmanto GitHub/BitBucket, kad ir ar ko padalīties, bet versionē visu lokāli.

  12. Versiju kontrolēšana pēc būtības ir pietiekami sarežģīta lieta, tāpēc ar vienkāršu aplikāciju nepietiks. Photoshopā jau arī nav viena poga “izdarīt, lai būtu skaisti”. Tomēr versionēšanas sistēmas apgūt var viegli un ātri (pāris stundu laikā?). Terminoloģijai vari palasīt kaut vai wikipēdiju (http://en.wikipedia.org/wiki/Revision_control#Common_vocabulary).

    Laba (bezmaksas) grāmata kuru pašķirstīt ir “Version Control by Example” (http://www.ericsink.com/vcbe/), savukārt no Windows rīkiem varu ieteikt “Git Extensions” (http://code.google.com/p/gitextensions/), kurš manuprāt ir uztaisīts cik nu iespējams vienkāršs. Tiesa, tas tā liekas man – profesionālam sarkanacim.

  13. git ir laba versiju kontroles sistēma. tai ir daudz plusi, ieskaitot github esamību, kas padara daudz-programmētāju projektu izstrādi daudz baudāmāku. papildus, var iesaistīties citi cilvēki un iesniegt pull requestus ar uzlabojumiem.

    neesi pateicis vai strādā, ar linux/win/mac un kāda vispār ir Tava pieredze. bet ja gadienā zini kas ir Terminālis, tad git pielietošana ir super vienkāršā un daudz vairāk par

    1) git commit -a

    2) git push/pull

    Tev arī nevajadzēs.

    Ja savukārt nezini, kas ir Terminālis, tad ir dažādi GUI darbībām ar GIT, pats gan tādus neizmantoju.

    Git serveri savukārt uzinstalēt arī ir diezgan triviāli, ja ir bijusi saskare ar linux serveriem.

    Rezumējot, ja esi lietotājs vulgaris, vari izmantot GitHub servisu – tas nodrošinās privātos repozitorijus etc. atliks tikai stumt iekšā izmaiņas. Ja negribi maksāt un rokas pietiekami taisnas, liec kaut kur savu git serveri un stum tur savus projektus. Ja tas viss Tevi biedē – tad iespējams tas nozīmē to, ka Tas Tev nav vajadzīgs un varbūt Mac OS Time Machine ir tieši tas, kas Tev vajadzīgs.

    mani 2 centi.

Komentāri ir slēgti.