Git vs Team Foundation Server [kapalı]

263

Git'i geliştirme ekibimle tanıştırdım ve benden başka herkes bundan nefret ediyor. Bunu Team Foundation Server ile değiştirmek istiyorlar. TFS'ye çok aşina olmasam da, bunun geriye doğru büyük bir adım olduğunu hissediyorum. Deneyimli bir kişi TFS'deki dallanma desteğini Git dallanma ile karşılaştırabilir mi? Ayrıca, genel olarak, TFS'nin artıları ve eksileri nelerdir? Git'i birkaç yıl kullandıktan sonra nefret edecek miyim?

git tfs tfvc

— Jacko
kaynak

24

Bu konuda yokuş yukarı bir savaşla karşı karşıyasınız. Git, Windows'ta svn / hg / tfs kadar olgun değil, git gazileri çok fazla rahatsız etmiyor, ancak yeni başlayanlar için büyük bir baş ağrısı.

— Marcelo Cantos

7

@Jacko: Son birkaç haftadır Windows için git'i değerlendiriyorum. Yaklaşık bir yıl önce baktığımdan bu yana belirgin bir şekilde iyileşmiş olsa da, tipik Windows geliştiricileriyle ilk kez hazır olmak için hala uzun bir yol var. Örneğin, VS eklentisi açıkçası kederli. Ana menü çubuğunun altında, bir proje yerine çözüm seçildiğinde sessizce başarısız olan bir grup menü seçeneğinden başka bir şey değildir. Ben git kullanmanın ana nedeni olan iri parça ve satırları indekslemek için taahhüt aracını alamıyorum ve git gui (bu tam bir zulüm, bir kullanılabilirlik POV gelen) almak en iyi ihtimalle garip.

— Marcelo Cantos

6

Yine de sana karşı dürüst olacağım; beni git bırakmam için öldürüyor. İkisinin eşit olduğu popüler görünümün aksine, git modelini çok daha güçlü ve mantıklı buluyorum. Mercurial'ın git'in indeksiyle eşleşecek hiçbir şeyi yok ve dallanma yaklaşımından nefret ediyorum. Git'in depolar arasında dolaştığınız ve depolar arasında senkronize ettiğiniz etiket kavramı çok zariftir. Mercurial'ın yer işaretleri yakın olan tek şey ve herkes için ayarlanacak bir PITA. Bununla birlikte, sonuçta, svn → Mercurial ile svn → git'e göre, personel ve araçların nispi olgunluğu göz önüne alındığında, başarı daha olasıdır.

— Marcelo Cantos

4

evet, Git güç ve zarafet söz konusu olduğunda karar verir. Ancak, herkes buna hazır değil.

— Jacko

7

@JamesReategui: Şahsen ( stackoverflow.com/a/11362998/520162 ) bir VCS'nin bir IDE'ye entegrasyonunun bir kıvrım olduğunu düşünüyorum . Yarın ana IDE'nizi değiştirip değiştirmediğinizi düşünün. Eclipse için VS'yi düşürürseniz ne olur? Gerçekten yeni bir VCS entegrasyonu öğrenmek istiyor musunuz ? Git komut satırında harika ( stackoverflow.com/a/5645910/520162 ). Öğrenin ve inanılmaz derecede güçlü bir sürüm kontrolü dünyası keşfedeceksiniz.

— eckes

273

Bence ifade

benden başka herkes nefret ediyor

daha fazla tartışma israfı yaratır: Git'i kullanmaya devam ettiğinizde, bir şeyler ters giderse sizi suçlarlar .

Bunun dışında Git benim için en çok takdir ettiğim merkezi bir VCS'ye göre iki avantajı var (kısmen Rob Sobers tarafından açıklandığı gibi ):

tüm deponun otomatik olarak yedeklenmesi: Birisi merkezi repodan her çekişinde, değişikliklerin tam geçmişini alır. Bir repo kaybolduğunda: endişelenmeyin, her iş istasyonunda bulunanlardan birini alın.
çevrimdışı Repo erişimi: Evde çalışıyorum (veya uçak veya tren içinde), İşe benim VPN bağlantısı başlatmadan, proje, her bir check dolu geçmişini görebilirsiniz ve ben gibi çalışabilir vardı iş yerinde : giriş, çıkış, şube, herhangi bir şey.

