Git vs Team Foundation Server [ditutup]

263

Saya memperkenalkan Git ke tim dev saya, dan semua orang membencinya kecuali saya. Mereka ingin menggantinya dengan Team Foundation Server. Saya merasa ini adalah langkah mundur yang besar, meskipun saya tidak terlalu mengenal TFS. Dapatkah seseorang dengan pengalaman membandingkan dukungan percabangan pada percabangan TFS ke Git? Juga, secara umum, apa pro dan kontra dari TFS? Apakah saya akan membencinya setelah menggunakan Git selama beberapa tahun?

git tfs tfvc Jacko
sumber
24
Anda menghadapi perjuangan yang berat untuk yang satu ini. Git sama sekali tidak matang seperti svn / hg / tfs di Windows, yang tidak terlalu mengganggu git veteran, tetapi merupakan sakit kepala utama bagi pendatang baru.
Marcelo Cantos
7
@ Jacko: Saya telah mengevaluasi git-untuk-Windows selama beberapa minggu terakhir. Meskipun sudah sangat membaik sejak saya terakhir melihatnya sekitar setahun yang lalu, masih jauh siap untuk prime time dengan pengembang Windows yang khas. Misalnya, plugin VS terus terang menyedihkan. Itu tidak lain hanyalah sekelompok pilihan menu di bawah bilah menu utama, yang secara diam-diam gagal jika solusi dipilih alih-alih proyek. Saya tidak bisa mendapatkan alat komit untuk mengindeks bongkahan dan garis, yang merupakan alasan utama saya menggunakan git, dan mendapatkan ke git gui (yang merupakan kekejaman lengkap, dari POV kegunaan) canggung di terbaik.
Marcelo Cantos
6
Saya akan jujur ​​dengan Anda, meskipun; itu membunuhku untuk menjatuhkan git. Bertentangan dengan pandangan populer di luar sana bahwa keduanya setara, saya menemukan model git jauh lebih kuat dan logis. Mercurial tidak ada yang cocok dengan indeks git, dan saya benci pendekatannya terhadap percabangan. Konsep label Git yang Anda jalani dan selaraskan di antara repo sangat elegan. Bookmark Mercurial adalah satu-satunya hal yang mendekati dan mereka PITA untuk mengatur untuk semua orang. Namun, intinya adalah bahwa keberhasilan lebih mungkin terjadi dengan svn → Mercurial daripada svn → git, mengingat staf dan kematangan relatif dari alat-alat tersebut.
Marcelo Cantos
4
ya, Git berkuasa dalam hal kekuatan dan keanggunan. Tapi, tidak semua orang siap untuk itu.
Jacko
7
@JamesReategui: Saya pribadi berpikir ( stackoverflow.com/a/11362998/520162 ) bahwa integrasi VCS dalam IDE adalah berliku-liku. Bayangkan jika Anda mengganti IDE utama Anda besok. Bagaimana jika Anda menjatuhkan VS untuk Eclipse? Apakah Anda benar-benar mau belajar integrasi VCS baru? Git bagus di baris perintah ( stackoverflow.com/a/5645910/520162 ). Pelajari dan Anda akan menemukan dunia kontrol versi yang sangat kuat.
eckes

Jawaban:

273

Saya pikir, pernyataan itu

semua orang membencinya kecuali aku

membuat diskusi lebih lanjut menjadi sia-sia: ketika Anda terus menggunakan Git, mereka akan menyalahkan Anda jika ada masalah.

Terlepas dari ini, bagi saya Git memiliki dua keunggulan dibandingkan VCS terpusat yang paling saya hargai (seperti dijelaskan oleh Rob Sobers ):

  • backup otomatis seluruh repo: setiap kali seseorang menarik dari repo pusat, dia mendapat sejarah penuh dari perubahan. Ketika satu repo hilang: jangan khawatir, ambillah salah satu yang hadir di setiap stasiun kerja.
  • akses repo secara offline: ketika saya sedang bekerja di rumah (atau di pesawat atau kereta), saya bisa melihat sejarah penuh proyek, setiap checkin tunggal, tanpa memulai koneksi VPN saya untuk bekerja dan dapat bekerja seperti saya berada di tempat kerja : lapor masuk, checkout, cabang, apa pun.

