9.1 Git və Digər Sistemlər - Git Müştəri kimi

Bütün Subversion körpü əmrləri üçün Git-dəki əsas əmr git svn-dir. Bunun üçün kifayət qədər bir neçə əmr lazımdır, buna görə bir neçə sadə iş axınından keçərkən ən çox yayılmışları göstərəcəyik. Qeyd etmək vacibdir ki, git svn istifadə edərkən Git-dən çox fərqli işləyən bir sistem olan Subversion ilə qarşılıqlı əlaqə qurursunuz. Local branching və birləşmə işlərini edə bilsəniz də, işinizi bərpa edərək və eyni zamanda bir Git remote deposu ilə qarşılıqlı əlaqə qurmaq kimi şeylərdən çəkinərək tarixinizi mümkün qədər xətti tutmaq yaxşıdır. Tarixinizi yenidən yazmayın və təkrar push etməyə çalışmayın və eyni zamanda Git developerləri ilə əməkdaşlıq etmək üçün paralel bir Git deposuna push etməyin.

Subversion yalnız bir xətti tarixçəyə sahib ola bilər və onu qarışdırmaq çox asandır. Bir komanda ilə işləyirsinizsə, bəziləri SVN, bəziləri Git istifadə edirsinizsə, hər kəsin əməkdaşlıq etmək üçün SVN serverindən istifadə etdiyinə əmin olun - bunu etmək həyatınızı asanlaşdıracaq.

Bu funksiyanı nümayiş etdirmək üçün yazmaq üçün daxil olduğunuz tipik bir SVN deposuna ehtiyacınız var. Bu nümunələri kopyalamaq istəyirsinizsə, bir SVN test deposunun yazılı surətini çıxarmalısınız. Bunu asanlıqla etmək üçün Subversion ilə gələn svnsync adlı bir vasitə istifadə edə bilərsiniz.

İzləmək üçün əvvəlcə yeni bir lokal Subversion deposu yaratmalısınız:

Sonra bütün istifadəçilərə revpropları dəyişdirməyə imkan verin - asan yol, həmişə 0-dan çıxan bir pre-revprop-change skriptini əlavə etməkdir:

Artıq bu proyekti depolardan və svnsync init çağıraraq lokal maşınınızla sinxronizasiya edə bilərsiniz.

Bu, sinxronizasiyanı işə salmaq üçün xüsusiyyətləri qurur. Daha sonra kodu işə salmaqla klonlaya bilərsiniz:

Bu əməliyyat yalnız bir neçə dəqiqə çəkə bilsə də, orijinal deponu lokal əvəzinə başqa bir uzaq depoya köçürməyə çalışarsanız, 100-dən az commit olmasına baxmayaraq proses təxminən bir saat çəkəcəkdir. Subversion bir dəfəyə bir revizyonu klonlamalı və sonra başqa bir depoya qaytarmalıdır - gülünc dərəcədə səmərəsizdir, amma bunu etmək üçün yeganə asan yoldur.

İndi yazma girişiniz olan bir Subversion deposuna sahib olduğunuz üçün tipik bir iş axınından keçə bilərsiniz. Bütün Subversion deposunu yerli Git deposuna idxal edən git svn clone əmri ilə başlayacaqsınız. Unutmayın ki, həqiqi bir yerləşdirilmiş Subversion deposundan idxal edirsinizsə, buradakı file:///tmp/test-svn-ni Subversion deposunuzun URL’si ilə əvəz etməlisiniz:

Artıq yazma girişiniz olan bir Subversion deposuna sahib olduğunuz üçün tipik bir iş axınından keçə bilərsiniz. Bütün Subversion deposunu yerli Git deposuna idxal edən git svn clone əmri ilə başlayacaqsınız. Unutmayın ki, həqiqi bir yerləşdirilmiş Subversion deposundan idxal edirsinizsə, buradakı file:///tmp/test-svn-ni Subversion deponuzun URL’si ilə əvəz etməlisiniz:

Bu, təqdim etdiyiniz URL-də iki əmr - git svn init və ardından git svn fetch kimi ekvivalentdir. Bu bir müddət çəkə bilər.

Məsələn, test layihəsində yalnız 75 iş görülürsə və kod bazası o qədər böyük deyilsə, Git buna baxmayaraq hər versiyanı bir-bir yoxlamalı və fərdi olaraq həyata keçirməlidir. Yüzlərlə və ya minlərlə commit-i olan bir layihə üçün bunun sözün əsl mənasında bitməsi saatlarla, hətta günlərlə davam edə bilər.

-T trunk -b branches -t tags hissəsi Git-ə bu Subversion deposunun əsas branching və etiketləmə şərtlərini izlədiyini bildirir. Trunk-nıza, branch-larınıza və ya etiketlərinizə fərqli ad verirsinizsə, bu seçimləri dəyişə bilərsiniz. Bu çox yayılmış olduğundan, bütün hissəni standart düzən mənasını verən və bütün bu variantları nəzərdə tutan -s ilə əvəz edə bilərsiniz. Aşağıdakı əmr bərabərdir:

Bu nöqtədə branch-larınızı və etiketlərinizi idxal edən etibarlı bir Git deposuna sahib olmalısınız:

Bu vasitənin Subversion etiketlərini uzaqdan idarəedici olaraq necə idarə etdiyinə diqqət yetirin. Git plumbing əmri ilə show-ref ilə daha yaxından tanış olaq:

Git bir Git serverindən klonladıqda bunu etmir; etiketli bir deponun təzə bir klondan sonra necə göründüyü:

Git etiketi uzaq branch-lara müalicə etmək əvəzinə birbaşa refs/tags-ə gətirir.

Artıq işləyən bir qovluğa sahib olduğunuz üçün Git-dən bir SVN müştərisi kimi effektiv istifadə edərək, proyektdə bir az iş görə bilər və commit-lərinizi yuxarı axın istiqamətində push edə bilərsiniz. Fayllardan birini redaktə edib onu yerinə yetirirsinizsə, Subversion serverində olmayan Git-də yerli olaraq mövcud olan bir commit-iniz var:

Bundan sonra dəyişikliklərinizi yuxarıya doğru push etməlisiniz . Bunun Subversion ilə işləmə tərzinizi necə dəyişdirdiyinə diqqət yetirin - bir neçə commit-i oflayn edə və sonra hamısını birdən Subversion serverinə köçürə bilərsiniz. Subversion serverinə keçmək üçün git svn dcommit əmrini yerinə yetirirsiniz:

Bu, Subversion server kodunun üstündə etdiyiniz bütün commit-ləri götürür, hər biri üçün bir Subversion commit-i götürür və sonra yerli Git unikal identifikatoru əlavə etmək üçün yenidən yazır.

Bu vacibdir, çünki commit-ləriniz üçün bütün SHA-1 hesablama cəmlərinin dəyişməsi deməkdir. Qismən bu səbəbdən bir Subversion server ilə eyni vaxtda layihələrinizin Git əsaslı uzaq versiyaları ilə işləmək yaxşı bir fikir deyil. Son commit-ə baxsanız, əlavə edilmiş yeni git-svn-id-i görə bilərsiniz:

Diqqət yetirin ki, commit etdiyiniz zaman əvvəlcə 4af61fd ilə başlayan SHA-1 hesablama cəmi 95e0222 ilə başlayır. Həm Git serverinə, həm də bir Subversion serverinə push etmək istəyirsinizsə, əvvəlcə Subversion serverinə (dcommit) push etməyə, çünki bu hərəkət commit məlumatınızı dəyişdirir.

Digər developerlərlə işləyirsinizsə, o zaman biriniz birini push edəcəksiniz, sonra digəri konflikt bir dəyişikliyə push etməyə çalışacaq. İşlərinizdə birləşənə qədər bu dəyişiklik rədd ediləcək. git svn-də belə görünür:

Bu vəziyyəti həll etmək üçün serverdə hələ olmadığınız hər hansı bir dəyişiklikləri aşağı salan və serverdə olanların üstündə etdiyiniz hər hansı bir işi yenidən bərpa edən git svn rebase-i işlədə bilirsiniz:

İndi bütün işləriniz Subversion serverindəki işlərin üstündədir, beləliklə uğurla dcommit edə bilərsiniz:

Diqqət yetirmədən əvvəl local işinizi birləşdirməyinizi tələb edən Gitdən fərqli olaraq, git svn bunu yalnız dəyişikliklər konflikt təşkil edərsə (Subversionun necə işlədiyi kimi) edir. Başqası bir dəyişikliyi bir fayla push edirsə, sonra başqa bir fayla dəyişiklik göndərirsinizsə, dcommi-iniz yaxşı işləyəcək:

Bunu unutmamaq vacibdir, çünki nəticə siz push etdiyiniz zaman hər iki kompüterinizdə olmayan bir layihə vəziyyətidir. Dəyişikliklər bir-birinə uyğun deyilsə, konflikt təşkil etmirsə, diaqnozu çətin olan problemlərlə qarşılaşa bilərsiniz. Bu, bir Git serverindən istifadə etməkdən fərqlidir - Git-də, vəziyyəti dərc etmədən əvvəl müştəri sisteminizdə tam olaraq yoxlaya bilərsiniz, halbuki SVN-də, işdən əvvəl və commit götürdükdən sonra vəziyyətlərin eyni olduğuna əmin ola bilməzsiniz.

Özünüzü commit etməyə hazır olmasanız da, Subversion serverindən dəyişikliklər etmək üçün bu əmri də işləməlisiniz. Yeni məlumatları əldə etmək üçün git svn fetch-i işə sala bilərsiniz, lakin git svn rebase gətirir və sonra local commit-lərinizi yeniləyir.

Hər dəfə git svn rebase işlətmək kodunuzun daima yeniləndiyinə əmin olur. Buna baxmayaraq işləyərkən iş qovluğunuzun təmiz olduğundan əmin olmalısınız.

Local dəyişiklikləriniz varsa, işinizi gizlətməlisiniz və ya git svn rebase-i işə salmadan əvvəl müvəqqəti olaraq etməlisiniz - əks təqdirdə, rebase-in birləşmə konflikti ilə nəticələnəcəyini görsə əmr dayanacaq.

Bir Git iş axını ilə rahat olduqda, ehtimal ki, mövzu branch-ları yaradacaq, üzərində işləyəcək və sonra onları birləşdirəcəksiniz. git svn vasitəsi ilə Subversion serverinə müraciət edirsinizsə, branch-larınızı birləşdirmək əvəzinə hər dəfə işinizi tək branch-da bərpa etmək istəyə bilərsiniz.