Ama dediğim gibi: Bence kayıp bir savaşta savaşıyorsunuz: herkes Git'ten nefret ettiğinde Git'i kullanma. Onları ikna etmeye çalışmak yerine Git'ten neden nefret ettiklerini bilmenize daha fazla yardımcı olabilir .

Eğer onlar bunu istemiyorlarsa, bu onlar için yenidir ve yeni bir şey öğrenmek istemiyorsa: bu kadro ile başarılı bir gelişme yapacağınızdan emin misiniz?

Gerçekten her insan Git'ten nefret mi ediyor, yoksa bazı fikir liderlerinden etkileniyor mu? Liderleri bulun ve onlara sorunun ne olduğunu sorun. Onları ikna edin, ekibin geri kalanını ikna edeceksiniz.

Liderleri ikna edemiyorsanız: Git'i kullanmayı unutun, TFS'yi alın. Hayatınızı kolaylaştıracak.

— Eckes
kaynak

22

Kes şunu, istekler. Bir şeyler ters gittiğinde beni suçluyorlar. Nasıl çalıştığını öğrenemedikleri için değil. Benim için Git, bir sürüm kontrol sisteminde deneyimlediğim kadar mükemmelliğe yakın.

— Jacko

15

Öte yandan TFS, kusur / iş öğesi takibi, raporlar, ... ve diğer işlevleri içerir. Bu yüzden Git vs TFS sadece VCS işlevselliğinde TFS'nin noktasını kaçırıyor.

— Richard

5

Rebase, filtre-ağacı görmek @Dan ...

— artefacto

7

@Artefacto biliyorum, ancak daha sonra tüm taahhüt etiketleri değişir ve tüm meta veriler (kod inceleme tartışmaları, vb.) Yetimdir veya güncellenmesi gerekir. Bununla birlikte, TFS ile bir ay, Git'in liginde bir sürüm kontrol sistemi olmadığı konusunda beni ikna etti. Git, geliştiriciyi anlaşılması için deneyimlenmesi gereken yollarla üretken olmaya özgür bırakır. Karalama defteri metaforu olarak şube güçlü kötü.

— Dan Solovay

6

@Richard Bunun TFS'nin bir dezavantajı olduğunu iddia ediyorum: bir kez girdiğinizde, hepsi içeride. Her şeyi vasat yapıyor ve size bu konuda bir seçenek sunmuyor. İş öğelerini, raporlamayı ve proje yönetimini izlemek için çok, çok daha iyi araçlar vardır.

— Ben Collins

102

İki sistem arasındaki temel fark TFS'nin merkezi bir sürüm kontrol sistemi ve Git'in dağıtılmış bir sürüm kontrol sistemi olmasıdır.

TFS ile depolar merkezi bir sunucuda depolanır ve geliştiriciler kodun belirli bir zamanda anlık görüntüsü olan çalışan bir kopyayı teslim alır . Git ile geliştiriciler, tüm tarih de dahil olmak üzere tüm veri havuzunu makinelerine kopyalar.

Tam deponun geliştiricinizin makinelerinde olmasının bir yararı, sunucunun ölmesi durumunda artıklıktır. Bir başka güzel yetenek ise, sunucunuzla konuşmadan çalışma kopyanızı revizyonlar arasında ileri geri hareket ettirebilmenizdir, bu da sunucu çalışmıyorsa veya erişilemiyorsa yardımcı olabilir.

Bana göre, gerçek nimet sen olmasıdır taahhüt hiç sunucuya konuşurken ya da (yani yapı kırma) ekibinizde potansiyel olarak istikrarsız değişiklikleri maruz kalmadan yerel havuzuna changesets.