Tapi seperti yang saya katakan: Saya pikir Anda bertarung dalam pertempuran yang hilang: ketika semua orang membenci Git, jangan gunakan Git. Ini bisa membantu Anda lebih tahu mengapa mereka membenci Git daripada mencoba meyakinkan mereka.

Jika mereka tidak menginginkannya karena itu baru bagi mereka dan tidak mau belajar sesuatu yang baru: apakah Anda yakin bahwa Anda akan melakukan pengembangan yang sukses dengan staf itu?

Apakah benar-benar setiap orang membenci Git atau mereka dipengaruhi oleh beberapa pemimpin opini? Temukan para pemimpin dan tanyakan kepada mereka apa masalahnya. Yakinkan mereka dan Anda akan meyakinkan anggota tim lainnya.

Jika Anda tidak dapat meyakinkan para pemimpin: lupakan tentang menggunakan Git, ambil TFS. Akan membuat hidup Anda lebih mudah.

eek
sumber
22
Bang on, eeckes. Mereka menyalahkan saya setiap kali terjadi kesalahan. Bukan diri mereka sendiri karena gagal mempelajari cara kerjanya. Bagi saya, Git sedekat dengan kesempurnaan seperti yang pernah saya alami dalam sistem kontrol versi.
Jacko
15
Di sisi lain TFS mencakup pelacakan cacat / benda kerja, pelaporan, ... dan fungsi lainnya. Jadi Git vs TFS hanya pada fungsionalitas VCS agak kehilangan titik TFS.
Richard
5
@Dan lihat rebase, filter-tree ...
Artefacto
7
@Artefacto saya tahu, tetapi kemudian semua tag commit berubah, dan semua metadata (diskusi tinjauan kode, dll.) Menjadi yatim piatu atau perlu diperbarui. Namun demikian, sebulan dengan TFS telah meyakinkan saya bahwa itu bukan di liga Git sebagai sistem kontrol versi. Git membebaskan pengembang untuk menjadi produktif dengan cara yang harus dialami untuk dipahami. Cabang sebagai metafora pad awal adalah jahat kuat.
Dan Solovay
6
@ Richard Saya berpendapat bahwa itu adalah kerugian TFS: begitu Anda masuk, Anda semua masuk. Itu melakukan segalanya biasa-biasa saja dan tidak memberi Anda pilihan tentang itu. Ada jauh, alat yang jauh lebih baik untuk melacak item pekerjaan, pelaporan, dan manajemen proyek.
Ben Collins
102

Perbedaan utama antara kedua sistem adalah bahwa TFS adalah sistem kontrol versi terpusat dan Git adalah sistem kontrol versi terdistribusi.

Dengan TFS, repositori disimpan di server pusat dan pengembang memeriksa salinan yang berfungsi, yang merupakan snapshot dari kode pada titik waktu tertentu. Dengan Git, pengembang mengkloning seluruh repositori ke mesin mereka, termasuk semua riwayat.

Salah satu manfaat memiliki repositori lengkap pada mesin pengembang Anda adalah redundansi seandainya server mati. Kegembiraan lain yang bagus adalah bahwa Anda dapat memindahkan copy pekerjaan Anda bolak-balik antara revisi tanpa pernah berbicara dengan server, yang dapat membantu jika server sedang down atau hanya tidak terjangkau.

Bagi saya, keuntungan sebenarnya adalah Anda dapat melakukan perubahan pada repositori lokal Anda tanpa pernah berbicara dengan server atau menyebabkan perubahan yang berpotensi tidak stabil pada tim Anda (yaitu, merusak build).

