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.

Skatīt manu atbildi eses.

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

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.

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

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.

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

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.

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.

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.

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

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.

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

"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?

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.

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)

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

mhm

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

Noteikti, ka nav.

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

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

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.

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

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.