Örneğin, büyük bir özellik üzerinde çalışıyorsam, kodlamam ve tamamen test etmem bir hafta sürebilir. Kararsız kodu hafta ortasında kontrol etmek ve yapıyı kırmak istemiyorum, ancak hafta sonuna yaklaştığımda ve yanlışlıkla tüm çalışma kopyamı doldurursam ne olur? Başından beri taahhütte bulunmazsam işimi kaybetme riski taşıyorum. Bu etkili bir sürüm kontrolü değildir ve TFS buna duyarlıdır.

DVCS ile, yapıyı bozma konusunda endişelenmeden sürekli taahhütte bulunabilirim, çünkü değişikliklerimi yerel olarak taahhüt ediyorum . TFS ve diğer merkezi sistemlerde yerel bir check-in konsepti yoktur.

DVCS'de daha iyi dallanma ve birleştirmenin ne kadar iyi olduğuna bile girmedim, ancak burada SO'da veya Google'da tonlarca açıklama bulabilirsiniz. TFS'de dallanma ve birleşmenin iyi olmadığını deneyimlerimden söyleyebilirim.

Kuruluşunuzdaki TFS'nin argümanı Windows'ta Git'ten daha iyi çalışıyorsa, Windows'ta harika çalışan Mercurial'ı öneririm - Windows Gezgini (TortoiseHg) ve Visual Studio (VisualHg) ile entegrasyon var.

— Rob Sobers
kaynak

5

Mercurial ile gitmeyi düşünüyorsanız, Joel Spolsky

— Martin Owen

3

Git'in merkezi bir sistemi taklit etme konusunda mükemmel bir kapasiteye sahip olduğunu ve tüm kullanıcılar için birincil bir git sunucusuna sahip olmanın yaygın olduğunu belirtmek gerekir , bunu bu şekilde yapmanız gerekmez.

— Tim Abell

7

diğer şeyleri kırabilecek bir işlevsellik üzerinde çalışıyorsanız - TFS'de bir şube oluşturamaz mısınız? Tabii ki - şube merkezi bir sunucuda - ama bu gerçekten önemli mi? Her ikisinde de aynı şeyi etkili bir şekilde yapabileceğiniz anlaşılıyor - hangi IDE'yi kullandığınıza ve sürüm kontrol sisteminin onunla ne kadar iyi entegre olduğuna dair bir soru gibi görünüyor -

— William

13

Ekibi kesintiye uğratabilecek büyük bir özellik üzerinde çalışıyorsanız, bir özellik dalı kullanmanız ve ardından hazır olduğunda geliştirme dalında birleşmeniz önerilir.

— Mike Cheel

9

@MikeCheel Bu harika bir yorum. Ayrıca her gün kodunuzun bir Rafını oluşturabilir ve nihayet özelliklerinizi kontrol ettiğinizde bunları silebilirsiniz (ancak dallanma fikri bunu yapmak için daha iyi bir yoldur)

— RPDeshaies

86

İnsanların silahı bırakmaları, çıkıntıdan uzaklaşmaları ve bir dakika düşünmeleri gerekiyor . DVCS'ye bir ekibin verimliliğinde BÜYÜK bir fark yaratacak objektif, somut ve inkar edilemez avantajlar olduğu ortaya çıkıyor.

Her şey Dallanma ve Birleşmeye gelir.

DVCS'den önce yol gösterici ilke "Dallanma ve birleşme içine girmeniz gerekmediği için Tanrı'ya dua edin. Ve eğer yaparsanız, en azından O'nun çok, çok basit olmasına izin vermesi için yalvarın."

Şimdi, DVCS ile dallanma ( ve birleştirme ) çok geliştirildi, yol gösterici prensip "Bir şapka düştüğünde yap. Size bir ton fayda sağlayacak ve size herhangi bir soruna neden olmayacak."

Ve bu, herhangi bir ekip için BÜYÜK bir verimlilik yükseltici.