Misalnya, jika saya sedang mengerjakan fitur besar, mungkin perlu waktu seminggu untuk membuat kode dan mengujinya sepenuhnya. Saya tidak ingin melakukan check-in kode tidak stabil pada pertengahan minggu dan memecah bangunan, tetapi apa yang terjadi jika saya mendekati akhir minggu dan saya secara tidak sengaja merusak seluruh copy pekerjaan saya? Jika saya tidak melakukan semua selama ini saya berisiko kehilangan pekerjaan saya. Itu bukan kontrol versi yang efektif, dan TFS rentan terhadap ini.

Dengan DVCS, saya bisa berkomitmen terus-menerus tanpa khawatir akan merusak pembangunan, karena saya melakukan perubahan saya secara lokal . Di TFS dan sistem terpusat lainnya tidak ada konsep check-in lokal.

Saya bahkan belum membahas seberapa jauh percabangan dan penggabungan yang lebih baik dalam DVCS, tetapi Anda dapat menemukan banyak penjelasan di sini di SO atau melalui Google. Saya dapat memberitahu Anda dari pengalaman bahwa bercabang dan bergabung dalam TFS tidak baik.

Jika argumen untuk TFS di organisasi Anda adalah bahwa ia bekerja lebih baik di Windows daripada Git, saya sarankan Mercurial, yang bekerja sangat baik pada Windows - ada integrasi dengan Windows Explorer (TortoiseHg) dan Visual Studio (VisualHg).

Rob Sobers
sumber
5
Jika Anda berpikir tentang pergi dengan Mercurial, Joel Spolsky memiliki situs tutorial yang sangat baik untuk mendidik tim Anda: hginit.com
Martin Owen
3
Mungkin perlu disebutkan bahwa git sangat mampu meniru sistem terpusat, dan itu umum untuk memiliki server git primer untuk semua pengguna, Anda hanya tidak harus melakukannya dengan cara itu.
Tim Abell
7
jika Anda mengerjakan sebagian fungsionalitas yang dapat merusak hal lain - tidak bisakah Anda membuat cabang di TFS? Tentu - cabang ada di server pusat - tetapi apakah itu penting? Sepertinya Anda dapat secara efektif melakukan hal yang sama pada keduanya - sepertinya lebih merupakan pertanyaan tentang IDE mana yang Anda gunakan dan seberapa baik integrasi sistem kontrol versi dengannya -
William
13
Jika Anda bekerja pada fitur besar yang berpotensi dapat mengganggu tim, disarankan untuk menggunakan cabang fitur dan kemudian ketika siap bergabung ke dalam cabang pengembangan.
Mike Cheel
9
@MikeCheel Ini adalah komentar yang bagus. Anda juga dapat membuat Shelve dari kode Anda setiap hari dan menghapusnya ketika Anda akhirnya memeriksa fitur Anda (tetapi ide percabangan adalah cara yang lebih baik untuk melakukannya)
RPDeshaies
86

Orang-orang perlu meletakkan pistol, menjauh dari langkan, dan berpikir sebentar. Ternyata ada keuntungan obyektif, konkret, dan tak terbantahkan untuk DVCS yang akan membuat perbedaan besar dalam produktivitas tim.

Semuanya bermuara pada Percabangan dan Penggabungan.

Sebelum DVCS, prinsip panduannya adalah "Berdoalah kepada Tuhan agar Anda tidak harus masuk ke percabangan dan penggabungan. Dan jika Anda melakukannya, setidaknya memohon kepada-Nya untuk membiarkannya menjadi sangat, sangat sederhana."

Sekarang, dengan DVCS, percabangan ( dan penggabungan ) jauh lebih baik, prinsip panduannya adalah, "Lakukan dengan mudah. ​​Ini akan memberi Anda banyak manfaat dan tidak menimbulkan masalah bagi Anda."

Dan itu adalah penguat produktivitas BESAR untuk tim mana pun.

Masalahnya adalah, agar orang mengerti apa yang baru saja saya katakan dan diyakinkan bahwa itu benar, pertama-tama mereka harus berinvestasi dalam sedikit kurva pembelajaran. Mereka tidak harus belajar Git atau DVCS lain itu sendiri ... mereka hanya perlu belajar bagaimana Git bercabang dan bergabung. Baca dan baca kembali beberapa artikel dan posting blog, lakukan dengan lambat, dan kerjakan sampai Anda melihatnya. Itu mungkin memakan waktu 2 atau 3 hari penuh.