Rebasing seçiminə üstünlük vermə səbəbi, Subversionun xətti bir tarixçəyə sahib olması və Git kimi birləşmələrlə məşğul olmamasıdır, buna görə də git svn snapshotları Subversion commit-lərinə çevirərkən yalnız ilk valideynə commit edir.

Tutaq ki, tarixiniz aşağıdakı kimidir: bir experiment branch-ı yaratdınız, iki commit etdiniz və sonra onları yenidən master-ə çevirdiniz. dcommit etdiyiniz zaman, nəticəni belə görürsünüz:

Birləşdirilmiş tarixə malik bir branch-da dcommit çalışması yaxşı işləyir, ancaq Git layihə tarixçənizə baxdığınız zaman experiment branch-da etdiyiniz commit-lərin heç birini yenidən yazmadı - bunun əvəzinə bütün bu dəyişikliklər tək birləşmə commit-inin SVN versiyası.

Başqa birisi işləyən klonlaşdırdıqda, gördükləri bütün işin içərisinə yığılan birləşmə əmridir, sanki git merge --squash işlətmisiniz; haradan gəldiyi və nə vaxt edildiyi barədə commit məlumatlarını görmürlər.

Subversionda branching, Git-də branching ilə eyni deyil; istifadə etməkdən çox çəkinə bilsəniz, ən yaxşısı budur. Bununla birlikdə, git svn istifadə edərək Subversion-dakı branch-ları yarada və commit edə bilərsiniz.

Subversion-da yeni bir branch yaratmaq üçün git svn branch [new-branch] işlədin:

Bu, Subversiondakı svn copy trunk branches/opera əmrinin ekvivalentini edir və Subversion serverində işləyir. Qeyd etmək vacibdir ki, sizi bu branch-a daxil etmir; Əgər bu anda commit götürsəniz, bu əməliyyat serverdəki opera-a yox, trunk-a gedəcək.

Git, tarixinizdəki Subversion branch-larınızın hər hansı birinin ucunu axtararaq dcommits-nizin hansı branch-a getdiyini müəyyənləşdirir - yalnız birinə sahib olmalısınız və mövcud branch-ınızda bir "git-svn-id" olan sonuncusu olmalıdır tarix.

Git, tarixinizdəki Subversion branch-larınızın hər hansı birinin ucunu axtararaq dcommitslərinizin hansı qola getdiyini müəyyənləşdirir - yalnız birinə sahib olmalısınız və mövcud filialınızda bir git-svn-id olan sonuncusu olmalıdır.

Eyni anda birdən çox branch üzərində işləmək istəyirsinizsə, bu branch üçün idxal olunan Subversion commit-indən başlayaraq müəyyən Subversion branch-larına dcommit etmək üçün local branch-lar qura bilərsiniz. Ayrı-ayrılıqda işləyə biləcəyiniz bir opera branch-ı istəsəniz, çalışdıra bilərsiniz:

İndi opera branch-ınızı trunk-a (master branch-nızın) birləşdirmək istəyirsinizsə, bunu normal bir git birləşmə ilə edə bilərsiniz. Ancaq təsviri bir commit mesajı verməlisiniz (-m vasitəsilə), əks halda birləşmə faydalı bir şey əvəzinə “Merge branch opera” deyəcəkdir.

Unutmayın ki, bu əməliyyatı yerinə yetirmək üçün git merge istifadə etsəniz də birləşmə ehtimalı Subversionda olduğundan daha asan olacaq (çünki Git sizin üçün uyğun birləşmə bazasını avtomatik olaraq aşkar edəcək), Git birləşmə commiti normal deyil. Bu məlumatları birdən çox valideynə baxan bir commit-i yerinə yetirə bilməyən bir Subversion serverinə qaytarmalısınız; belə ki, onu push etdikdən sonra, başqa bir branch-ın bütün işlərində tək bir commit altında əzilən tək bir commit-ə bənzəyir. Bir branch-ı digərinə birləşdirdikdən sonra asanlıqla geri qaytara bilməzsiniz və normal olaraq Gitdə olduğu kimi bu branch üzərində işləməyə davam edə bilməzsiniz. İşlətdiyiniz dcommit əmri hansı branch-ın birləşdirildiyini bildirən hər hansı bir məlumatı silir, bu səbəbdən sonrakı birləşmə bazası hesablamaları səhv olacaq -dcommit git merge nəticənizi git merge --squash kimi işlədir. Təəssüf ki, bu vəziyyətdən qaçınmaq üçün yaxşı bir yol yoxdur - Subversion bu məlumatı saxlaya bilməz, buna görə də onu server olaraq istifadə edərkən məhdudiyyətləri ilə əlil olacaqsınız. Problemlərin qarşısını almaq üçün trunk-a birləşdirdikdən sonra local branch-ı (bu halda, opera) silməlisiniz.

git svn alətlər dəsti Subversion-dakılara bənzər bəzi funksionallıq təmin edərək Git-ə keçidi asanlaşdırmağa kömək edəcək bir sıra əmrlər təqdim edir. Budur sizə Subversionun istifadə etdiyini verən bir neçə əmr.

git svn alətləri bir Subversion serverinə qapıldığınızda və ya başqa bir şəkildə Subversion serverinin işlədilməsini zəruri edən inkişaf mühitində olduğunuzda faydalıdır. Bununla birlikdə şikəst Git olduğunu düşünməlisiniz, yoxsa tərcümədə sizi və həmkarlarınızı qarışdıra biləcək məsələlərə toxunacaqsınız. Problemlərdən uzaq olmaq üçün aşağıdakı qaydalara əməl etməyə çalışın:

Bu təlimatlara əməl etsəniz, Subversion server ilə işləmək daha dözümlü ola bilər. Ancaq həqiqi bir Git serverinə keçmək mümkündürsə, bunu etmək komandanızı daha çox qazana bilər.

Əvvəlcə git-remote-hg yükləməlisiniz. Bu, əsasən faylı path-nıza bir yerə atmağa səbəb olur:

…~/bin-in $PATH-da olduğunuzu düşünürük. Git-remote-hg-nin başqa bir asılılığı var: Python üçün mercurial kitabxanası. Python quraşdırılıbsa, bu qədər sadədir:

Python’unuz yoxdursa, https://www.python.org/ səhifəsini ziyarət edin və əvvəl əldə edin.

Sizə lazım olan son şey Mercurial müştərisidir. https://www.mercurial-scm.org/ saytına gedin və hələ də yoxdursa quraşdırın.

İndi isə rock etməyə hazırsınız. Sadəcə, push etməyə bir Mercurial deposuna ehtiyacınız var. Xoşbəxtlikdən, hər bir Mercurial deposu bu şəkildə hərəkət edə bilər, buna görə Mercurial-ı öyrənmək üçün hər kəsin istifadə etdiyi "hello world" deposundan istifadə edəcəyik:

Artıq uyğun bir “server-tərəf” depomuz olduğuna görə tipik bir iş axınından keçə bilərik. Gördüyünüz kimi, bu iki sistem kifayət qədər sürtünmə olmadan oxşayır.

Həmişə olduğu kimi Git ilə əvvəlcə klonlaşdırırıq:

Bir Mercurial deposu ilə işləmək üçün standart git clone əmrini istifadə etdiyini görəcəksiniz. Git-in HTTP/S protokolunun necə tətbiq olunduğuna bənzər bir mexanizm istifadə edərək (remote köməkçilər) git-remote-hg-nin kifayət qədər aşağı səviyyədə işləməsidir. Git və Mercurial, hər bir müştərinin anbar tarixinin tam bir nüsxəsinə sahib olması üçün hazırlandığından, bu əmr bütün layihə tarixi daxil olmaqla tam bir klon yaradır və bunu kifayət qədər tez edir.

Log əmri iki commit göstərir, ən sonuncusu isə bir çox refer tərəfindən göstərilmişdir. Bunlardan bəzilərinin əslində orada olmadığı ortaya çıxdı. Gəlin .git qovluğundakılara nəzər salaq:

Git-remote-hg şeyləri daha idiomatik olaraq Git-esque etməyə çalışır, ancaq başlıq altında iki fərqli sistem arasındakı konseptual xəritələşməni idarə edir. refs/hg qovluğu faktiki uzaq reflərin saxlanıldığı yerdir. Məsələn, refs/hg/origin/branches/default, master-in işarə etdiyi “ac7955c” ilə başlayan SHA-1-i ehtiva edən bir Git ref sənədidir.

Beləliklə, refs/hg qovluğu bir növ saxta refs/remotes/origin kimidir, lakin bookmark-lar və branch-lar arasında əlavə bir fərq var.

notes/hg faylı, git-remote-hg xəritələrinin Gitin Mercurial dəyişən ID-lərinə necə hash olduğunun üçün başlanğıc nöqtəsidir. Gəlin bir az araşdıraq:

Beləliklə, refs/notes/hg, Git obyekt bazasında adları olan digər obyektlərin siyahısı olan bir ağaca işarə edir. git ls-tree bir ağacın içindəki əşyalar üçün rejimi, növü, obyekt hash-ı və fayl adını çıxarır.

Ağac item-larından birinə endikdən sonra içərisində “0a04b98” konteksi ilə (bu, default branch-nın ucundakı Mercurial dəyişikliyinin identifikatorudur) “ac9117f” ( master tərəfindən göstərilən commit-in SHA-1 hashı) adlı bir blob olduğunu görürük.

Yaxşı xəbər odur ki, bunların hamısı üçün narahat olmaq lazım deyil. Tipik iş axını, Git remote ilə işləməkdən çox fərqli olmayacaq.

Davam etməzdən əvvəl iştirak etməli olduğumuz bir şey daha var: ignores. Mercurial və Git bunun üçün çox bənzər bir mexanizm istifadə edirlər, lakin çox güman ki, bir .gitignore sənədini Mercurial deposuna daxil etmək istəməyəcəksiniz. Xoşbəxtlikdən, Git’in diskdəki bir depo üçün lokal olan faylları ignore etməyin bir yolu var və Mercurial formatı Git ilə uyğundur, buna görə onu köçürməlisiniz:

The .git/info/exclude file acts just like a .gitignore, but isn’t included in commits.

Fərz edək ki, master branch-ında bir az iş gördük və bir neçə commit götürdük və onu uzaq depoya push etməyə hazırsınız. Depomuz hazırda belə görünür:

master branch-ımız origin/master-dan iki commit-dir, lakin bu iki vəzifə yalnız local maşınımızda mövcuddur. Başqa birinin eyni zamanda mühüm bir iş görüb görmədiyini baxaq:

--all flag-ından istifadə etdiyimiz üçün git-remote-hg tərəfindən daxili istifadə edilən “qeydlər” istinadlarını görürük, lakin onları ignore edə bilərik. Qalan nə gözlədiyimizdir; origin/master bir commit-lə irəli getdi və tariximiz indi fərqlidir. Bu fəsildə işlədiyimiz digər sistemlərdən fərqli olaraq, Mercurial birləşmələri idarə edə bilir, buna görə də zərif bir şey etməyəcəyik.

Əla. Testləri aparırıq və hər şey uğurlu keçir, buna görə işimizi komandanın qalan üzvləri ilə bölüşməyə hazırıq:

Bu qədər! Merkuri deposuna nəzər yetirsəniz, bunun gözlədiyimizi etdiyini görərsiniz:

2 nömrəli dəyişikliklər Mercurial tərəfindən, 3 və 4 nömrəli dəyişikliklər git-remote-hg tərəfindən Git ilə edilən commit-ləri push etməklə edilmişdir.

Gitin yalnız bir növ branch-ı var: commit-lər qoyulduqda hərəkət edən bir istinad. Mercurial-da bu növ bir istinad “bookmark” adlanır və Git branch-ı ilə eyni şəkildə davranır.

Mercurial-ın “branch” konsepsiyası daha ağırdır. Dəyişikliklərin edildiyi branch dəyişikliklərlə yazılır, yəni həmişə depo tarixində olacaqdır.

Budur develop branch-ında edilən bir commit-in nümunəsi:

“branch” ilə başlayan sətrə diqqət yetirin. Git bunu həqiqətən təkrarlaya bilməz (və buna ehtiyac yoxdur; hər iki branch növü də Git ref kimi təmsil edilə bilər), lakin git-remote-hg fərqi anlamalıdır, çünki Mercurial qayğı göstərir.

Mercurial bookmark-lar yaratmaq, Git branch-ları yaratmaq qədər asandır. Git tərəfində:

Bunun üçün hər şey var. Mercurial tərəfdən bu belə görünür:

Reviziya 5-də yeni [featureA] etiketinə diqqət yetirin. Bunlar bir istisna olmaqla, Git tərəfindəki Git branch-ları kimi hərəkət edirlər: bir bookmark-ı Git tərəfdən silə bilməzsiniz (bu, uzaq köməkçilərin məhdudiyyətidir).

“heavyweight” bir Mercurial branch-da da işləyə bilərsiniz: sadəcə branches namespace-nə bir branch qoyun:

Mercurial tərəfdə görünən budur:

“permanent” branch adı 7 işarəsi ilə dəyişiklik dəsti ilə qeyd edildi.

Git tərəfdən, bu branch üslublarından hər hansı biri ilə işləmək eynidir: normalda istədiyiniz kimi checkout, commit, fetch, merge, pull, və push etmək. Bilməli olduğunuz bir şey, Mercurial-ın tarixin yenidən yazılmasını dəstəkləməməsi, yalnız tarixə əlavə etməsidir. Mercurial depomuzun interaktiv rebase və force-push tətbiqindən sonra belə görünəcək:

8, 9 və 10 dəyişikliklər yaradıldı və permanent branch-na aiddir, lakin köhnə dəyişikliklər hələ də mövcuddur. Bu, Mercurial istifadə edən komanda yoldaşlarınız üçün çox qarışıq ola bilər, buna görə də bundan çəkinməyə çalışın.

Git və Mercurial kifayət qədər oxşardır və sərhəd boyunca işləmək kifayət qədər ağrısızdır. Maşınınızda qalan tarixi dəyişdirməkdən çəkinsəniz (ümumiyyətlə tövsiyə olunduğu kimi), digər ucunun Mercurial olduğunu da bilməyəcəksiniz.

İstifadəsi sadədir. Bir Bazaar deposunu əvvəldən əlavə edən bzr:: ilə klonlaşdırmaq kifayətdir. Git və Bazaar hər ikisi də cihazınıza tam klonlar verdiyindən local Bazaar klonuna bir Git klonu əlavə etmək mümkündür, lakin tövsiyə edilmir. Git klonunuzu birbaşa Bazaar klonunuzun bağlandığı yerə - mərkəzi depoya əlavə etmək daha asandır.

Fərz edək ki, bzr+ssh://developer@mybazaarserver:myproject ünvanında olan uzaq bir depo ilə işləmisiniz. Sonra aşağıdakı şəkildə klonlamalısınız:

Bu nöqtədə Git deposunuz yaradılır, lakin optimal disk istifadəsi üçün sıxılmır. Bu səbəbdən Git deposunuzu təmizləmək və yığmaq lazımdır, xüsusən də böyükdürsə:

Bazaar yalnız branch-ları klonlamağa imkan verir, ancaq bir depo bir neçə branch-dan ibarət ola bilər və git-remote-bzr hər ikisini də klonlaya bilər. Məsələn, branch-ı klonlamaq üçün:

Və bütün deponu klonlamaq üçün:

İkinci komanda, emacs deposundakı bütün branch-ları klonlaşdırır; buna baxmayaraq, bəzi branch-lara işarə etmək mümkündür:

Bəzi uzaq depolar branch-larını siyahıya almağa imkan vermir, bu halda onları manual olaraq təyin etməlisiniz və klonlama əmrində konfiqurasiyanı təyin edə bilsəniz də, bunu daha asan tapa bilərsiniz:

Bazaar ilə idarə olunan bir layihə üzərində çalışdığınız üçün .gitignore faylı yaratmamalısınız, çünki təsadüfən onu versiya nəzarəti altına olacaqsınız və Bazaar ilə işləyən digər insanlar narahat olacaqlar. Çözüm, .git/info/exclude faylını simvolik bir link və ya adi bir fayl olaraq yaratmaqdır. Bu sualın necə həll ediləcəyini daha sonra görəcəyik.

Bazaar, faylları ignore etmək üçün Git ilə eyni modeli istifadə edir, eyni zamanda Git-ə ekvivalenti olmayan iki xüsusiyyəti var. Tam təsviri the documentation-də tapa bilərsiniz. İki xüsusiyyət bunlardır:

Nəticə olaraq, nəzərə alınacaq iki fərqli vəziyyət var:

Nə olursa olsun, .git/info/exclude faylının hər zaman .bzrignore yansıtdığından əmin olmaq üçün .bzrignore dəyişikliyinə qarşı xəbərdar olmalısınız. Həqiqətən, .bzrignore faylı dəyişdirilərsə və "!!" ilə başlayan bir və ya daha çox sətir var idi və ya "RE:", Git bu sətirləri şərh edə bilmirsə, .git/info/exclude faylınızı .bzrignore ilə ignore olunanlarla eyni faylları ignore etmək üçün uyğunlaşdırmalısınız. Üstəlik, .git/info/exclude faylı simvolik bir əlaqə olsaydı, əvvəlcə simvolik linki silməli, .bzrignore .git/info/exclude şəklində kopyalayıb sonra ikincisini uyğunlaşdırmalısınız. Bununla birlikdə, onun yaradılmasında diqqətli olun, çünki Git ilə bu faylın bir ana qovluğu xaric edildikdə bir faylı yenidən daxil etmək mümkün deyil.

Remote-un dəyişikliklərini əldə etmək üçün Git əmrlərindən istifadə edərək dəyişiklikləri adətən fetch edirsiniz. Dəyişikliklərinizin master branch-ında olduğunu düşünərək, origin/master branch-ında işlərinizi birləşdirir və ya yenidən artırırsınız:

Bazaar da birləşmə commit-i konsepsiyasına sahib olduğundan birləşdirmə commit-ini irəli sürsəniz, heç bir problem olmayacaqdır. Beləliklə, bir branch-da işləyə, dəyişiklikləri master halına gətirə və işinizi push edə bilərsiniz. Sonra, branch-larınızı yaradırsınız, işinizi həmişəki kimi sınaqdan keçirirsiniz. Nəhayət işinizi Bazaar deposuna push edirsiniz:

Git’in uzaqdan köməkçilər çərçivəsinin tətbiq olunan bəzi məhdudiyyətləri var. Xüsusilə, bu əmrlər işləmir:

Git və Bazaar modelləri bir-birinə bənzədiyi üçün sərhəd xaricində işləyərkən çox müqavimət göstərmir. Məhdudiyyətlərə diqqət yetirdiyiniz və uzaqdakı deponun local olaraq Git olmadığını bildiyiniz müddətdə yaxşı olacaqsınız.