Sorun, insanların söylediklerimi anlamaları ve bunun doğru olduğuna ikna olmaları için, önce biraz öğrenme eğrisine yatırım yapmaları gerektiğidir. Git'i veya başka bir DVCS'nin kendisini öğrenmek zorunda değiller ... sadece Git'in nasıl dallanma ve birleşme yaptığını öğrenmeleri gerekir. Bazı makaleleri ve blog yayınlarını okuyup tekrar okuyun, yavaşlayın ve görene kadar üzerinde çalışın. Bu, 2 veya 3 tam günün daha iyi kısmını alabilir.

Ancak bunu gördükten sonra, DVCS olmayan birini seçmeyi bile düşünmeyeceksiniz. Çünkü DVCS için gerçekten net, objektif, somut avantajlar vardır ve en büyük kazançlar dallanma ve birleşme alanındadır.

— Charlie Çiçek
kaynak

3

Teşekkürler, Charlie. Biliyorum ve bunu biliyorsunuz, ancak "kaynak kontrolünün Visual Studio ile entegrasyonu benim için en önemli özellik" diyen insanlara ulaşmak zor

— Jacko

58

Biliyorum. Bir arkadaşım ve ben bu benzetmeyi etrafa atıyorduk - ciddi bir ilişkisel veritabanına ihtiyacınız olduğunu düşünün. Sql Server, Oracle ve MS Access değerlendiriyorsunuz. Access'i seçersiniz, çünkü ölçeklenememesine, referans bütünlüğünü çok iyi uygulamamasına rağmen en güzel GUI'ye sahiptir. Dallanma ve Birleştirme, bir sürüm kontrol sisteminin mutlak et ve patatesidir. Diğer herhangi bir özellik yan tarafta sadece küçük bir bling. Ancak insanlar bling temelinde seçimler yapıyorlar.

— Charlie Flowers

17

İfadelerinize katılma eğilimindeyken, Git'in dallanma ve birleşmesinin neden sadece "dağıtılmış" bir sistem olduğu için "daha iyi" olduğunu anlamıyorum. DVCS olmanın birleştirme yeteneğiyle bir ilgisi olduğundan emin değilim. Dağıtılmış bir sistemde birleştirmenin neden daha kolay olduğunu açıklamak isterim. Öncelikle Git ve Svn olan deneyimlerime göre, SVN'de birleştirme, merkezi bir VCS olduğu için değil, GIT gibi şubelerdeki revizyonları düzgün bir şekilde izlemediği için korkunç.

— CodingWithSpike

8

@ rally25rs - Buna katılıyorum. Bir VCS'nin birleşmede de iyi olmasının bir nedeni yoktur. (Henüz bildiğim) henüz yok. Ama katılmıyorum kısmı "sadece çatışmaları daha iyi çözen daha iyi birleştirme rutinleri yazarak." Gizli sos, daha akıllı birleştirme rutinlerinde değil, repoda hangi bilgileri sakladığınıza ve nasıl düzenlediğinize temel olarak farklı bir yaklaşım benimsiyor. Esas olarak, Taahhütleri iç devletin temeli haline getirmek. Taahhütler sadece havalı bir cıvata değildir ... yeteneklerin temelidir.

— Charlie Flowers

10

@ rally25rs kesinlikle kabul eder: atom iş birimi olmayı taahhüt eder. Çoğu merkezi sistem, verileri bu şekilde organize etmekle kalmaz, aynı zamanda geliştiricilerin gerçekten iyi bir şube ve birleştirme çalışması yapmak için yapması gereken ani çalışmaları engeller. Dağıtılmış sistemler, "uygun" taahhütlerimi (bağımsız, iyi tanımlarla ilgili işin küçük taahhütleri) dediğim şeyi teşvik eder ve merkezi sistemler, hazır oluncaya kadar bir mağarada patladığınız ve günleri bırakana kadar "fark bombaları" dediğim şeyi teşvik eder (veya hafta) sistem üzerinde çalışmaya değer. Hangi türün en iyi birleştiğini tahmin edin?

— Ben Collins

45