Tetapi begitu Anda melihatnya, Anda bahkan tidak akan mempertimbangkan untuk memilih non-DVCS. Karena memang ada keuntungan nyata yang jelas, objektif, dan nyata bagi DVCS, dan kemenangan terbesar adalah di bidang percabangan dan penggabungan.

Charlie Flowers
sumber
3
Terima kasih, Charlie. Saya tahu itu, dan Anda tahu itu, tetapi sulit untuk menghubungi orang-orang yang mengatakan hal-hal seperti "integrasi kontrol sumber dengan Visual Studio adalah fitur yang paling penting bagi saya"
Jacko
58
Aku tahu. Seorang teman dan saya melemparkan analogi ini - bayangkan Anda membutuhkan database relasional yang serius. Anda mengevaluasi Sql Server, Oracle, dan MS Access. Anda akhirnya memilih Access karena memiliki GUI terbaik, terlepas dari kenyataan bahwa ia tidak dapat skala, tidak menegakkan integritas referensial dengan sangat baik, dll. Bercabang dan Menggabungkan adalah daging dan kentang mutlak dari sistem kontrol versi. Fitur lain hanya sedikit bling di samping. Tetapi orang-orang membuat pilihan berdasarkan bling.
Charlie Flowers
17
Walaupun saya cenderung setuju dengan pernyataan Anda, saya tidak melihat mengapa percabangan dan penggabungan Git "lebih baik" hanya karena itu adalah sistem "terdistribusi". Saya tidak yakin menjadi DVCS ada hubungannya dengan kemampuannya untuk bergabung. Saya ingin penjelasan mengapa penggabungan lebih mudah dalam sistem terdistribusi. Dalam pengalaman saya, yang terutama Git dan Svn, bergabung dalam SVN mengerikan bukan karena itu adalah VCS terpusat, tetapi karena itu tidak melacak revisi di seluruh cabang seperti GIT.
CodingWithSpike
8
@ rally25rs - Saya setuju dengan sebagian besar dari itu. Tidak ada alasan VCS tidak bisa pandai menggabungkan juga. Hanya belum ada (yang saya tahu). Tetapi bagian yang saya tidak setuju adalah "murni dengan menulis rutinitas penggabungan yang lebih baik yang menyelesaikan konflik dengan lebih baik." Saus rahasia tidak dalam rutinitas penggabungan yang lebih baik-pintar, tetapi dalam mengambil pendekatan yang berbeda secara mendasar terhadap informasi apa yang Anda simpan di dalam repo dan bagaimana Anda mengaturnya. Terutama, menjadikan Komit sebagai dasar dari keadaan internal. Komit bukan hanya baut-on keren ... mereka adalah dasar dari kemampuan.
Charlie Flowers
10
@ rally25rs setuju sepenuhnya: berkomitmen menjadi unit kerja atom. Tidak hanya sebagian besar sistem terpusat tidak mengorganisasikan data dengan cara ini, tetapi mereka juga mencegah jenis pekerjaan dari waktu ke waktu yang harus dilakukan pengembang untuk membuat pekerjaan cabang dan penggabungan yang benar-benar bagus. Sistem terdistribusi mendorong apa yang saya sebut komitmen "sepantasnya" (mandiri, komitmen kecil dari pekerjaan yang relevan dengan deskripsi yang baik) dan sistem terpusat mendorong apa yang saya sebut "bom beda" di mana Anda berlubang di sebuah gua sampai Anda siap dan kemudian melepas hari (atau minggu) senilai bekerja pada sistem. Coba tebak jenis mana yang paling cocok?
Ben Collins
45

