Git Windows geliştiricileri arasında gittikçe daha popüler hale gelmektedir ve eğer Windows üzerinde kod yazıyorsanız, Microsoft’un Team Foundation Server (TFS) kullanma olasılığınız yüksektir. TFS, hata ve iş öğesi izleme, Scrum ve diğerleri için süreç desteği, kod incelemesi ve sürüm kontrolü gibi işbirliği paketini içerir. Ancak önümüzde biraz kafa karışıklığı vardır: TFS kendi özel VCS’leri olan TFVC (Team Foundation Version Control) ile birlikte Git’i de destekleyen bir sunucudur. Git desteği TFS’in nispeten yeni bir özelliğidir (2013 sürümü ile birlikte gelmiştir), bu yüzden daha öncesindeki tüm araçlar, çoğunlukla TFVC ile çalışsalar da sürüm kontrol kısmını "TFS" olarak adlandırırlar.
Eğer kendinizi TFVC kullanan bir takımda bulursanız ve sürüm kontrol istemci olarak Git’i tercih ediyorsanız, sizin için bir proje bulunmaktadır.
İ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.
|
Note
|
Bu yönergeleri takip etmek için TFVC tabanlı bir repoya erişiminiz olması gerekecek. Bunlar genelde Git veya Subversion repoları kadar yaygın değildir, bu yüzden kendi TFVC tabanlı reponuzu oluşturmanız gerekebilir. Codeplex (https://www.codeplex.com) veya Visual Studio Online (https://visualstudio.microsoft.com) araçlarının her ikisi de bunun için iyi seçeneklerdir. |
Herhangi bir Git projesi gibi, ilk yapmanız gereken kopyalamadır.
İşte git-tf ile bunun nasıl yapıldığı:
$ git tf clone https://tfs.codeplex.com:443/tfs/TFS13 $/myproject/Main project_gitİ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:
$ cd project_git
$ git log --all --oneline --decorate
512e75a (HEAD, tag: TFS_C35190, origin_tfs/tfs, master) Checkin messageBu, 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:
$ git tf clone https://tfs.codeplex.com:443/tfs/TFS13 $/myproject/Main \
project_git --deep
Username: domain\user
Password:
Connecting to TFS...
Cloning $/myproject into /tmp/project_git: 100%, done.
Cloned 4 changesets. Cloned last changeset 35190 as d44b17a
$ cd project_git
$ git log --all --oneline --decorate
d44b17a (HEAD, tag: TFS_C35190, origin_tfs/tfs, master) Goodbye
126aa7b (tag: TFS_C35189)
8f77431 (tag: TFS_C35178) FIRST
0745a25 (tag: TFS_C35177) Created team project folder $/tfvctest via the \
Team Project Creation WizardTFS_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:
PS> git tfs clone --with-branches \
https://username.visualstudio.com/DefaultCollection \
$/project/Trunk project_git
Initialized empty Git repository in C:/Users/ben/project_git/.git/
C15 = b75da1aba1ffb359d00e85c52acb261e4586b0c9
C16 = c403405f4989d73a2c3c119e79021cb2104ce44a
Tfs branches found:
- $/tfvc-test/featureA
The name of the local branch will be : featureA
C17 = d202b53f67bde32171d5078968c644e562f1c439
C18 = 44cd729d8df868a8be20438fdeeefb961958b674--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:
PS> git log --oneline --graph --decorate --all
* 44cd729 (tfs/featureA, featureA) Goodbye
* d202b53 Branched from $/tfvc-test/Trunk
* c403405 (HEAD, tfs/default, master) Hello
* b75da1a New project
PS> git log -1
commit c403405f4989d73a2c3c119e79021cb2104ce44a
Author: Ben Straub <ben@straub.cc>
Date: Fri Aug 1 03:41:59 2014 +0000
Hello
git-tfs-id: [https://username.visualstudio.com/DefaultCollection]$/myproject/Trunk;C16İ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.
|
Note
|
Hangi aracı kullandığınızdan bağımsız olarak, sorunlarla karşılaşmamak için birkaç Git yapılandırma değerini ayarlamanız önerilir. $ git config set --local core.ignorecase=true
$ git config set --local core.autocrlf=false |
Sıradaki işiniz bir projede çalışmak olacaktır. TFVC ve TFS iş akışınıza karmaşıklık katabilecek birkaç özellik sunar:
-
TFVC’de temsil edilmeyen özellik dalları karmaşıklığı arttırır. Bu TFVC ve Git’in dalları temsil etme şekillerinin çok farklı olmasından kaynaklanır.
-
TFVC kullanıcıların dosyaları sunucudan "checkout" yapıp kilitleyerek, başkalarının onları değiştirmesini engellemenize izin verir. Bu, elbette, dosyaları yerel repoda düzenlemeyi engellemeyecektir, ancak değişikliklerinizi TFVC sunucusuna yüklerken engel olabilir.
-
TFS’nin "gated" checkin kavramı vardır, burada bir TFS derleme-test döngüsünün başarıyla tamamlanması gerekmektedir. Bu, TFVC’de
shelveişlevini kullanır, ancak burada bunu incelemeyeceğiz. Bu işlemi git-tf ile manuel olarak taklit edebilirsiniz ve git-tfs gate bilgisine sahip olancheckintoolkomutunu sağlar.
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:
$ git log --oneline --graph --decorate --all
* 4178a82 (HEAD, master) update code
* 9df2ae3 update readme
* d44b17a (tag: TFS_C35190, origin_tfs/tfs) Goodbye
* 126aa7b (tag: TFS_C35189)
* 8f77431 (tag: TFS_C35178) FIRST
* 0745a25 (tag: TFS_C35177) Created team project folder $/tfvctest via the \
Team Project Creation Wizard4178a82 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:
$ git tf fetch
Username: domain\user
Password:
Connecting to TFS...
Fetching $/myproject at latest changeset: 100%, done.
Downloaded changeset 35320 as commit 8ef06a8. Updated FETCH_HEAD.
$ git log --oneline --graph --decorate --all
* 8ef06a8 (tag: TFS_C35320, origin_tfs/tfs) just some text
| * 4178a82 (HEAD, master) update code
| * 9df2ae3 update readme
|/
* d44b17a (tag: TFS_C35190) Goodbye
* 126aa7b (tag: TFS_C35189)
* 8f77431 (tag: TFS_C35178) FIRST
* 0745a25 (tag: TFS_C35177) Created team project folder $/tfvctest via the \
Team Project Creation WizardGö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:
-
Birleştirme bir Git kullanıcısı olarak doğal hissettirir (sonuçta bu
git pull'un yaptığı şeydir) ve git-tf bunu basit birgit tf pullile yapabilir. Ancak TFVC bu şekilde düşünmez ve birleştirme işlemlerini gönderirseniz; geçmişiniz her iki tarafta da farklı görünmeye başlayacaktır, bu da kafa karıştırıcı olabilir. Bununla birlikte, tüm değişikliklerinizi bir değişiklik seti olarak göndermeyi planlıyorsanız, bu muhtemelen en kolay seçenektir. -
Yeniden temelleme katkı geçmişimizi çizgisel hale getirir, bu da her bir Git katkısını bir TFVC değişiklik setine dönüştürme seçeneğimizin olduğu anlamına gelir. En fazla seçeneği açık bıraktığından, bunu yapmanızı öneririz (git-tf bunu bile
git tf pull --rebaseile size kolaylaştırır).
Tercih sizin. Biz bu örnekte yeniden temelleme yapacağız:
$ git rebase FETCH_HEAD
First, rewinding head to replay your work on top of it...
Applying: update readme
Applying: update code
$ git log --oneline --graph --decorate --all
* 5a0e25e (HEAD, master) update code
* 6eb3eb5 update readme
* 8ef06a8 (tag: TFS_C35320, origin_tfs/tfs) just some text
* d44b17a (tag: TFS_C35190) Goodbye
* 126aa7b (tag: TFS_C35189)
* 8f77431 (tag: TFS_C35178) FIRST
* 0745a25 (tag: TFS_C35177) Created team project folder $/tfvctest via the \
Team Project Creation WizardŞ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:
$ git tf checkin -m 'Updating readme and code'
Username: domain\user
Password:
Connecting to TFS...
Checking in to $/myproject: 100%, done.
Checked commit 5a0e25e in as changeset 35348
$ git log --oneline --graph --decorate --all
* 5a0e25e (HEAD, tag: TFS_C35348, origin_tfs/tfs, master) update code
* 6eb3eb5 update readme
* 8ef06a8 (tag: TFS_C35320) just some text
* d44b17a (tag: TFS_C35190) Goodbye
* 126aa7b (tag: TFS_C35189)
* 8f77431 (tag: TFS_C35178) FIRST
* 0745a25 (tag: TFS_C35177) Created team project folder $/tfvctest via the \
Team Project Creation WizardYeni 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:
-
Dallanma yoktur. Git-tf bir TFVC dalından yalnızca bir Git reposu oluşturabilir.
-
TFVC veya Git kullanarak işbirliği yapın, ancak her ikisini birden kullanmayın. Aynı TFVC reposunun farklı git-tf kopyaları farklı SHA-1 karma değerlerine sahip olabilir, bu da baş ağrısına neden olabilir.
-
Takımınızın iş akışı, Git’te işbirliği yapmayı ve düzenli aralıklarla TFVC ile senkronize etmeyi içeriyorsa, TFVC’ye sadece Git repolarından biriyle bağlanın.
Aynı senaryoyu git-tfs kullanarak adım adım geçelim.
İşte Git reposundaki master dalına işlediğimiz yeni katkılar:
PS> git log --oneline --graph --all --decorate
* c3bd3ae (HEAD, master) update code
* d85e5a2 update readme
| * 44cd729 (tfs/featureA, featureA) Goodbye
| * d202b53 Branched from $/tfvc-test/Trunk
|/
* c403405 (tfs/default) Hello
* b75da1a New projectŞimdi, biz çalışırken başka birinin iş yapmış olup olmadığını görelim:
PS> git tfs fetch
C19 = aea74a0313de0a391940c999e51c5c15c381d91d
PS> git log --all --oneline --graph --decorate
* aea74a0 (tfs/default) update documentation
| * c3bd3ae (HEAD, master) update code
| * d85e5a2 update readme
|/
| * 44cd729 (tfs/featureA, featureA) Goodbye
| * d202b53 Branched from $/tfvc-test/Trunk
|/
* c403405 Hello
* b75da1a New projectEvet, 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:
-
çizgisel geçmişi korumak için yeniden temelleme.
-
Gerçekte ne olduğunu korumak için birleştirme.
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.
PS> git rebase tfs/default
First, rewinding head to replay your work on top of it...
Applying: update readme
Applying: update code
PS> git log --all --oneline --graph --decorate
* 10a75ac (HEAD, master) update code
* 5cec4ab update readme
* aea74a0 (tfs/default) update documentation
| * 44cd729 (tfs/featureA, featureA) Goodbye
| * d202b53 Branched from $/tfvc-test/Trunk
|/
* c403405 Hello
* b75da1a New projectŞ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).
PS> git tfs rcheckin
Working with tfs remote: default
Fetching changes from TFS to minimize possibility of late conflict...
Starting checkin of 5cec4ab4 'update readme'
add README.md
C20 = 71a5ddce274c19f8fdc322b4f165d93d89121017
Done with 5cec4ab4b213c354341f66c80cd650ab98dcf1ed, rebasing tail onto new TFS-commit...
Rebase done successfully.
Starting checkin of b1bf0f99 'update code'
edit .git\tfs\default\workspace\ConsoleApplication1/ConsoleApplication1/Program.cs
C21 = ff04e7c35dfbe6a8f94e782bf5e0031cee8d103b
Done with b1bf0f9977b2d48bad611ed4a03d3738df05ea5d, rebasing tail onto new TFS-commit...
Rebase done successfully.
No more to rcheckin.
PS> git log --all --oneline --graph --decorate
* ff04e7c (HEAD, tfs/default, master) update code
* 71a5ddc update readme
* aea74a0 update documentation
| * 44cd729 (tfs/featureA, featureA) Goodbye
| * d202b53 Branched from $/tfvc-test/Trunk
|/
* c403405 Hello
* b75da1a New projectHer 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:
PS> git tfs checkintool
PS> git tfs ctBiraz şö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:
PS> git tfs branch $/tfvc-test/featureBee
The name of the local branch will be : featureBee
C26 = 1d54865c397608c004a2cadce7296f5edc22a7e5
PS> git log --oneline --graph --decorate --all
* 1d54865 (tfs/featureBee) Creation branch $/myproject/featureBee
* ff04e7c (HEAD, tfs/default, master) update code
* 71a5ddc update readme
* aea74a0 update documentation
| * 44cd729 (tfs/featureA, featureA) Goodbye
| * d202b53 Branched from $/tfvc-test/Trunk
|/
* c403405 Hello
* b75da1a New projectTFVC’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).