Orijinal : @Rob, TFS'de " konusundaki endişenizi gideren Raflar " olarak . Merkezi sürüm kontrolünü bir engel olarak gördüğünüzün farkındayım, ancak TFS ile ilgili olarak, kodunuzu rafa kontrol etmek bir güç b / c olarak görüntülenebilir, daha sonra merkezi sunucu nadir olayda devam eden çalışmanızın bir kopyasına sahiptir. yerel makineniz çöker veya kaybolur / çalınır veya vitesleri hızlıca değiştirmeniz gerekir. Demek istediğim, TFS'ye bu alanda uygun övgü verilmesi gerektiğidir. Ayrıca, TFS2010'da dallanma ve birleştirme önceki sürümlerden geliştirildi ve "... TFS'de dallanma ve birleştirmenin iyi olmadığı deneyiminden" söz ettiğinizde hangi sürüme başvurduğunuz açık değil. Yasal Uyarı: TFS2010'un orta kullanıcısıyım.

Edit Dec-5-2011 : , TFS hakkında beni rahatsız eden bir şey, üzerinde çalışmadığınız zamanlarda tüm yerel dosyalarınızı "salt okunur" olarak ayarlaması konusunda ısrar . Değişiklik yapmak istiyorsanız, akış, TFS'nin dosyaya göz kulak olmasını bilmesi için dosyadaki salt okunur özniteliği temizleyen dosyayı "teslim almanız" gerektiğidir. Bu uygunsuz bir iş akışı. Çalışmasını tercih edeceğim yol, bir değişiklik yaptım ve dosya öznitelikleri ile hiç endişe / rahatsızlık yoksa otomatik olarak algılar olmasıdır. Bu şekilde, dosyayı Visual Studio veya Not Defteri'nde veya istediğim herhangi bir araçla değiştirebilirim. Versiyon kontrol sistemi bu açıdan mümkün olduğunca şeffaf olmalıdır. Windows Gezgini Uzantısı var ( TFS PowerTools), Windows Gezgini'nde dosyalarınızla çalışmanıza olanak tanır, ancak bu iş akışını çok basitleştirmez.

— Lee Grissom
kaynak

2

Bu soruya cevap verir, temsilcisi olsanız bile bir yorum olmamalıdır.

— SingleNegationElimination

8

FYI - TFS "11" artık varsayılan olan yerel çalışma alanlarını kullanıyorsanız artık salt okunur bit gerektirmez. Herhangi bir uygulamadan hangi dosyaların değiştirildiğini akıllıca keşfeder. Brian Harry'nin buradaki gelişmeler hakkında daha fazla bilgi var: blogs.msdn.com/b/bharry/archive/2011/08/02/…

— Ed Blankenship

2

@EdBlankenship, bu blog bağlantısı için çok teşekkür ederim. Bu, TFS'nin sonraki sürümünü kullanmayı kolaylaştırmak için salt okunur bit saçmalıklarının ele alındığını görmek için mükemmel bir haber.

— Lee Grissom

7

Git'te yaptığınız gibi bir dalda işlemenin aksine, rafları anlamak ve yönetmek kolay değildir. Rafların yapıldığı her bir taahhütte bilmiyorsunuz ve genellikle birleştirme ile ilgili sorunlarınız var (o zamandan beri değişiklikler yaptıysanız, genellikle kaybolurlar). Git şubesi raflardan çok daha güçlü ve anlaşılır. Raf, başka bir şey yaşamamış geliştiriciler içindir ....

— Philippe

2

Bir dosyayı 'teslim alma' iş akışı, Visual SourceSafe'i hatırlatır, çünkü bu ortak çalışma yoludur; dosyalar SourceSafe'den alındı ve yerel olarak salt okunur dosyalar olarak saklandı. Bir dosyayı veya bir grup dosyayı teslim almak özel olarak işaretlenebilir; başka bir deyişle, başka bir geliştiricinin üzerinde çalıştığı dosya kümesini görebilir; sağ domuz).

— Brett Rigby

18