Asli : @Rob, TFS memiliki sesuatu yang disebut " Shelving " yang membahas kekhawatiran Anda tentang melakukan pekerjaan dalam proses tanpa memengaruhi bangunan resmi. Saya menyadari Anda melihat kontrol versi pusat sebagai penghalang, tetapi sehubungan dengan TFS, memeriksa kode Anda di rak dapat dilihat sebagai kekuatan b / c maka server pusat memiliki salinan pekerjaan Anda yang sedang berjalan dalam acara langka mesin lokal Anda rusak atau hilang / dicuri atau Anda harus mengganti persneling dengan cepat. Maksud saya adalah bahwa TFS harus diberi pujian yang tepat di bidang ini. Selain itu, bercabang dan bergabung dalam TFS2010 telah ditingkatkan dari versi sebelumnya, dan tidak jelas versi apa yang Anda maksud ketika Anda mengatakan "... dari pengalaman bahwa bercabang dan bergabung dalam TFS tidak baik." Penafian: Saya pengguna moderat TFS2010.

Sunting Dec-5-2011 : Untuk OP, satu hal yang mengganggu saya tentang TFS adalah bahwa ia bersikeras mengatur semua file lokal Anda menjadi "hanya-baca" ketika Anda tidak mengerjakannya. Jika Anda ingin melakukan perubahan, alurnya adalah Anda harus "memeriksa" file tersebut, yang hanya menghapus atribut readonly pada file sehingga TFS tahu untuk mengawasinya. Itu alur kerja yang tidak nyaman. Cara saya lebih suka untuk bekerja adalah yang hanya secara otomatis mendeteksi jika saya telah membuat perubahan dan tidak khawatir / repot dengan atribut file sama sekali. Dengan begitu, saya dapat memodifikasi file di Visual Studio, atau Notepad, atau dengan alat apa pun yang saya suka. Sistem kontrol versi harus setransparan mungkin dalam hal ini. Ada Ekstensi Windows Explorer ( TFS PowerTools) yang memungkinkan Anda untuk bekerja dengan file Anda di Windows Explorer, tetapi itu tidak menyederhanakan alur kerja.

Lee Grissom
sumber
2
Ini menjawab pertanyaan, itu seharusnya bukan komentar, bahkan jika Anda memiliki perwakilan.
SingleNegationElimination
8
FYI - TFS "11" tidak memerlukan bit read-only lagi jika Anda menggunakan ruang kerja lokal yang merupakan default sekarang. Dengan cerdas menemukan file apa yang diubah dari aplikasi apa pun. Brian Harry memiliki beberapa informasi lebih lanjut tentang perbaikan di sini: blogs.msdn.com/b/bharry/archive/2011/08/02/…
Ed Blankenship
2
@ EdBlankenship, terima kasih banyak untuk tautan blog itu. Itu adalah berita bagus untuk melihat bahwa bit-read-only sedang ditangani untuk membuat menggunakan versi TFS berikutnya menjadi lebih mudah.
Lee Grissom
7
Berlawanan dengan komitmen di cabang seperti yang Anda lakukan dengan Git, rak tidak mudah dipahami dan dikelola. Anda tidak tahu di setiap komit bahwa rak dibuat dan Anda sering memiliki masalah dengan penggabungan (jika sejak saat itu melakukan modifikasi, mereka sering hilang). Cabang Git jauh lebih kuat dan mudah dipahami daripada rak. Rak adalah untuk para pengembang yang tidak pernah mengalami hal lain ....
Philippe
2
Alur kerja 'memeriksa-keluar' file ini mengingatkan pada Visual SourceSafe, karena ini adalah cara kerja yang umum; file diambil dari SourceSafe dan disimpan secara lokal sebagai file hanya-baca. Memeriksa file, atau banyak file, dapat ditandai sebagai eksklusif, artinya orang lain dapat melihat set file yang sedang dikerjakan dev lain, untuk mencegah perlunya penggabungan saat percabangan dinonaktifkan (mungkin karena menjadi babi yang tepat dalam VSS).
Brett Rigby
18

