9.1 Git ve Diğer Sistemler - İstemci Olarak Git

Git’in tüm Subversion köprüleme komutları için temel komutu git svn 'dir. Birkaç basit iş akışını incelerken en yaygın olanlarını göstereceğiz.

git svn kullanırken, Git’ten çok farklı bir çalışma sistemine sahip olan Subversion ile etkileşimde bulunduğunuzu unutmamalısınız. Yerel dal oluşturup birleştirebilirsiniz, ancak genellikle çalışmanızı yeniden temelleyerek mümkün olduğunca çizgisel tutmak ve bir Git uzak deposuyla eş zamanlı etkileşimde bulunmaktan kaçınmak en iyisidir.

Geçmişinizi yeniden yazıp, tekrar göndermeye çalışmayın ve bir Git reposuna başka geliştiricilerle eş zamanlı itmeye çalışmayın. Subversion yalnızca tek bir çizgisel geçmişe sahip olabilir ve onun kafasını karıştırmak çok kolaydır. Bir ekip ile çalışıyorsanız ve bazıları SVN kullanırken diğerleri Git kullanıyorsa, herkesin işbirliği yapmak için SVN sunucusunu kullandığından emin olun (bu hayatınızı kolaylaştıracaktır).

Bu işlevselliği göstermek için yazma erişiminiz olan tipik bir SVN reposuna ihtiyacınız var. Bu örnekleri kopyalamak istiyorsanız, yazılabilir bir SVN test reposunun bir kopyasını oluşturmanız gerekecektir. Bunu kolayca yapmak için, Subversion ile birlikte gelen svnsync adlı bir aracı kullanabilirsiniz.

Takip edebilmek için önce yeni bir yerel Subversion reposu oluşturmanız gerekiyor:

Sonra, tüm kullanıcıların revprops’ları değiştirmesine izin verin: kolay yol, her zaman 0 (sıfır) çıkışlı bir pre-revprop-change betiği eklemektir:

Şimdi svnsync init komutunu "to" ve "from" repolarıyla kullanarak bu projeyi yerel makinenize senkronize edebilirsiniz.

Bu komut senkronizasyonu çalıştırmak için özellikleri ayarlar. Kodu kopyalamak için şunu çalıştırabilirsiniz:

Bu işlem normalde sadece birkaç dakika sürmesine rağmen, eğer orijinal repoyu başka bir uzak repoya kopyalamaya çalışırsanız, neredeyse bir saat sürecektir (100’den az katkı olsa bile). Subversion her bir revizyonu tek tek kopyalamak ve ardından başka bir repoya geri itmek zorundadır. Gülünç derecede verimsiz olmasına rağmen, bunu yapmanın tek kolay yolu budur.

Şimdi yazma erişimimiz olan bir Subversion reposuna sahip olduğumuza göre, tipik bir iş akışının üzerinden geçebiliriz. Bir Subversion reposunu yerel bir Git reposuna aktaran git svn clone komutuyla başlayacağız. Eğer canlıda olan gerçek bir Subversion reposundan içe aktarıyorsanız, buradaki file:///tmp/test-svn 'yi Subversion reposunuzun URL’siyle değiştirmeyi unutmayın:

Bu girdiğiniz URL üzerinde git svn init ve ardından git svn fetch komutlarının eşdeğerini çalıştırır. İşlemin gerçekleşmesi biraz zaman alabilir. Örneğin, test projesinde yaklaşık 75 katkı varsa ve kod tabanı çok büyük değilse, Git yine de her sürümü tek tek kontrol etmeli ve bunu bireysel olarak katkılamaladır. Yüzlerce veya binlerce katkı içeren bir proje için, bunun tamamlanması gerçekten saatler, hatta günler alabilir.

-T trunk -b branches -t tags kısmı, bu Subversion reposunun temelleme ve etiketleme kurallarını takip ettiğini Git’e belirtir. Eğer ana dalınızı (trunk), dallarınızı veya etiketlerinizi farklı adlandırırsanız, bu seçenekleri değiştirebilirsiniz. Bu çok yaygın olduğu için, ilgili kısmı -s ile değiştirebilirsiniz: bu standart düzeni ima eder ve tüm bu seçenekleri içerir. Aşağıdaki komuta eşdeğerdir:

Bu noktada, dallarınızı ve etiketlerinizi içe aktarmış geçerli bir Git reponuz olmalıdır:

Bu aracın Subversion etiketlerini uzak referanslar olarak nasıl yönettiğine dikkat edin. Git tesisat (plumbing) komutu show-ref ile daha yakından inceleyelim:

Git, bir Git sunucusundan kopyaladığında bunu yapmaz; işte taze bir kopya sonrası etiketlere sahip bir reponun görüntüsü:

Git etiketleri uzak dallar gibi işlemek yerine doğrudan refs/tags içine çeker.

Artık bir çalışma dizininiz olduğuna göre, Git’i bir SVN istemcisi olarak etkili bir şekilde kullanarak proje üzerinde biraz çalışabilir ve katkılarınızı üst-akıma itebilirsiniz. Dosyalardan birini düzenleyip katkılarsanız, Git’te yerel olarak işlenmiş ancak henüz Subversion sunucusunda bulunmayan bir katkıya sahip olursunuz:

Sonraki adım, değişikliklerinizi yukarı akıma itmektir. Subversion ile çalışma şeklinizin değiştiğine dikkat edin: çevrimdışı olarak birkaç katkı yapabilir ve ardından hepsini aynı anda Subversion sunucusuna itebilirsiniz. Bir Subversion sunucusuna itmek için git svn dcommit komutunu çalıştırırsınız:

Bu, Subversion sunucusu kodunun üstüne yaptığınız tüm katkıları alır, her biri için bir Subversion katkısı yapar ve ardından yerel Git katkınızı benzersiz bir kimlik içerecek şekilde yeniden yazar. Bu tüm katkılarınızın SHA-1 kontrol toplamlarının değiştiği anlamına gelmesi yönünden önemlidir. Kısmen bu nedenle, eşzamanlı olarak projelerinizin Git tabanlı uzak sürümleriyle ve bir Subversion sunucusuyla çalışmak iyi bir fikir değildir. Son katkıya baktığınızda, eklenen yeni `git-svn-id`yi görebilirsiniz:

İlk olarak katkıladığınız 4af61fd ile başlayan SHA-1 kontrol toplamının şimdi 95e0222 ile başladığını görüyorsunuz. Eğer hem bir Git sunucusuna hem de bir Subversion sunucusuna itmek istiyorsanız, katkı verilerinizin değişmesi nedeniyle önce Subversion sunucusuna (dcommit) itmelisiniz.

Diğer geliştiricilerle çalışıyorsanız, o zaman biriniz bir noktada kodunu itecek ve ardından diğeri öbürüyle çakışan bir değişiklik itmeye çalışacaktır. Bu değişiklik, siz onların çalışmasını kendinizinkiyle birleştirmedikçe reddedilecektir. git svn 'de durum şöyle görünür:

Bu durumu çözmek için git svn rebase komutunu çalıştırabilirsiniz. Bu komut, sunucudaki henüz sahip olmadığınız tüm değişiklikleri indirir ve yaptığınız çalışmayı sunucudaki mevcut durumun üstüne yerleştirir:

Şimdi, tüm çalışmanız Subversion sunucusundaki durumun üstüne yerleşmiş olduğu için, başarıyla dcommit yapabilirsiniz:

Kodunuzu itmeden önce henüz sahip olmadığınız değişikleri yukarı akımdan çekmenizi gerektiren Git’in aksine, git svn bunu ancak değişiklikler çakıştığında yapmanızı gerektirir (Subversion’ın çalışma şekli gibi). Birisi bir dosyaya bir değişiklik yaptıktan sonra siz de başka bir dosyada bir değişiklik yaparsanız, dcommit sorunsuz çalışacaktır:

Kodunuzu ittiğinizde herhangi birinizin bilgisayarında var olmayan bir proje durumu elde edeceğiniz için bu önemlidir. Değişiklikler ister uyumsuz olsun ister çakışmasın, teşhis etmesi zor sorunlarla karşılaşabilirsiniz. Bu bir Git sunucusu kullanmaktan farklıdır: Git’te, yayınlamadan önce istemcinizdeki durumu tamamen test edebilirsiniz, SVN’de ise katkı öncesi ve sonrası durumların aynı olduğundan kesinlikle emin olamazsınız.

Kendiniz katkı işlemeye hazır olmasanız bile, bu komutu Subversion sunucusundan değişiklikleri çekmek için çalıştırmalısınız. Yeni verileri almak için git svn fetch komutunu çalıştırabilirsiniz ancak git svn rebase hem çekme yapar hem de yerel katkılarınızı günceller.

Arada bir git svn rebase 'i çalıştırmak kodunuzun her zaman güncel olmasını sağlar. Ancak bunu çalıştırdığınızda çalışma dizininizin temiz olduğundan emin olmalısınız. Yerel değişiklikleriniz varsa, git svn rebase 'i çalıştırmadan önce çalışmanızı saklamanız veya geçici olarak kaydetmeniz gerekir; aksi takdirde, rebase’in birleştirme çakışmasına yol açacağını görürse komut duracaktır.

Git iş akışına alıştığınızda, muhtemelen konu dalları oluşturacak, bunlar üzerinde çalışacak ve sonra bunları birleştireceksiniz. Eğer bir Subversion sunucusuna git svn yoluyla itiyorsanız, dalları birleştirmek yerine çalışmanızı her seferinde tek bir dal üzerinde yeniden temellemek isteyebilirsiniz. Yeniden temellemeyi tercih etmenin nedeni, Subversion’un doğrusal bir geçmişe sahip olması ve Git gibi birleştirmelerle ilgilenmemesidir. Dolayısıyla git svn, anlık pozları Subversion katkılarına dönüştürürken yalnızca ilk önceli takip eder.

Geçmişinizin şuna benzediğini varsayalım: bir experiment dalı oluşturdunuz, iki katkı işlediniz ve ardından bunları tekrar master olarak birleştirdiniz. Dcommit yaptığınızda şöyle bir çıktı görürsünüz:

Git proje geçmişinize bakmadığınız sürece birleştirilmiş geçmişe sahip bir dalda dcommit çalıştırmak sorunsuz çalışır. Ancak experiment dalında yaptığınız katkıların hiçbirinin yeniden yazmılamış, bunun yerine tüm bu değişikliklerin SVN sürücüsünde tek bir birleştirme katkısının altında toplanmış olduğunu görürsünüz.

Başka biri bu çalışmayı kopyaladığında, sanki git merge --squash çalıştırmışsınız gibi, tüm çalışmaların içine sıkıştırıldığı birleştirme katkısını görürler. Bunların nereden geldiğine veya ne zaman işlendiğine ilişkin katkı verilerini göremezler.

Subversion’daki dallanma Git’tekiyle aynı değildir: en iyisi, onu çok fazla kullanmaktan kaçınmaktır. Ancak Subversion’da git svn kullanarak dallar oluşturabilir ve bunlara katkı işleyebilirsiniz.

Subversion’da yeni bir dal oluşturmak için git svn Branch [new-branch] komutunu çalıştırın:

Bu, Subversion’daki svn copy trunk Branch/Opera komutunun eşdeğerini yapar ve Subversion sunucusunda çalışır. Sizi o dala geçirmediğini akılda tutmak önemlidir; eğer bu noktada katkıda bulunursanız, bu katkı sunucudaki opera 'ya değil trunk 'a gidecektir.

Git geçmişinizdeki herhangi bir Subversion dalınızın ipucunu arayarak dcommit'lerinizin hangi şubeye gittiğini belirler. Yalnızca bir taneye sahip olmalısınız ve bu, mevcut dal geçmişinizde git-svn-id 'ye sahip son dal olmalıdır.

Aynı anda birden fazla dal üzerinde çalışmak istiyorsanız, yerel dalları belirli Subversion şubelerine dcommit edecek şekilde ayarlayabilirsiniz. Bunları o dal için içe aktarılan Subversion işleminde başlatabilirsiniz. Ayrı ayrı çalışabileceğiniz bir opera dalı istiyorsanız aşağıdaki komutu çalıştırabilirsiniz.

Şimdi, eğer opera dalınızı trunk (master dalınız) ile birleştirmek istiyorsanız, bunu normal bir git merge ile yapabilirsiniz. Ancak (-m aracılığıyla) açıklayıcı bir katkı mesajı girmeniz gerekir, aksi takdirde birleştirme, yararlı bir şey yerine "opera dalını birleştir" diyecektir.

Bu işlemi gerçekleştirmek için git merge kullanıyor olsanız ve (Git sizin için uygun birleştirme tabanını otomatik olarak algılayacağı için) birleştirme muhtemelen Subversion’dakinden çok daha kolay olsa da, bunun normal bir birleştirme işlemi olmadığını unutmayın. Bu verileri, birden fazla önceli olan bir katkıyı işleyemeyen bir Subversion sunucusuna geri göndermeniz gerekir. Yani onu üst akıma ittikten sonra, başka bir dalın tüm çalışmalarını tek bir katkı altında sıkıştıran bir katkı gibi görünecektir. Bir dalı diğeriyle birleştirdikten sonra, Git’te normalde yaptığınız gibi kolayca geri dönüp o dal üzerinde çalışmaya devam edemezsiniz. Çalıştırdığınız dcommit komutu, hangi dalın birleştirildiğini belirten tüm bilgileri siler, dolayısıyla daha sonraki birleştirme temeli hesaplamaları yanlış olur (dcommit komutu sizin git merge sonucunuzu sanki git merge --squash komutunu çalıştırmışsınız gibi görünmesini sağlar).

Ne yazık ki, bu durumu önlemenin iyi bir yolu yoktur (Subversion bu bilgiyi saklayamadığı için, onu sunucunuz olarak kullanırken her zaman sınırlamalarından dolayı bazı şeyler eksik kalacaktır). Sorunları önlemek için, yerel dalı (burada opera) ana dalla birleştirdikten sonra silmelisiniz.

git svn araç seti Subversion’da sahip olduğunuza benzer bazı işlevler sağlayarak, Git’e geçişi kolaylaştırmaya yardımcı olacak bir dizi komut sunar. Subversion’un eskiden ne yaptığını size veren birkaç komut:

git svn araçları bir Subversion sunucusunda sıkışıp kaldıysanız veya başka bir geliştirme ortamında bir Subversion sunucusunu çalıştırmanız gerekiyorsa faydalıdır. Ancak bu araçları kısıtlı Git olarak düşünmelisiniz, aksi takdirde sizin ve ekip arkadaşlarınızın kafasını karıştıracak çeviri sorunlarıyla karşılaşabilirsiniz.

Sorun yaşamamak için şu kuralları izlemeye çalışın:

Bu kuralları izlerseniz, bir Subversion sunucusu ile çalışmak daha katlanılabilir bir hale gelir. Ancak, mümkünse gerçek bir Git sunucusuna geçmek, takımınıza çok daha fazla fayda sağlayabilir.

Öncelikle git-remote-hg’yi kurmanız gerekiyor. Bu, temel olarak dosyasını yolunuzun üzerinde bir yere bırakmayı gerektirir:

…~/bin öğesinin $PATH dizininizde olduğunu varsayıyoruz. Git-remote-hg’nin başka bir bağımlılığı daha var: Python için "Mercurial" kütüphanesi. Python’u yüklediyseniz, bu şu kadar basittir:

(Python yüklü değilse https://www.python.org/ adresini ziyaret edin ve önce onu kurun.)

İhtiyacınız olan son şey Mercurial istemcisidir. https://www.mercurial-scm.org/ adresine gidin ve henüz yapmadıysanız yükleyin.

Artık dansa hazırsınız. İhtiyacınız olan tek şey, itebileceğiniz bir Mercurial reposudur. Neyse ki, her Mercurial reposu bu şekilde davranır, bu nedenle herkesin Mercurial’ı öğrenmek için kullandığı "merhaba dünya" reposunu kullanacağız:

Artık uygun bir “sunucu tarafı” repomuz olduğuna göre, tipik bir iş akışını gerçekleştirebiliriz. Göreceğiniz üzere, bu iki sistem fazla sürtünme olmayacak kadar benzerdir.

Git’te her zaman olduğu gibi önce repoyu kopyalarız:

Mercurial reposuyla çalışmanın standart "git clone" komutunu kullandığını fark edeceksiniz. Bunun nedeni, git-remote-hg’nin Git’in HTTP/S protokolünün uygulanmasına (uzaktan yardımcılar) benzer bir mekanizma kullanarak oldukça düşük bir düzeyde çalışmasıdır. Git ve Mercurial’ın her ikisi de her kullanıcının repo geçmişinin tam bir kopyasına sahip olması için tasarlandığından, bu komut tüm projenin geçmişini içeren tam bir kopya oluşturur ve bunu çok hızlı bir şekilde yapar.

Log komutu, en sonuncusu bir dizi referans tarafından işaret edilen iki işlemi gösterir. Bunlardan bazılarının aslında orada olmadığı ortaya çıktı. .git dizininde gerçekte ne olduğuna bir bakalım:

Git-remote-hg işleri daha deyimsel olarak Git benzeri hale getirmeye çalışır, ancak aslında birbirinden biraz farklı iki sistem arasındaki kavramsal eşlemeyi yönetir. refs/hg dizini gerçek uzak referansların saklandığı yerdir. Örneğin, "refs/hg/origin/branches/default", "master"ın işaret ettiği katkı olan "ac7955c" ile başlayan SHA-1’i içeren bir Git ref dosyasıdır. Yani refs/hg dizini bir nevi sahte refs/remotes/Origin gibidir, ancak yer imleri ve dallar arasında ek bir ayrım vardır.

notes/hg dosyası, git-remote-hg’nin Git katkı karmalarını Mercurial değişiklik kümesi kimlikleriyle nasıl eşlediğinin başlangıç noktasıdır. Hadi biraz araştıralım:

Yani refs/notes/hg, Git nesne veritabanında adları olan diğer nesnelerin listesi olan bir ağaca işaret eder. git ls-tree bir ağacın içinde yer alan öğeler için: mod, tür, nesne karması ve dosya adını verir. Ağaç öğelerinden birini incelediğimizde, içinde “ac9117f” ("master" ile gösterilen katkının SHA-1 karması) adında ve “0a04b98” içeriğine sahip bir blob olduğunu görürüz (bu, varsayılan dalın ucundaki Mercurial değişiklik kümesinin kimliğidir).

Güzel olan şu ki, çoğunlukla tüm bunlar için endişelenmemize gerek yoktur. Tipik iş akışı Git uzaktan reposuyla çalışmaktan çok farklı olmayacaktır.

Devam etmeden önce ilgilenmemiz gereken bir şey daha var: yoksayılanlar. Mercurial ve Git bunun için çok benzer bir mekanizma kullanır, ancak muhtemelen bir .gitignore dosyasını Mercurial reposuna işlemek istemezsiniz. Neyse ki Git’in diskteki bir repoda yerel olan dosyaları yok saymanın bir yolu var ve bu Mercurial formatı Git ile uyumludur; dolayısıyla onu kopyalamanız yeterli:

.git/info/exclude dosyası tıpkı .gitignore gibi davranır ancak katkılara dahil edilmez.

Diyelim ki master dalında bazı değişiklikler yaptık ve bazı katkılar işledik ve siz de bunu uzak repoya göndermeye hazırsınız. Repomuz şu anda şöyle görünüyor:

Bizim master dalımız, Origin/master 'dan iki katkı ileridedir, ancak bu iki katkı yalnızca yerel makinemizde mevcuttur. Bakalım aynı anda, başka biri de önemli işler yapıyor mu:

--all bayrağını kullandığımız için, git-remote-hg tarafından dahili olarak kullanılan ``notes`` referanslarını görüyoruz, ancak onları görmezden gelebiliriz. Gerisi beklediğimiz gibidir; Origin/master tek bir katkı ilerledi ve artık geçmişimiz ayrıştı. Bu bölümde üzerinde çalıştığımız diğer sistemlerden farklı olarak; Mercurial, birleştirme işlemlerini gerçekleştirebilir, dolayısıyla havalı bir şey yapmayacağız.

Mükemmel. Testleri yapıyoruz ve her şey başarılı oluyor, böylece çalışmalarımızı ekibin geri kalanıyla paylaşmaya hazırız:

Bu kadar! Mercurial reposuna bakarsanız, bunun beklediğimiz şeyi yaptığını göreceksiniz:

2 numaralı değişiklik seti Mercurial tarafından, 3 ve 4 numaralı değişiklik seti ise Git-remote-hg tarafından Git ile yapılan katkıların itilmesiyle yapıldı.

Git’in yalnızca tek bir tür dalı vardır: katkılar işlendiğinde hareket eden bir referans. Mercurial’da bu tür bir referansa ``yer imi`` (bookmark) adı verilir ve Git dalıyla hemen hemen aynı şekilde davranır.

Mercurial’ın ``dal`` kavramı daha ağırdır. Değişiklik kümesinin yapıldığı dal, değişiklik kümesiyle birlikte kaydedilir. Bu da her zaman repo geçmişinde yeralacağı anlamına gelir. develop dalında yapılan bir katkı örneği:

``branch`` ile başlayan satıra dikkat edin. Git bunu gerçekten kopyalayamaz (her iki dal türü de Git referansı olarak temsil edilebildiği için gerek de yoktur zaten), ancak Mercurial bunu önemsediği için git-remote-hg’nin farkı anlaması gereklidir.

Mercurial yer imleri oluşturmak Git dalları oluşturmak kadar kolaydır. Git tarafında:

Hepsi bu kadardır. Mercurial tarafında ise şöyle görünür:

Revizyon 5’teki yeni [featureA] etiketine dikkat edin. Bunlar, bir istisna dışında Git tarafındaki Git dalları gibi davranır (Git tarafından bir yer işaretini silemezsiniz: bu, uzak yardımcılara yönelik bir sınırlamadır).

Ayrıca “ağır” bir Mercurial dalı üzerinde de çalışabilirsiniz: ``branches`` ad alanına (namespace) bir dal koymanız yeterlidir:

Mercurial tarafın şöyle görünür:

``permanent`` (kalıcı) dal adı, 7 işaretli değişiklik kümesiyle kaydedildi.

Git açısından bakıldığında, bu dal stillerinden herhangi biriyle çalışmak aynıdır: normalde yaptığınız gibi yalnızca geçiş yapın, kaydedin, getirin, birleştirin, çekin ve itin. Bilmeniz gereken bir şey de Mercurial’ın tarihin yeniden yazılmasını desteklememesidir. Ona yalnızca ekleme yapabilirsiniz. Etkileşimli bir yeniden temelleme (rebase) ve zorla itme (forced push) sonrasında Mercurial repomuz şu şekilde görünür:

8, 9 ve 10 değişiklik kümeleri oluşturuldu ve permanent dalına aitler, ancak eski değişiklik kümeleri hâlâ duruyor. Bu, Mercurial kullanan takım arkadaşlarınız için çok kafa karıştırıcı olabilir, bu yüzden bundan kaçınmaya çalışın.

Git ve Mercurial, sınırın ötesinde çalışmanın oldukça sancısız olmasını sağlayacak kadar benzerdir. (Genellikle önerildiği üzere) makinenizden kalan geçmişi değiştirmekten kaçınırsanız, diğer ucun Mercurial olduğunun farkına bile varmazsınız.

Kullanımı oldukça basittir. Bir Bazaar reposunu kopyalamak için onu bzr:: önekiyle kopyalamak yeterlidir. Hem Git hem de Bazaar, makinanıza tam kopyalar yapar; bu nedenle bir Git kopyasını yerel Bazaar kopyanıza bağlamak mümkündür, ancak önerilmez. Git kopyanızı doğrudan Bazaar kopyanızın bağlı olduğu yere (merkezi repo) bağlamak çok daha kolaydır.

Varsayalım ki bzr+ssh://developer@mybazaarserver:myproject adresinde bir uzak repo ile çalıştınız. O zaman onu şu şekilde kopyalamalısınız:

Bu noktada, Git reposu oluşturulmuş olsa da, disk kullanımı için optimize edilmiş değildir. Bu yüzden, özellikle büyük bir repo ise, Git reposunuzu temizlemeniz ve sıkıştırmanız gerekmektedir:

Bazaar sadece dalları kopyalamanıza izin verir, ancak bir repo birden çok dal içerebilir ve git-remote-bzr her ikisini de kopyalayabilir. Örneğin, bir dalı kopyalamak için:

Ve tüm repoyu kopyalamak için:

İkinci komut, emacs reposunda bulunan tüm dalları kopyalar; yine de, belirli bazı dalları işaretlemek mümkündür:

Bazı uzak repolar, dallarını listeleme izni vermez; bu durumda onları manuel olarak belirtmeniz gerekir. Kpyalama komutunda yapılandırmayı belirtmenize rağmen, bu yöntemi daha kolay bulabilirsiniz:

Bazaar tarafından yönetilen bir projede çalıştığınızdan, .gitignore dosyası oluşturmamalısınız. Çünkü yanlışlıkla sürüm kontrolü altına alabilirsiniz ve Bazaar ile çalışan diğer kişiler bundan rahatsız olabilir. Çözüm, simgesel bir bağ olarak veya düzenli bir dosya olarak .git/info/exclude dosyasını oluşturmaktır. Bu sorunu nasıl çözeceğimizi daha sonra göreceğiz.

Bazaar, dosyaları yok saymak için Git ile aynı modeli kullanır, ancak benzersiz iki özelliğe de sahiptir. Tam açıklamayı dokümantasyonda bulabilirsiniz. Bahsettiğimiz iki özellik şunlardır:

Sonuç olarak, düşünülmesi gereken iki farklı durum vardır:

Ne olursa olsun, .bzrignore 'daki herhangi bir değişikliğe karşı dikkatli olmalı ve .git/info/exclude dosyasının her zaman .bzrignore 'u yansıttığından emin olmalısınız. Gerçekten de, eğer .bzrignore dosyası değişirse ve "!!" veya "RE:" ile başlayan bir veya daha fazla satır içeriyorsa; Git bu satırları yorumlayamadığından, .git/info/exclude dosyanızı .bzrignore ile aynı dosyaları yok sayacak şekilde uyarlamalısınız. Ayrıca, .git/info/exclude dosyası sembolik bir bağsa, önce sembolik bağı silmeniz, .bzrignore'u .git/info/exclude'a kopyalamanız ve daha sonra ikincisini uyarlamanız gerekecektir. Ancak dikkatli olun, çünkü Git’te bir dosyanın üst dizinini hariç tutarsanız, dosyayı yeniden dahil etmek imkansızdır.

Uzak repodaki değişiklikleri getirmek için, Git komutlarını kullanarak değişiklikleri her zamanki gibi çekersiniz. Değişikliklerinizin "master" dalında olduğunu varsayarak, çalışmanızı "Origin/master" dalında birleştirir veya yeniden temellendirirsiniz:

Bazaar’ın da birleştirme işlemi kavramı olduğu için, birleştirme işlemi içeren bir işlem yaparsanız sorun yaşamayacaksınız. Bu nedenle bir dalda çalışabilir, değişiklikleri `master`a birleştirebilir ve çalışmanızı gönderebilirsiniz. Sonra, dallarınızı oluşturur, çalışmanızı test eder ve normal şekilde kaydedersiniz. Son olarak, çalışmanızı Bazaar reposuna gönderirsiniz:

Git’in uzak yardımcılar çerçevesinin geçerli bazı sınırlamaları vardır. Özellikle şu komutlar çalışmaz:

Git’in ve Bazaar’ın modelleri benzer olduğundan sınırın ötesinde çalışırken çok fazla direnç görülmez. Sınırlamalara dikkat ettiğiniz ve uzak reponun yerel olarak Git olmadığının her zaman farkında olduğunuz sürece sorun olmaz.

Perforce, bir Perforce sunucusunu sunucu tarafındaki Git repolarıyla senkronize eden "Git Fusion" adlı bir ürün sağlar. Bu ürünü http://www.perforce.com/git-fusion adresinden temin edebilirsiniz.

Git-p4, Git ile Perforce arasında iki yönlü bir köprüdür. Tamamen Git reposu içinde çalışır, bu nedenle Perforce sunucusuna erişim sağlamanıza gerek yoktur (elbette kullanıcı kimlik bilgilerine ihtiyacınız olacaktır). Git-p4, Git Fusion kadar esnek veya tam bir çözüm değildir, ancak sunucu ortamına aşırı müdahale etmeden istediğiniz çoğu şeyi yapmanıza izin verir.

Git-p4, bir Perforce sunucusu ile Git iş akışını kullanmayı mümkün kılar ve bu konuda oldukça iyidir. Ancak kaynakların kontrolünün Perforce’da olduğunu ve Git’i sadece yerelde çalışmak için kullandığınızı unutmamalısınız. Git katkılarını paylaşırken çok dikkatli olun. Başkalarıyla ortak kullandığız bir uzak sunucunuz varsa, Perforce sunucusuna göndermediğiniz hiçbir katkıyı oraya göndermeyin.

Eğer Perforce ve Git’i özgürce kaynak kontrolü istemcileri olarak karıştırmak ister ve sunucu yöneticisini bunu kurmaya ikna edebilirseniz; Git Fusion, Git’i bir Perforce sunucusu için birinci sınıf bir versiyon kontrol istemcisi olarak kullanmanızı sağlar.

İki tane bulunmaktadır: git-tf ve git-tfs.

Git-tfs (https://github.com/git-tfs/git-tfs adresinde bulabilirsiniz) yalnızca Windows’ta çalışın bir .NET projesidir. Git repolarıyla çalışmak için libgit2 için .NET bağlantılarını kullanır. Libgit2 Git’in kütüphane odaklı bir uygulamasıdır ve Git reposunun iç yapısında esneklik ve yüksek performans sağlar. Libgit2, Git’in tam bir uygulaması değildir, bu yüzden farklılıkları kapsamak için bazı işlemlerde aslında komut satırı Git istemcisini çağırır. Yani, Git repolarıyla yapabileceği işlemler üzerinde yapay sınırlamalar yoktur. Sunucu işlemleri için Visual Studio derlemelerini kullandığı için, TFVC özelliklerine olan desteği çok ileri seviyededir. Bu, bu derlemelere erişiminizin olması gerektiği anlamına gelir, yani son sürüm bir Visual Studio (2010 sürümünden itibaren herhangi bir sürüm, 2012 sürümünden itibaren Express sürümleri dahil) veya Visual Studio SDK’sı kurmanız gerekir.

Git-tf (https://gittf.codeplex.com adresinde bulabilirsiniz) bir Java projesidir ve Java çalışma ortamına (runtime environment) sahip her bilgisayarda çalışır. Git repolarıyla JGit (Git’in JVM uygulaması) aracılığıyla etkileşir, bu da Git işlevleri açısından neredeyse hiçbir kısıtlaması olmadığı anlamına gelir. Ancak, git-tfs’e kıyasla TFVC desteği sınırlıdır (örneğin dalları desteklemez).

Her bir aracın avantajları ve dezavantajları vardır ve birini diğerine tercih eden birçok durum bulunur. Bu kitapta her ikisinin de temel kullanımını ele alacağız.

Herhangi bir Git projesi gibi, ilk yapmanız gereken kopyalamadır. İşte git-tf ile bunun nasıl yapıldığı:

İlk argüman, bir TFVC koleksiyonunun URL’sidir, ikincisi $ / proje / dal formunda ve üçüncüsü oluşturulacak yerel Git reposunun dizinidir (bu sonuncusu isteğe bağlıdır). Git-tf tek seferde yalnızca bir dalda çalışabilir: farklı bir TFVC dalında geçiş yapmak istiyorsanız, o daldan yeni bir klon oluşturmanız gerekecektir.

Bu tam olarak işlevsel bir Git reposu oluşturur:

Bu, yalnızca en son değişiklik setinin indirildiği sığ bir klon denir. TFVC her istemcinin tüm geçmişin tam bir kopyasına sahip olması için tasarlanmamıştır, bu nedenle git-tf varsayılan olarak yalnızca en son sürümü almak için ayarlanmıştır ki bu çok daha hızlıdır.

Eğer zamanınız varsa --deep seçeneğini kullanarak tüm proje geçmişini kopyalamakta fayda vardır:

TFS_C35189 gibi adlara sahip etiketlere dikkat edin: bu hangi Git commit’lerinin TFVC değişiklik setleri ile ilişkilendirildiğini bilmeye yardımcı olan bir özelliktir. Bu basit bir log komutu ile hangi katkılarınızın TFVC’de de bulunan bir poz ile ilişkili olduğunu görebileceğiniz, hoş bir yoldur. Bunlar aslında gerekli değildir (git config git-tf.tag false ile de bunları kapatabilirsiniz). git-tf gerçek katkı-değişiklik seti eşlemelerini .git/git-tf dosyasında tutar.

Git-tfs klonlaması biraz farklı davranır. İnceleyin:

--with-branches bayrağına dikkat edin. Git-tfs TFVC dallarını Git dallarına eşleyecek yetenektedir ve bu bayrak her TFVC dalı için yerel bir Git dalı kurmasını söyler. Bu TFS’de şimdiye kadar dallandırma veya birleştirme yaptıysanı kesinlikle önerilir, ancak TFS 2010’dan önceki bir sunucu ile çalışmaz (bu sürümden önce "dallar" sadece klasörlerdi, bu yüzden git-tfs onları normal klasörlerden ayırt edemez).

Şimdi oluşan Git reposuna bir göz atalım:

İki yerel dal vardır: master ve featureA. Bu da kopyalamanın başlangıç noktasını (TFVC’de Trunk) ve bir alt dalı (TFVC’de featureA) temsil eder. Ayrıca tfs "remote" da TFVC dallarını temsil eden bir çift referans da bulunur: default ve featureA. Git-tfs kopyaladığınız dalı tfs/default ile eşler, diğerleri kendi adlarını alır.

Dikkate değer bir başka bir şey de Katkı mesajlarındaki git-tfs-id: satırlarıdır. git-tfs etiketler yerine bu işaretleri kullanarak TFVC değişiklik setlerini Git katkılarıyla ilişkilendirir. Bu Git katkılarınızın TFVC’ye gönderilmeden önce ve sonra farklı SHA-1 karma değerlerine sahip olacağı anlamına gelir.

Sıradaki işiniz bir projede çalışmak olacaktır. TFVC ve TFS iş akışınıza karmaşıklık katabilecek birkaç özellik sunar:

Kısa ve öz olması adına, burada kapsayacağımız şey, çoğu bu sorunları atlatmanızı veya onlardan kaçınmanızı sağlayacak "mutlu patika" olacaktır.

Diyelim ki biraz çalışma yaptınız, master üzerinde birkaç Git katkısı yaptınız ve ilerlemenizi TFVC sunucusuyla paylaşmaya hazırsınız. İşte Git repomuz:

4178a82 katkısındaki pozu almak ve bunu TFVC sunucusuna yüklemek istiyoruz. Öncelikle, son bağlandığımızdan beri takım arkadaşlarımızın bir şeyler yapıp yapmadığını kontrol edelim:

Görünüşe göre başka biri de çalışıyor ve şimdi farklı geçmişlerimiz var. İşte Git’in parladığı yer burasıdır, ancak ilerlemek için iki seçeneğimiz var:

Tercih sizin. Biz bu örnekte yeniden temelleme yapacağız:

Şimdi TFVC sunucusuna bir geçmeye hazırız. Git-tf son değişiklikten bu yana tüm değişiklikleri temsil eden tek bir değişiklik seti yapma (varsayılan seçenek olan --shallow) veya her Git katkısı için yeni bir değişiklik seti oluşturma (--deep) seçeneği sunar. Bu örnekte sadece bir değişiklik seti oluşturacağız:

Yeni bir TFS_C35348 etiketi var, bu da TFVC’nin tam olarak 5a0e25e katkısındaki aynı pozu sakladığını gösteriyor. Her Git katkısının TFVC’de tam bir karşılığa sahip olması gerekmediğini bilmek önemlidir: örneğin, 6eb3eb5 katkısı sunucudaki hiçbir yerde mevcut değildir.

Bu ana iş akışıdır. Aklınızda bulundurmanız gereken birkaç başka husus var:

Aynı senaryoyu git-tfs kullanarak adım adım geçelim. İşte Git reposundaki master dalına işlediğimiz yeni katkılar:

Şimdi, biz çalışırken başka birinin iş yapmış olup olmadığını görelim:

Evet, iş arkadaşımız aea74a0 katkısıyla yeni bir TFVC değişiklik seti eklemiş ve tfs/default uzak dalı hareket etmiş.

Git-tf ile olduğu gibi, bu ayrık geçmişi nasıl çözeceğimize dair iki temel seçeneğimiz var:

Bu durumda, her Git katkısının bir TFVC değişiklik seti haline geldiği bir deep (derin) katkılama yapacağız, bu yüzden yeniden temellemek istiyoruz.

Şimdi katkımızı tamamlamak için kodumuzu TFVC sunucusuna işlemeye hazırız. Burada her Git katkısının HEAD kısmandan, ilk bulunan tfs uzak dalına kadar olan yol boyunca bir TFVC değişiklik seti oluşturmak için rcheckin komutunu kullanacağız (checkin komutu Git katkılarını birleştirmek gibi, sadece bir değişiklik seti oluşturur).

Her başarılı checkin işleminin ardından, git-tfs’in kalan işi yeni yaptığı işin üzerine yeniden temellemesi dikkatinizi çekmiş olabilir. Bunun nedeni, katkı mesajlarının altına git-tfs-id alanını eklemesidir, bu da SHA-1 karma değerlerini değiştirir. Bu tam olarak tasarlandığı gibidir ve endişelenecek bir şey yoktur, ancak özellikle de Git katkılarını başkalarıyla paylaşıyorsanız, bunun farkında olmanız önemlidir.

TFS’nin birçok özelliği, iş öğeleri, atanmış gözden geçirenler, kontrollü checkinler vb. gibi sürüm kontrol sistemi ile entegre olan özellikleri bulunmaktadır. Sadece komut satırı aracını kullanarak bu özelliklerle çalışmak sıkıcı olabilir, ancak neyse ki git-tfs çok kolay bir şekilde grafiksel bir checkin aracı başlatabilmenizi sağlar:

Biraz şöyle şunun gibi görünür:

Bu TFS kullanıcılarının aşina olduğu şekilde, Visual Studio içinden başlatılan iletişim kutusuna benzer.

Git-tfs ayrıca Git reposundan TFVC dallarını kontrol etmenizi sağlar. Bir örnek olarak, bir tane oluşturalım:

TFVC’de bir dal oluşturmak, bu dalın artık bulunduğu bir değişiklik seti eklemeyi ve bu değişiklik setinin bir Git katkısı olarak yansıtıldığı anlamına gelir. Ayrıca git-tfs’nin tfs/featureBee uzak dalını oluşturduğunu, ancak HEAD 'in hâlâ main 'i gösterdiğini unutmayın. Yeni oluşturulan dal üzerinde çalışmak istiyorsanız, belki de bu katkıdan bir konu dalı oluşturarak yeni katkılarınızı 1d54865 katkısına dayandırmak isteyebilirsiniz.

Git-tf ve Git-tfs TFVC sunucusuyla etkileşimde bulunmak için harika araçlardır. Size yerelde Git’in gücünü kullanma, sürekli olarak merkezi TFVC sunucusuna yolculuk yapmaktan kaçınma ve geliştirici olarak hayatınızı çok daha kolay hale getirme imkanı sağlarlar, ancak tüm ekibinizi Git’e taşımaya zorlamazlar. Eğer Windows’ta çalışıyorsanız (ki ekibiniz TFS kullanıyorsa muhtemelen durum budur), muhtemelen özellik seti daha tam olduğu için git-tfs’i kullanmak isteyeceksiniz, ancak başka bir platformda çalışıyorsanız, daha sınırlı olan git-tf’i kullanacaksınız. Bu bölümdeki çoğu araç gibi, bu versiyon kontrol sistemlerinden birini standart olarak seçmeli ve diğerini yardımcı bir şekilde kullanmalısınız (ya Git ya da TFVC işbirliğinin merkezi olmalı, ancak ikisi birden değil).