Söylenen her şeyin üstünde (

https://stackoverflow.com/a/4416666/172109

https://stackoverflow.com/a/4894099/172109

https://stackoverflow.com/a/4415234/172109

) doğru olan TFS yalnızca bir VCS değildir. TFS'nin sağladığı önemli özelliklerden biri, yerel olarak entegre edilmiş hata izleme işlevselliğidir. Değişiklik kümeleri sorunlarla bağlantılıdır ve izlenebilir. Check-in'lerle ilgili çeşitli politikaların yanı sıra TFS çalıştıran kişilerin sahip olduğu Windows etki alanıyla entegrasyon da desteklenmektedir. Visual Studio ile sıkı bir şekilde entegre edilmiş GUI, ~~ortalama~~ fare ve tıklama geliştiricisinden ve menajerinden ~~daha azına~~ hitap eden başka bir satış noktasıdır .

Dolayısıyla Git'i TFS ile karşılaştırmak sormak için uygun bir soru değildir. Doğru değil, pratik olsa da, Git'i TFS'nin sadece VCS işlevselliği ile karşılaştırmak. Böylece Git, TFS'yi sudan üfler. Bununla birlikte, herhangi bir ciddi takımın başka araçlara ihtiyacı vardır ve burası TFS'nin tek bir durak hedefi sağladığı yerdir.

— Sherlock
kaynak

4

Lütfen TFS'nin sağladığı aynı araçları çevik takım uygulamalarında da alabilirsiniz. Ralli, adını siz koyun.

— PositiveGuy

2

TFS'nin daha geniş bir hedefi olduğu gerçeğini kabul etsem de, bunu "tek noktadan hedef sağlamak için ÇALIŞIYOR" olarak yeniden ifade ederdim, ancak yapmaya çalıştığı görevlerin hiçbirinde yeterince iyi değil (en azından en iyi seçenek yok) çözmek; yani kör bir İsviçre bıçağı gibi.

— slashCoder

@PositiveGuy iş ve yapılandırma olmadan alamazsınız. TFS size her şeyi tek bir tıklamayla verir. Durumda, ekosistemin tamamı artık sıfır yapılandırması gereken bir bulut hizmeti olarak kullanılabilir. Sürüm kontrolü, scrum desteği, otomatik yapımlar, test laboratuarı ve test planı yönetimi alabilirsem, hepsi kendileriyle kutudan entegre olur VE kurumsal bir LDAP (yalan AzureAD), 10 $ / ay için, neden sağ aklımda gideyim parçaları kendi başıma yapıştırmaya mı çalışıyorsunuz?

— Craig Brunetti

1

@slashCoder herhangi bir süitin her parçada en iyi olması nasıl beklenebilir? En iyi edimsizliğinin maliyeti, bileşenlerin entegrasyonunu kendi başınıza yönetmek zorunda kalmanın maliyetinden daha ağır mı? ... belki de bazı yerler için bunu görebiliyorum. Ancak bu tür şeyleri yürütmek saf bir yük. Kurumsal GIT'niz iyi çalışıyorsa, ancak JIRA örneğiniz azalır ve Jenkins yükseltmeniz uçmazsa ne olur? Sağ? Motorlu testere hokkabazlığı gibi. Yanıyor. Yarı gözleri. :) :)

— Craig Brunetti

17

Ekibiniz TFS kullanıyorsa ve Git'i kullanmak istiyorsanız "git to tfs" köprüsünü düşünebilirsiniz. Esasen bilgisayarınızda Git'i kullanarak her gün çalışırsınız, daha sonra değişikliklerinizi aktarmak istediğinizde TFS sunucusuna gönderirsiniz.

Orada (github üzerinde) bir çift var. Son yerimde (başka bir geliştiriciyle birlikte) bir miktar başarı ile kullandım. Görmek:

https://github.com/spraints/git-tfs

https://github.com/git-tfs/git-tfs

— bytedev
kaynak

6

Microsoft şimdi Git depoları ve TFS ile doğrudan bir entegrasyon sağlıyor: blogs.msdn.com/b/bharry/archive/2012/08/13/…

— Ed Blankenship

1

@EdBlankenship, yorumunuzu bir cevaba dönüştürmek isteyebilirsiniz. OP için harika bir çözüm gibi görünüyor. Oy vereceğim. :)

— Lee Grissom

1