Di atas semua yang dikatakan (

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

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

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

), yang benar, TFS bukan hanya VCS. Salah satu fitur utama yang disediakan TFS adalah fungsi pelacakan bug yang terintegrasi secara asli. Perubahan terkait dengan masalah dan bisa dilacak. Berbagai kebijakan untuk lapor masuk didukung, serta integrasi dengan domain Windows, yang dimiliki oleh orang yang menjalankan TFS. GUI terintegrasi dengan Visual Studio adalah titik penjualan lain, yang menarik bagi pengembang mouse dan klik yang kurang dari rata-rata dan manajernya.

Oleh karena itu membandingkan Git dengan TFS bukanlah pertanyaan yang tepat untuk ditanyakan. Pertanyaan yang benar, meskipun tidak praktis, adalah untuk membandingkan Git dengan fungsionalitas VCS TFS saja. Saat itu, Git meniup TFS keluar dari air. Namun, tim mana pun yang serius membutuhkan alat lain dan ini adalah tempat TFS menyediakan destinasi terpadu.

Sherlock
sumber
4
Silakan Anda bisa mendapatkan alat yang sama yang disediakan TFS dalam aplikasi alat tangkas mana pun. Rally, sebutkan saja.
PositiveGuy
2
Meskipun saya setuju pada kenyataan bahwa TFS memiliki tujuan yang lebih luas, saya akan mengubah kata menjadi "itu MENCOBA untuk memberikan tujuan satu atap", tetapi itu tidak cukup baik (setidaknya tidak ada pilihan terbaik) dalam salah satu tugas yang dicoba untuk memecahkan; jadi itu seperti pisau Swiss tumpul.
slashCoder
@PositiveGuy Anda tidak bisa mendapatkannya tanpa kerja dan konfigurasi. TFS memberi Anda semuanya dengan satu klik. Contoh kasus, seluruh ekosistem sekarang tersedia sebagai layanan cloud, dengan nol konfigurasi. Jika saya bisa mendapatkan kontrol versi, dukungan scrum, build otomatis, lab pengujian dan manajemen rencana pengujian, semuanya terintegrasi di luar kotak dengan mereka sendiri DAN LDAP perusahaan (bohong AzureAD), sebesar $ 10 / bln, mengapa saya berpikiran waras mencoba menempelkan potongan sendiri?
Craig Brunetti
1
@ slashCoder bagaimana mungkin suite lengkap diharapkan menjadi yang terbaik di setiap bagian? Apakah biaya non-best-ed-ness benar-benar lebih besar daripada biaya untuk mengelola integrasi komponen sendiri? ... mungkin untuk beberapa tempat, saya bisa melihatnya. Tapi itu murni overhead harus menjalankan hal-hal seperti itu. Apa yang terjadi jika GIT perusahaan Anda berjalan dengan baik, tetapi instance JIRA Anda turun, dan pemutakhiran Jenkins Anda tidak terbang? Baik? Ini seperti gergaji juggling. Semangat. Semi-ditutup matanya. :) :)
Craig Brunetti
17

Jika tim Anda menggunakan TFS dan Anda ingin menggunakan Git, Anda mungkin ingin mempertimbangkan jembatan "git to tfs". Pada dasarnya Anda bekerja sehari-hari menggunakan Git di komputer Anda, maka ketika Anda ingin mendorong perubahan Anda mendorongnya ke server TFS.

Ada pasangan di luar sana (di github). Saya menggunakan satu di tempat terakhir saya (bersama dengan pengembang lain) dengan beberapa keberhasilan. Lihat:

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

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

bytedev
sumber
6
Microsoft menyediakan integrasi langsung dengan repositori Git dan TFS sekarang: blogs.msdn.com/b/bharry/archive/2012/08/13/…
Ed Blankenship
1
@ EdBlankenship, Anda mungkin ingin mengonversi komentar Anda menjadi jawaban. Tampaknya menjadi solusi hebat untuk OP. Saya akan memilihnya. :)
Lee Grissom
1
Kecuali jika Anda menggunakan platform lain selain Windows, Anda sebaiknya memilih git-tfs! git-tf jauh dari sama baiknya dengan git-tfs ... Dan filosofi ini berorientasi pada TFS sementara git-tfs lebih berorientasi git (dan itulah yang kami inginkan!)
Philippe
15