Perforce, bir Perforce serverini server tərəfindəki Git depoları ilə sinxronizasiya edən Git Fusion adlı bir məhsul təqdim edir (http://www.perforce.com/git-fusion).

Git-p4, Git və Perforce arasında iki tərəfli bir körpüdür. Tamamilə Git deponuzun içərisində işləyir, beləliklə Perforce serverinə hər hansı bir girişə ehtiyacınız olmayacaq (əlbəttə ki, istifadəçi məlumatları xaricində). Git-p4, Git Fusion qədər çevik deyil və ya bir həll yolu tamamlamamaqla yanaşı, istədiyiniz işlərin əksəriyyətini server mühitinə müdaxilə olmadan etməyinizə imkan verir.

Git-p4 Perforce server ilə bir Git iş axını istifadə etməyi mümkün edir və bu işdə olduqca yaxşıdır. Bununla birlikdə, Perforce-un mənbədən məsul olduğunu və yalnız Git’i yerli işləmək üçün istifadə etdiyinizi unutmamalısınız. Yalnız Git commit-lərini bölüşmək üçün həqiqətən diqqətli olun; digər insanların istifadə etdiyi bir remote-nuz varsa, əvvəllər Perforce serverinə təqdim olunmamış commit-lər verməyin.

Perforce və Git-in mənbə nəzarəti üçün müştəri kimi istifadəsini sərbəst şəkildə qarışdırmaq istəyirsinizsə və server administratorunu onu quraşdırmağa inandıra bilsəniz, Git Fusion, Git-i Perforce server üçün birinci dərəcəli versiya-nəzarət müştərisinə çevirir.

Əslində iki var: git-tf və git-tfs.

Git-tfs (https://github.com/git-tfs/git-tfs saytında tapın) bir .NET layihəsidir və (bu yazı kimi) yalnız Windows-da işləyir. Git depoları ilə işləmək üçün yüksək performanslı və Git deposunun bağırsaqları ilə çox rahatlıq təmin edən Git-in kitabxana yönümlü tətbiqi olan libgit2 üçün .NET bağlamalarından istifadə edir. Libgit2, Git-in tam bir tətbiqi deyil, beləliklə fərqi ödəmək üçün git-tfs həqiqətən bəzi əməliyyatlar üçün əmr sətiri Git müştəri çağıracaq, buna görə də Git depoları ilə əlaqəli süni məhdudiyyətlər yoxdur. TFVC xüsusiyyətlərini dəstəkləməsi çox yetkindir, çünki serverlərlə əməliyyatlar üçün Visual Studio assemblilərindən stifadə edir. Bu o assemblilərə girişə ehtiyacınız olacaq deməkdir, yəni Visual Studio-nun son versiyasını (versiya 2012-dən bəri Express daxil olmaqla 2010-cu ildən bəri hər hansı bir nəşr) və ya Visual Studio SDK-nı quraşdırmanız lazımdır.

Git-tf (hansı ki evi https://archive.codeplex.com/?p=gittf ünvanındadı) bir Java layihəsidir və bu şəkildə Java işləmə müddəti olan istənilən kompüterdə işləyir. JGit (Git’in bir JVM tətbiqi) vasitəsi ilə Git depoları ilə əlaqə qurur, yəni Git funksiyaları baxımından heç bir məhdudiyyətə sahib deyildir. Bununla birlikdə, TFVC üçün dəstəyi git-tfs ilə müqayisədə məhduddur - məsələn branch-ları dəstəkləmir.

Beləliklə, hər bir vasitənin müsbət və mənfi cəhətləri var və bir-birinə üstünlük verən çoxlu vəziyyət var. Hər ikisinin əsas istifadəsini bu kitabda nəzərdən keçirəcəyik.

Etdiyiniz ilk şey hər hansı bir Git layihəsində olduğu kimi klondur. git-tf ilə görünən budur:

Birinci arqument bir TFVC kolleksiyasının URL’si, ikincisi $/project/branch şəklində, üçüncüsü isə yaradılacaq yerli Git deposuna gedən yoldur (sonuncusu istəyə bağlıdır). Git-tf hər dəfə yalnız bir branch ilə işləyə bilər; fərqli bir TFVC branch-ında chekinlər etmək istəyirsinizsə, bu branch-dan yeni bir klon etməlisiniz.

Bu, tamamilə işləyən bir Git deposu yaradır:

Buna yalnız son dəyişikliklər endirildiyi anlamına bir shallow klonu deyilir. TFVC, hər bir müştərinin tarixin tam bir nüsxəsini əldə etməsi üçün nəzərdə tutulmamışdır, beləliklə git-tf varsayılan olaraq yalnız son versiyasını alır, bu da daha sürətlidir.

Bir az vaxtınız varsa, ehtimal ki, bütün layihə tarixçəsini --deep seçimindən istifadə edərək klonlamağa dəyər:

TFS_C35189 kimi adlarla etiketlərə diqqət yetirin; bu, hansı Gitin TFVC dəyişiklikləri ilə əlaqəli olduğunu bilməyinizə kömək edən bir xüsusiyyətdir. Bu onu təmsil etmək üçün gözəl bir yoldur, çünki sadə bir günlük əmri ilə hansınızın TFVC-də mövcud olan bir snapshot ilə əlaqəli olduğunu görə bilərsiniz. Bunlar lazım deyil (və əslində onları git config git-tf.tag false ilə söndürə bilərsiniz) - git-tf, .git/git-tf faylında həqiqi commit-changeset uyğunlaşmalarını saxlayır.

Git-tfs klonlama bir az fərqli davranır. Baxaq:

--with-branches flag-na diqqət yetirin. Git-tfs, TFVC branch-larını Git branch-larına uyğunlaşdırma qabiliyyətinə malikdir və bu bayraq hər TFVC branch-ı üçün yerli bir Git branch-ının qurulmasını bildirir. TFS-də branched zamanı və ya birləşdiyiniz təqdirdə bu çox tövsiyə olunur, lakin TFS 2010-dan əvvəlki bir serverlə işləməyəcək - git-tfs onları adi qovluqlardan ayıra bilməz, çünki bu buraxılışdan əvvəl “branch-lar” sadəcə qovluq idi.

Nəticədə çıxan Git deposuna nəzər salaq:

Klonun başlanğıc nöqtəsini (TFVC-də Trunk) və bir child branch-ını (TFVC-də featureA) təmsil edən iki local branch, master və featureA var. Ayrıca, tfs “remote”-da bir neçə referensa sahib olduğunu görə bilərsiniz: TFVC branch-larını təmsil edən default və featureA. Git-tfs klonladığınız branch-ı tfs/default-a xəritələşdirir və digərləri öz adlarını alır.

Diqqəti cəlb edən başqa bir şey, mesajlardakı git-tfs-id: sətirləridir. Etiket əvəzinə git-tfs, TFVC dəyişikliklərini Git commit-ləri ilə əlaqələndirmək üçün bu markerlərdən istifadə edir. Bu, Git commit-lərinizin TFVC-yə göndərilmədən əvvəl və sonra fərqli bir SHA-1 qarışığına sahib olacağı mənasını verir.

İstəyəcəyiniz açıq bir şey layihə üzərində işləməkdir. TFVC və TFS, iş axınınıza mürəkkəblik əlavə edə biləcək bir neçə xüsusiyyətə malikdir:

Qısaca, burada əhatə edəcəyimiz bu məsələlərin əksəriyyətini kənara qoyan və ya çəkindirən xoşbəxt yoldur.

Deyək ki, bir az iş görmüsünüz, bir neçə Git master üzərində commit götürdünüz və TFVC serverində irəliləyişinizi bölüşməyə hazırsınız. Budur Git depomuz:

4178a82 commit-indəki ani görüntüyü götürmək və TFVC serverinə ötürmək istəyirik. Əvvəlcə hər şey: gəlin görək komanda yoldaşlarımızdan biri son əlaqə qurandan bəri bir şey edib etməyib:

Deyəsən başqası da işləyir və indi fərqli tarixə sahibik. Gitin parladığı yer budur, amma necə davam edəcəyimizə dair iki seçimimiz var:

Seçim sizindir. Bu nümunə üçün biz geri qayıdacağıq:

İndi TFVC serverinə giriş yazmağa hazırıq. Git-tf, sonuncudan başlayaraq bütün dəyişiklikləri əks etdirən tək bir dəyişiklik etmə seçimini (default olaraq --shallow) və hər bir Git commit-i üçün yeni bir dəyişiklik yaratma seçimini verir (--deep). Bu nümunə üçün yalnız bir dəyişiklik düzəldəcəyik:

TFVC-nin 5a0e25e commit-i ilə eyni snapshot-nu saxladığını göstərən yeni bir TFS_C35348 etiketi var. Qeyd etmək vacibdir ki, hər bir Gitin TFVC-də dəqiq bir həmkarına sahib olması lazım deyil; məsələn, 6eb3eb5 commit-i serverin heç bir yerində yoxdur.

Əsas iş axını budur. Unutmamaq istədiyiniz bir neçə başqa məqam var:

Git-tfs istifadə edərək eyni ssenaridən keçək. Git depomuzdakı master branch-na etdiyimiz yeni commit-lər:

İndi gəlin görək başqaları işimizi görüb ya yox:

Bəli, iş yoldaşımızın yeni aea74a0 əmri kimi görünən yeni bir TFVC dəyişiklik dəsti əlavə etdiyi və tfs/default uzaq branch-ın hərəkət etdiyi ortaya çıxdı.

Git-tf-də olduğu kimi, bu fərqli tarixi necə həll etmək üçün iki əsas seçimimiz var:

Bu vəziyyətdə, hər bir Git-in bir TFVC dəyişikliyinə çevrildiyi bir “dərin” yoxlama edəcəyik, buna görə geri qayıdaq.

İndi TFVC serverinə kodumuzu yoxlayaraq töhfəmizi tamamlamağa hazırıq. HEAD-dən tapılan ilk tfs uzaq branch-ına gedən yolda hər bir Git əməli üçün bir TFVC dəyişikliyi yaratmaq üçün burada rcheckin əmrindən istifadə edəcəyik (checkin əmri yalnız bir dəyişik yaradır; Git kimi commit-lər götürür).

TFVC serverinə hər uğurlu qeydiyyatdan keçdikdən sonra git-tfs-in qalan işləri əvvəlki işlərinə necə qaytardığına diqqət yetirin. Bunun səbəbi SHA-1 hash-ları dəyişdirən commit mesajlarının altına git-tfs-id sahəsini əlavə etməsidir.

Bu tam olaraq dizayn edilmiş şəkildədir və narahat olacağınız bir şey yoxdur, ancaq bunun baş verdiyini, xüsusən də Git commit-lərini başqaları ilə bölüşdüyünüzü bilməlisiniz.

TFS, versiya nəzarət sistemi ilə inteqrasiya olunan bir çox xüsusiyyətə malikdir, məsələn iş item-ları, təyin olunmuş reviewer-lərin, gated checkins və s. Bu xüsusiyyətlərlə yalnız bir əmr sətiri alətindən istifadə etmək çətin ola bilər, amma xoşbəxtlikdən git-tfs qrafik qeyd alətini çox asanlıqla işə salmağa imkan verir:

Belə görünəcəkdir:

Bu, Visual Studio içərisindən başlayan eyni dialoq olduğundan TFS istifadəçilərinə tanış görünür.

Git-tfs ayrıca Git deposundan TFVC branch-larını idarə etməyə imkan verir. Nümunə olaraq birini yaradaq:

TFVC-də bir branch yaratmaq, bu branch-ın mövcud olduğu bir dəyişiklik dəsti əlavə etmək deməkdir və bu, Git commit-i kimi proqnozlaşdırılır. Git-tfs tfs/featureBee uzaq branch-ını yaratdığını da unutmayın, lakin HEAD hələ də master-ə işarə edir. Newly-minted branch-da işləmək istəyirsinizsə, yeni commit-lərinizi, bəlkə də həmin commit-dən mövzu commit-i yaratmaqla 1d54865 commit-i üzərində qurmaq istəyirsiniz.

Git-tf və Git-tfs TFVC serverlə əlaqə yaratmaq üçün əla vasitədir. Git gücünü yerli olaraq istifadə etməyə, mərkəzi TFVC serverinə davamlı gediş-gəlişdən çəkinməyə və bütün komandanızı Git-ə köçməyə məcbur etmədən bir developer olaraq həyatınızı asanlaşdırmağa imkan verirlər. Windows-da işləyirsinizsə (çox güman ki, komandanız TFS istifadə edir), xüsusiyyət dəsti daha tamamlandığından git-tfs istifadə etmək istərdiniz, ancaq başqa bir platformada işləsəniz, daha məhdud olan git-tf istifadə edəcəksiniz. Bu fəsildəki alətlərin əksəriyyətində olduğu kimi, bu versiya idarəetmə sistemlərindən birini kanonik olaraq seçməlisiniz və digərini tabe bir şəkildə istifadə etməlisiniz - ya Git ya da TFVC əməkdaşlıq mərkəzi olmalıdır, lakin hər ikisi deyil.