Windows dışında başka bir platformdaysanız, git-tfs'yi tercih etmelisiniz! git-tf git-tfs kadar iyi olmaktan uzaktır ... Ve felsefe TFS yönelimlidir, git-tfs ise daha git yönelimlidir (ve istediğimiz de budur!)

— Philippe

15

Profesyoneller ve eksiler arasındaki bazı araştırmalardan sonra, dahil olduğum şirket de TFS'ye gitmeye karar verdi. GIT iyi bir sürüm kontrol sistemi olmadığı için değil, en önemlisi TFS'nin sunduğu tam entegre ALM çözümü için. Yalnızca sürüm kontrolü özelliği önemliyse, seçim muhtemelen GIT olabilir. Bununla birlikte, düzenli geliştiriciler için dik GIT öğrenme eğrisi göz ardı edilemez.

Gerçek bir çapraz teknoloji platformu olarak TFS blog yayınımda ayrıntılı bir açıklama görün .

— Pieter Gheysens
kaynak

3

Belki de, TFS'nin her bir parçasının yönetimi kötü ve zordur (aslında, TFS için gerçek bir yöneticiye ihtiyacınız vardır). Git> TFS (VCS), Jenkins> TFS (CI), nunit veya xunit> ilk, IceScrum veya ...> TFS (Proje Yönetimi). Kullanana kadar TFS başlangıçta iyi bir fikirdir !!!

— Philippe

1

Neden TFS'ye ihtiyacınız var, sadece iyi bir çevik uygulama edinin. Ve sonra Git'i veya yıkımı kullanın ve yolunuza devam edin. TFS sizi problemlerle boğarak yoluna giriyor.

— PositiveGuy

Güncelleme: TFS 2013 (sunucu) [ve VS12-13) artık sürüm kontrolü için git'i destekliyor. Böylece her iki dünyanın en iyisini elde edebilirsiniz

— DarcyThomas

2

Elbette, tamamen entegre bir ALM'ye sahip olmak güzel. Ancak esneklik pahasına değil. IMO. bir ALM mümkün olduğunca çok "türün en iyisi" teknolojisi ile inşa edilmelidir ... ya da en azından, zaman içinde değişme olasılığı yüksek olan ırkların en iyilerini entegre etme esnekliği. TFS'yi seçmek, temelde "microsoft ALM'imin tüm yönleriyle kazanacak" diyerek, bir çığır açıyor. Mesela Git'i wira ile kullandım. Deneyimlerime göre (TFS ile de bol), bu çok üstün bir iş akışı.

— Scott Silvi

1

Kenar çubuğu - TFS / Git entegrasyonu ile bile, temelde "sorun izlememizi korurken VCS'yi Git'e izin verir" - temel olarak Git'i diğer sorun izleme yazılımlarıyla kullanmaktan farklı değildir. Bu nedenle, Microsofts'un esneklik girişimleri (alkışladığım) göz önüne alındığında, ALM argümanının artık geçerli olduğundan emin değilim.

— Scott Silvi

14

Git'in tüm Dağıtılmış şey gerçekten harika. Raf setlerinin yerel geri alma ve taahhüt seçenekleri ( Eclipse'nin yerel geçmişi özelliği gibi) gibi (mevcut üründe) sahip olmadığı birkaç özellik sunar . Bunu geliştirici dallarını kullanarak hafifletebilirsiniz, ancak dürüst olalım, birçok geliştirici dallamayı ve birleştirmeyi sevmiyor. Birkaç kez çok sık TFS eski stil "özel ödeme" özelliğini açmak istendi (ve her zaman reddedildi).