Setelah beberapa penyelidikan antara pro dan kontra, perusahaan tempat saya terlibat juga memutuskan untuk menggunakan TFS. Bukan karena GIT bukan sistem kontrol versi yang baik, tetapi yang paling penting untuk solusi ALM terintegrasi penuh yang TFS berikan. Jika hanya fitur kontrol versi yang penting, pilihannya mungkin GIT. Kurva pembelajaran GIT yang curam untuk pengembang reguler mungkin tidak dapat diremehkan.

Lihat penjelasan terperinci di posting blog saya TFS sebagai platform lintas teknologi yang sebenarnya .

Pieter Gheysens
sumber
3
Mungkin, tetapi setiap bagian dari TFS buruk dan sulit untuk diadministrasikan (pada kenyataannya, Anda memerlukan administrator untuk TFS). Lihat Git> TFS (VCS), Jenkins> TFS (CI), nunit atau xunit> mstest, IceScrum atau ...> TFS (Manajemen Proyek). TFS adalah ide yang bagus di awal, sampai Anda menggunakannya !!!
Philippe
1
mengapa Anda membutuhkan TFS, cukup dapatkan aplikasi gesit yang baik. Dan kemudian gunakan Git atau subversi dan Anda berada di jalan Anda. TFS hanya menghalangi Anda dengan menghalangi Anda dengan masalah.
PositiveGuy
Pembaruan: TFS 2013 (server) [dan VS12-13) sekarang mendukung git untuk kontrol versi. Jadi Anda bisa mendapatkan yang terbaik dari kedua dunia
DarcyThomas
2
Tentu, senang memiliki ALM yang terintegrasi penuh. Tetapi tidak dengan mengorbankan fleksibilitas. IMO. ALM harus dibangun dengan sebanyak mungkin teknologi "terbaik berkembang biak" ... atau paling tidak, fleksibilitas untuk mengintegrasikan yang terbaik dari breed, karena mereka cenderung berubah seiring waktu. Memilih TFS pada dasarnya menempatkan taruhan di tanah, mengatakan "microsoft akan menang di semua aspek ALM saya", yang konyol. Saya telah menggunakan Git dengan Jira, misalnya, yang memungkinkan saya untuk memperbarui / menutup masalah berdasarkan pesan komit saya. Dalam pengalaman saya (banyak dengan TFS juga), ini adalah alur kerja yang jauh lebih unggul.
Scott Silvi
1
Bilah samping - bahkan dengan integrasi TFS / Git, Anda pada dasarnya mengatakan "mari keluar dari VCS ke Git, sambil menjaga pelacakan masalah kami" - pada dasarnya tidak berbeda dengan menggunakan Git dengan perangkat lunak pelacakan masalah lainnya. Jadi saya tidak yakin argumen ALM valid lagi, mengingat upaya Microsoft pada fleksibilitas (yang saya salut).
Scott Silvi
14

Seluruh hal yang didistribusikan Git benar-benar hebat. itu memberikan beberapa fitur yang tidak dimiliki Shelvesets (dalam produk saat ini) seperti rollback lokal dan opsi komit (seperti fitur sejarah lokal Eclipse ). Anda dapat meringankan ini menggunakan cabang pengembang, tetapi mari kita jujur, banyak pengembang tidak suka bercabang dan menggabungkan sedikit pun. Saya telah diminta untuk mengaktifkan fitur "checkout eksklusif" gaya lama di TFS beberapa kali terlalu sering (dan setiap kali ditolak).

Saya pikir banyak perusahaan besar cukup takut untuk membiarkan seorang dev hanya membawa seluruh sejarah ke dalam ruang kerja lokal dan membawanya bersama mereka (ke majikan baru misalnya) ... Mencuri foto adalah buruk, tetapi mengambil seluruh sejarah bahkan lebih merepotkan. (Bukannya Anda tidak bisa mendapatkan riwayat lengkap dari TFS yang Anda inginkan) ...

Disebutkan bahwa ini adalah cara yang bagus untuk mencadangkan, yang bagus untuk open source lagi di mana pengelola asli mungkin berhenti untuk peduli dan menghapus versinya, tetapi untuk rencana perusahaan ini lagi gagal untuk banyak perusahaan karena tidak ada penugasan tanggung jawab yang jelas untuk menyimpan cadangan. Dan akan sulit untuk mengetahui versi mana yang digunakan jika 'proyek' utama menghilang entah bagaimana. Yang cenderung menunjuk satu repositori sebagai pemimpin / pusat.

Apa yang paling saya sukai dari Git adalah opsi Push / Pull, di mana Anda dapat dengan mudah menyumbangkan kode ke suatu proyek tanpa perlu memiliki hak komit. Saya kira Anda bisa menggunakan pengguna dan rak yang sangat terbatas di TFS untuk meniru ini, tetapi tidak sekuat opsi Git. Bercabang di proyek-proyek tim mungkin juga berhasil, tetapi dari perspektif administrasi, hal itu tidak benar-benar layak bagi banyak organisasi karena menambahkan proyek tim menambah banyak overhead administrasi.

Saya juga ingin menambahkan hal-hal yang disebutkan di area kendali non-sumber. Fitur-fitur seperti Pelacakan Item Kerja, Pelaporan dan Otomasi Bangun (termasuk manajemen lab) sangat diuntungkan dari repositori terkemuka pusat. Ini menjadi jauh lebih sulit ketika Anda menggunakan model terdistribusi murni, kecuali jika Anda membuat salah satu node terkemuka (dan dengan demikian kembali ke model yang kurang terdistribusi).

Dengan TFS Basic hadir dengan TFS 11, mungkin tidak jauh untuk mengharapkan TFS terdistribusi yang memungkinkan Anda untuk menyinkronkan dasar TFS lokal Anda ke TFS pusat di era TFS 12+. Saya akan menempatkan suara saya untuk itu di bawahmisalnya !

jessehouwing
sumber
Anda juga akan tertarik dengan fitur baru ini yang dipersembahkan oleh Microsoft kepada Anda: gittf.codeplex.com
jessehouwing
1
gunakan git-tfs. Untuk saat ini, jauh lebih baik daripada git-tf !!! github.com/git-tfs/git-tfs
Philippe
3
Seluruh jawaban ini cepat ketinggalan jaman. Microsoft telah menambahkan dukungan Git ke Layanan Team Foundation dan akan menambahkan dukungan untuk Git ke rilis utama berikutnya dari Team Foundation Server.
jessehouwing
1
@ Pilipe: Saya sudah mencoba keduanya. Beberapa perbedaan: 1) git-tf adalah cross-platform, sedangkan git-tfs hanya berjalan di Windows. 2) git-tfs menulis ulang komit ketika Anda "mendorong" untuk memasukkan nomor ubah, sedangkan git-tf membiarkan hash komit lokal Anda tetap utuh.
Joey Adams
@ JoeyAdams 1) +1, itulah satu-satunya alasan bagus untuk memilih git-tf 2) Anda juga bisa melakukannya dengan git-tfs menggunakan checkinperintah (bukan rcheckin). Tetapi saya lebih suka rcheckin karena ini lebih merupakan cara git untuk melakukan sesuatu dan itulah mengapa kami memilih untuk menggunakan git;)
Philippe
9

Bagi saya perbedaan utama adalah semua file tambahan yang akan ditambahkan TFS ke solusi Anda (.vssscc) ke 'dukungan' TFS - kami memiliki masalah baru-baru ini dengan file-file ini berakhir dipetakan ke cabang yang salah, yang mengarah ke beberapa debugging yang menarik ...

Padi
sumber
2
Poin bagus di sini. Git akan menambahkan .gitfolder untuk melacak semua detail repositori. TFS setidaknya akan memodifikasi file Anda .sln(atau apakah itu .csproj?) Untuk meletakkan lokasi repositori jarak jauh ke dalamnya.
CodingWithSpike
5
Saya lupa betapa saya dulu benci bagaimana VSS akan memodifikasi file Anda 'untuk' Anda.
Padi