Birçok büyük işletmenin, bir geliştiricinin tüm tarihi yerel bir çalışma alanına getirmesine ve onlarla birlikte (örneğin yeni bir işverene) götürmesine izin vermekten oldukça korktuğunu düşünüyorum ... Anlık görüntü çalmak kötüdür, ancak tüm tarihi ortadan kaldırır daha da zahmetlidir. (İstediğiniz TFS'den tam bir tarih alamadığınız için değil ) ...

Orijinal sürdürücünün bakımını durdurabileceği ve sürümünü kaldırabileceği açık kaynak için tekrar harika olan yedekleme için harika bir yol olduğu belirtiliyor, ancak bir kurumsal plan için bu, birçok işletme için açık bir sorumluluk atamadığı için tekrar yetersiz kalıyor yedek tutmak için. Ve ana 'proje' bir şekilde kaybolursa hangi sürümü kullanacağını bulmak zor olurdu. Hangi bir depo önde / merkezi olarak atamak eğilimindedir.

Git hakkında en çok sevdiğim şey, taahhüt haklarına sahip olmak zorunda kalmadan bir projeye kolayca kod ekleyebileceğiniz Push / Pull seçeneğidir. Sanırım bunu taklit etmek için TFS'de çok sınırlı kullanıcıları ve raf setlerini kullanabilirsiniz, ancak Git seçeneği kadar güçlü değildir. Ekip projeleri arasında dallanma da işe yarayabilir, ancak takım projeleri eklemek çok fazla idari yük eklediğinden, birçok kuruluş için idari açıdan gerçekten uygun değildir.

Ayrıca kaynak dışı kontrol alanında bahsedilen şeylere de eklemek istiyorum. İş Öğesi Takibi, Raporlama ve Derleme Otomasyonu (laboratuvar yönetimi dahil) gibi özellikler merkezi bir lider depodan büyük ölçüde yararlanır. Saf bir dağıtılmış model kullandığınızda, düğümlerden birini önde yapmazsanız (ve böylece daha az dağıtılmış bir modele geri dönmezseniz) bunlar çok daha zor hale gelir.

TFS Basic'in TFS 11 ile gelmesiyle, yerel TFS temelinizi TFS 12+ döneminde merkezi bir TFS ile senkronize etmenizi sağlayan dağıtılmış bir TFS beklemek çok uzak olmayabilir. Bunun için oyumu uservoice'ye koyacağım !

— jessehouwing
kaynak

Ayrıca Microsoft'un size getirdiği bu yeni özellikle de ilgileneceksiniz: gittf.codeplex.com

— jessehouwing

1

git-tfs kullanın. Şu an için git-tf'den daha iyi !!! github.com/git-tfs/git-tfs

— Philippe

3

Bu cevabın tamamı hızla tükeniyor. Microsoft, Team Foundation Service'e Git desteğini ekledi ve Team Foundation Server'ın bir sonraki büyük sürümüne Git için destek ekleyecek.

— jessehouwing

1

@Philippe: İkisini de denedim. Birkaç fark: 1) git-tf platformlar arasıyken, git-tfs sadece Windows üzerinde çalışır. 2) git-tfs, değişiklik kümesi numarasını eklemek için "bastığınızda" komut açıklamalarını yeniden yazar, oysa git-tf yerel komut karmalarını olduğu gibi bırakır.

— Joey Adams

@JoeyAdams 1) +1, git-tf 2'yi seçmenin tek iyi nedeni budur) Bunu git-tfs ile checkinkomut (rcheckin yerine) kullanarak da yapabilirsiniz . Ama rcheckin'i tercih ediyorum çünkü bir şeyler yapmak için daha çok git yolu ve bu yüzden git'i kullanmayı seçiyoruz;)

— Philippe

9

Benim için en büyük fark, TFS'nin TFS'yi 'desteklemek' için çözümünüze (.vssscc) ekleyeceği tüm yardımcı dosyalar - bu dosyalar ile ilgili yanlış şubeye eşlenen ve bazı ilginç hata ayıklamalarına yol açan son sorunlarla karşılaştık ...

— çeltik
kaynak

2

Burada iyi bir nokta. Git, .gittüm depo ayrıntılarını izlemek için klasörü ekler . TFS , uzak deponun konumunu içine yerleştirmek için en azından dosyalarınızı değiştirir .sln(ya da .csproj?).

— CodingWithSpike

5

VSS'nin dosyalarınızı 'sizin için' nasıl değiştireceğinden nefret etmek için ne kadar kullandığımı unutmuştum.

— Çeltik