Git vs Team Foundation Server [закрито]

263

Я представив Git своїй команді розробників, і всі ненавидять його, крім мене. Вони хочуть замінити його на Team Foundation Server. Я відчуваю, що це величезний крок назад, хоча я не дуже знайомий з TFS. Чи може хтось із досвідом порівняти підтримку розгалуження на TFS з гіткою Git? Також, загалом, які плюси і мінуси TFS? Невже я ненавиджу його після використання Git протягом декількох років?

git  tfs  tfvc 
— Яко
джерело
24
На цьому ви стикаєтеся з важким боєм. Git ніде не є такою зрілою, як svn / hg / tfs в Windows, що не дуже турбує ветеранів git, але є головним болем для новачків.
— Марсело Кантос
7
@Jacko: Останні кілька тижнів я оцінював git-for-Windows. Незважаючи на те, що він помітно покращився з моменту останнього перегляду цього року близько року тому, все ще далеко не бути готовим до пройм-тайму з типовими розробниками Windows. Наприклад, плагін VS відверто жахливий. Це не що інше, як безліч параметрів меню під основним рядком меню, які мовчки виходять з ладу, якщо рішення вибирається замість проекту. Я не можу отримати інструмент фіксації для індексації перегонів та ліній, що є основною причиною використання git, а потрапляння до git gui (що є повною жорстокістю від POV зручності використання) в кращому випадку незручно.
— Марсело Кантос
6
Я з тобою чесно кажу; це вбиває мене, щоб кинути git. На відміну від загальноприйнятої думки про те, що вони стоять нарівні, я вважаю, що модель git є набагато більш потужною та логічною. У Mercurial нічого не відповідає індексу git, і я ненавиджу його підхід до розгалуження. Концепція етикетки Git, яку ви переміщуєте та синхронізуєте між репост, дуже елегантна. Закладки Mercurial - це єдине, що наближається, і вони є PITA, який слід створити для всіх. Суть, однак, полягає в тому, що успіх швидше стосується svn → Mercurial, ніж svn → git, враховуючи штат та відносну зрілість інструментів.
— Марсело Кантос
4
так, Git править, коли мова йде про силу та елегантність. Але, не всі готові до цього.
— Jacko
7
@JamesReategui: Я особисто думаю ( stackoverflow.com/a/11362998/520162 ), що інтеграція VCS в IDE є меандром. Уявіть, чи завтра ви переключите основний IDE. Що робити, якщо ви кинете VS для Eclipse? Ви дійсно готові навчитися новій інтеграції VCS? Git чудовий у командному рядку ( stackoverflow.com/a/5645910/520162 ). Дізнайтеся це, і ви відкриєте для себе неймовірно потужний світ управління версіями.
— eckes

Відповіді:

273

Я думаю, заява

всі ненавидять його, крім мене

будь-яка подальша дискусія марнує: коли ви продовжуєте використовувати Git, вони звинувачуватимуть вас, якщо щось піде не так.

Крім цього, для мене Git має дві переваги перед централізованою системою VCS, яку я найбільше ціную (як частково описав Роб Соберс ):

  • автоматичне резервне копіювання всього репо: кожного разу, коли хтось витягує з центрального репо, він / вона отримує повну історію змін. Коли одна репо загубиться: не хвилюйтесь, приймайте когось із присутніх на кожній робочій станції.
  • офлайн-доступ до репо: коли я працюю вдома (або в літаку чи поїзді), я бачу повну історію проекту, кожну перевірку, не запускаючи VPN-з'єднання на роботу і можу працювати так, як я був на роботі : реєстрація, каса, відділення, що завгодно.

Але як я вже сказав: я думаю, що ти ведеш програний бій: коли всі ненавидять Git, не використовуй Git. Це може допомогти вам більше зрозуміти, чому вони ненавидять Гіта, а не намагатися їх переконати.

Якщо вони просто не хочуть цього, бо це для них нове і не готові дізнатися щось нове: ви впевнені, що будете робити успішний розвиток з цим персоналом?

Чи насправді кожна людина ненавидить Git чи на них впливають деякі лідери думок? Знайдіть лідерів і запитайте, в чому проблема. Переконайте їх, і ви переконаєте решту команди.

Якщо ви не можете переконати лідерів: забудьте про використання Git, візьміть TFS. Полегшить ваше життя.

— eckes
джерело
22
Вибух, eckes. Вони звинувачують мене, коли щось піде не так. Не самі за те, що вони не дізналися, як це працює. Для мене Git настільки ж близький до досконалості, як я коли-небудь відчував у системі управління версіями.
— Jacko
15
З іншого боку, TFS включає відстеження дефектів / робочих елементів, звітів, ... та інші функції. Тож лише у Git та TFS щодо функціональності VCS досить не вистачає точки TFS.
— Річард
5
@Dan see rebase, filter filter ...
— Artefacto
7
@Artefacto Я знаю, але тоді всі теги фіксування змінюються, і всі метадані (обговорення коду та ін.) Осиротіли або потребують оновлення. Тим не менш, місяць з TFS переконав мене, що він не в лізі Гіта як система контролю версій. Git позбавляє розробника бути продуктивним способами, які повинні бути досвідченими, щоб їх зрозуміти. Гілка, як метафора подряпини, злісно потужна.
— Дан Соловай
6
@ Richard Я б заперечував, що це мінус TFS: як тільки ти входиш, ти все працюєш. Це робить усе посередньо і не дає тобі вибору з цього приводу. Існують набагато кращі інструменти для відстеження робочих позицій, звітності та управління проектами.
— Бен Коллінз
102

Ключова відмінність між двома системами полягає в тому, що TFS є централізованою системою управління версіями, а Git - розподіленою системою управління версіями.

З TFS сховища зберігаються на центральному сервері, а розробники перевіряють робочу копію, яка є знімком коду в певний момент часу. За допомогою Git розробники клонують весь сховище до своїх машин, включаючи всю історію.

Однією з переваг наявності повного сховища на машинах розробника є надмірність у випадку загибелі сервера. Ще одна приємна вигода полягає в тому, що ви можете переміщати робочу копію назад і назад між редакціями, не розмовляючи ніколи з сервером, що може бути корисно, якщо сервер не працює або просто недоступний.

Для мене справжньою користю є те, що ви можете здійснювати набори змін у вашому локальному сховищі, не розмовляючи ніколи з сервером або завдаючи потенційно нестабільних змін вашій команді (тобто, порушуючи збірку).

Наприклад, якщо я працюю над великою функцією, може знадобитися тиждень, щоб кодувати і протестувати її повністю. Я не хочу зареєструвати нестабільний код у середині тижня і розірвати збірку, але що станеться, якщо я наближаюся до кінця тижня і випадково зірвую всю свою робочу копію? Якщо я не займався всіма зобов'язаннями, я ризикую втратити роботу. Це не є ефективним контролем версій, і TFS сприйнятливий до цього.

За допомогою DVCS я можу постійно виконувати завдання, не переживаючи про порушення збірки, оскільки я ввожу свої зміни на місцевому рівні . У TFS та інших централізованих системах відсутня концепція місцевої реєстрації.

Я навіть не розглядав, наскільки краще розгалуження та злиття є у DVCS, але ви можете знайти багато пояснень тут на SO або через Google. Я можу вам сказати з досвіду, що розгалуження та об'єднання в TFS - це не добре.

Якщо аргументом для TFS у вашій організації є те, що він працює краще в Windows, ніж Git, я б запропонував Mercurial, який чудово працює в Windows - є інтеграція з Windows Explorer (TortoiseHg) і Visual Studio (VisualHg).

— Роб Соберс
джерело
5
Якщо ви думаєте про співпрацю з Меркуріалом, Джоел Спольський має чудовий сайт підручників для навчання вашої команди: hginit.com
— Мартін Оуен
3
Можливо, варто згадати, що git цілком здатний наслідувати централізовану систему, і звичайно мати первинний сервер git для всіх користувачів, просто не потрібно робити це таким чином.
— Тім Абелл
7
якщо ви працюєте над функцією, яка може порушити інші речі - ви не могли просто створити гілку в TFS? Звичайно - гілка знаходиться на центральному сервері - але чи це насправді має значення? Здається, ви можете ефективно робити те саме в обох - це, здається, більше питання про те, яку IDE ви використовуєте та наскільки добре інтегрована система управління версіями,
— Вільям
13
Якщо ви працюєте над великою функцією, яка потенційно може перервати команду, рекомендується використовувати функціональну гілку, а потім, коли будете готові зливатися в гілку розвитку.
— Майк Чіл
9
@MikeCheel Це чудовий коментар. Ви також можете створити полицю свого коду щодня і видалити їх, коли остаточно зареєструєте свою функцію (але ідея розгалуження - це кращий спосіб зробити це)
— RPDeshaies
86

Людям потрібно скласти пістолет, відійти від виступу і подумати хвилину. Виявляється, є об'єктивні, конкретні та незаперечні переваги для DVCS, які зроблять ВЕЛИЧЕЗНУ різницю у продуктивності команди.

Все зводиться до розгалуження та об'єднання.

Перед DVCS керівним принципом було: "Моліться Бога, щоб вам не довелося вступати у розгалуження та злиття. І якщо ви це зробите, принаймні благайте Його, щоб він був дуже-дуже простим".

Тепер, завдяки DVCS, розгалуження ( і злиття ) настільки вдосконалено, керівним принципом є: "Зробіть це при краплі капелюха. Це дасть тону переваг і не доставить вам ніяких проблем".

І це ВЕЛИЧЕЗНИЙ підвищення продуктивності для будь-якої команди.

Проблема полягає в тому, щоб люди зрозуміли, що я щойно сказав, і переконалися, що це правда, вони повинні спочатку інвестувати у криву навчання. Їм не доведеться самостійно вивчати Git або будь-який інший DVCS ... їм просто потрібно дізнатися, як Git робить розгалуження та злиття. Читайте та перечитуйте деякі статті та публікації в блогах, запускаючи їх повільно, і працюйте через них, поки не побачите. Це може зайняти більшу частину 2 або 3 повних днів.

Але як тільки ви це побачите, ви навіть не будете розглядати питання про вибір не DVCS. Тому що дійсно є чіткі, об'єктивні, конкретні переваги DVCS, а найбільші виграші - у галузі розгалуження та об’єднання.

— Чарлі Квіти
джерело
3
Спасибі, Чарлі. Я це знаю, і ви це знаєте, але важко проникнути до людей, які говорять про такі речі, як "інтеграція керування джерелами з Visual Studio - для мене найважливіша особливість"
— Jacko
58
Я знаю. Ми з другом кидали цю аналогію - уявіть, вам потрібна серйозна реляційна база даних. Ви оцінюєте сервер Sql, Oracle та MS Access. Ви в кінцевому підсумку вибираєте Access, оскільки він має найкращий графічний інтерфейс, незважаючи на те, що він не може масштабувати, не застосовує референтну цілісність дуже добре і т.д. Будь-яка інша особливість - це лише трохи баламучення. Але люди роблять вибір на основі bling.
— Charlie Flowers
17
Хоча я схильний погоджуватися з вашими твердженнями, я не бачу, чому розгалуження та злиття Гіта "краще" лише тому, що це "розподілена" система. Я не впевнений, що бути DVCS має щось спільне з його здатністю до злиття. Я хотів би пояснити, чому об’єднуватись в розподіленій системі простіше. На мій досвід, який в першу чергу є Git і Svn, злиття в SVN жахливо не тому, що це централізований VCS, а тому, що воно не відстежує належним чином ревізії в галузях, як це робить GIT.
— CodingWithSpike
8
@ rally25rs - Я згоден з більшою частиною цього. Немає причини, що VCS теж не може бути злиденним. Просто їх ще немає (про що я знаю). Але частина, з якою я не згоден, - це "суто написання кращих процедур об'єднання, які краще вирішували конфлікти". Таємний соус полягає не в кращих розумніших процедурах злиття, а в принципово іншому підході до того, яку інформацію ви зберігаєте в репо і як ви її організовуєте. В основному, прийняття комітетів основою внутрішнього стану. Коміти - це не просто крутий підйом… вони є основою можливостей.
— Charlie Flowers
10
@ rally25rs повністю згоден щодо: зобов'язується бути атомною одиницею роботи. Більшість централізованих систем не тільки не організовують дані таким чином, але й перешкоджають поточній роботі, яку розробники повинні виконати, щоб зробити дійсно гарну роботу з фіксації та об'єднання. Розподілені системи спонукають до того, що я називаю "підходящими" вчинками (автономні, невеликі комісії відповідної роботи з хорошими описами), а централізовані системи заохочують те, що я називаю "різними бомбами", де ви прориваєтесь у печері, поки ви не будете готові, а потім залишите дні (або тижнів) варто працювати над системою. Відгадайте, який вид зливається найкраще?
— Бен Коллінз
45

Оригінал : @Rob, TFS має щось, що називається " Стелажі ", яке вирішує вашу проблему щодо зайняття незавершеного виробництва, не впливаючи на офіційну збірку. Я усвідомлюю, що ви бачите керування центральною версією як перешкоду, але щодо TFS перевірка коду на полиці може розглядатися як міцність, тоді центральний сервер має копію вашої незавершеної роботи в рідкісних подіях ваша локальна машина виходить з ладу або втрачається / викрадається або вам потрібно швидко перемикати передачі. Я мою думку про те, що TFS слід гідно оцінити в цій галузі. Крім того, розгалуження та злиття в TFS2010 було вдосконалено з попередніх версій, і незрозуміло, до якої версії ви звертаєтесь, коли ви говорите "... з досвіду, що розгалуження та об'єднання в TFS не є хорошим". Відмова: Я помірний користувач TFS2010.

Редагувати 5 грудня 2011 р .: Для ОП одне, що мене турбує щодо TFS, - це те, що він наполягає на встановленні всіх локальних файлів на "лише для читання", коли ви не працюєте над ними. Якщо ви хочете внести зміни, потік полягає в тому, що ви повинні "перевірити" файл, який просто очищає атрибут readonly у файлі, щоб TFS знав, як слідкувати за ним. Це незручний робочий процес. Я б хотів, щоб він працював, це те, що він автоматично автоматично визначає, чи я змінив, і зовсім не хвилюється / не турбується з атрибутами файлів. Таким чином я можу змінити файл або в Visual Studio, або в Блокноті, або будь-яким інструментом, який мені подобається. Система управління версіями повинна бути максимально прозорою в цьому плані. Є розширення Windows Explorer ( TFS PowerTools), що дозволяє працювати з файлами в Windows Explorer, але це не дуже спрощує робочий процес.

— Лі Гріссом
джерело
2
Це відповідає на питання, це не повинно бути коментарем, навіть якщо у вас був представник.
— SingleNegationElimination
8
FYI - TFS "11" більше не вимагає біт для читання, якщо ви використовуєте локальні робочі простори, що є типовим для теперішнього часу. Він розумно виявляє, які файли змінюються з будь-якої програми. Брайан Гаррі має додаткову інформацію про вдосконалення тут: blogs.msdn.com/b/bharry/archive/2011/08/02/…
— Ед
2
@EdBlankenship, дуже дякую за те посилання на блог. Це відмінна новина про те, що розслідування бітів лише для читання розглядаються, щоб зробити використання наступної версії TFS набагато простіше.
— Лі Гріссом
7
На відміну від зобов'язань у такій галузі, як ви робите з Git, стелажі не просто зрозуміти та керувати ними. Ви не знаєте, що на кожній комісії стелаж був зроблений, і у вас часто виникають проблеми зі злиттям (якщо ви з тих пір вносили модифікації, вони часто втрачаються). Гіткові гілки набагато потужніші і зрозуміліші, ніж стелажі. Стелаж призначений для розробників, які ніколи іншого не відчували ....
— Філіппе
2
Цей робочий процес "перевірки" файлу нагадує Visual SourceSafe, оскільки це був звичайний спосіб роботи; Файли були отримані з SourceSafe та зберігалися локально як файли лише для читання. Перевірка файлу чи купи файлів може бути позначена як ексклюзивна, це означає, що інші могли бачити набір файлів, над якими працює інший розробник, щоб запобігти необхідності злиття, коли відгалуження було відключено (можливо, через те, що права свиня у ВСС).
— Бретт Рігбі
18

На додаток до всього сказаного (

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

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

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

), що правильно, TFS - це не просто VCS. Однією з головних особливостей, яку надає TFS, є функціональне відстеження помилок. Набори змін пов'язані з проблемами і їх можна відстежити. Підтримуються різні політики щодо реєстрації, а також інтеграція з доменом Windows. Це люди, які управляють TFS. Щільно інтегрований графічний інтерфейс із Visual Studio - ще одна точка продажу, яка звертається до менш ніж середнього показника миші та розробників кліків та його менеджера.

Отже, порівнювати Git з TFS не є правильним питанням. Правильним, хоч і непрактичним, питанням є порівняння Git із лише функціональністю VCS TFS. При цьому Гіт видуває TFS з води. Однак будь-якій серйозній команді потрібні інші інструменти, і саме тут TFS забезпечує єдине місце зупинки.

— Шерлок
джерело
4
Будь ласка, ви можете отримати ті самі інструменти, які надає TFS у будь-якому спритному застосуванні інструментів. З'їзд, ти його називаєш.
— PositiveGuy
2
Хоча я згоден у тому, що TFS має більш широку мету, я б переформулював це у "СТОРІННЯ, щоб забезпечити єдине місце призначення", але це недостатньо добре (принаймні, не найкращий варіант) у будь-якому із завдань, які він намагається вирішувати; тож це як тупий швейцарський ніж.
— slashCoder
@PositiveGuy ви не можете отримати його без роботи та конфігурації. TFS дає вам всю справу одним клацанням. Насправді, вся екосистема тепер доступна як хмарна послуга, нульова конфігурація не потрібна. Якщо я можу отримати контроль над версіями, підтримку scrum, автоматизовані побудови, тестування лабораторії та управління тестовим планом, все інтегровано з коробки з собою та корпоративним LDAP (брехня AzureAD), за 10 доларів на місяць, чому я з розумом пішов би намагаюся самостійно вставити шматки?
— Крейг Брунетті
1
@slashCoder: як можна очікувати, що будь-який повний набір буде найкращим у кожному творі? Чи дійсно вартість його не найкращої редакції перевищує витрати на необхідність самостійно керувати інтеграцією компонентів? ... можливо, в деяких місцях це відбувається, я це бачу. Але чисто керувати такими справами треба. Що станеться, якщо ваш корпоративний GIT працює нормально, але ваш примірник JIRA знижується, а оновлення Jenkins не пролетить? Правильно? Це як жонглювання бензопилами. У вогні. Напівзаплющені. :) :)
— Крейг Брунетті
17

Якщо ваша команда використовує TFS і ви хочете використовувати Git, ви можете розглянути міст "git to tfs". По суті, ви працюєте щодня, використовуючи Git на своєму комп’ютері, тоді, коли ви хочете натиснути свої зміни, ви пересунете їх на сервер TFS.

Там пара (на github). Я використав його на останньому місці (разом з іншим розробником) з деяким успіхом. Побачити:

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

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

— бидєдєв
джерело
6
Microsoft надає пряму інтеграцію із сховищами Git та TFS зараз: blogs.msdn.com/b/bharry/archive/2012/08/13/…
— Ед
1
@EdBlankenship, ви можете перетворити свій коментар у відповідь. Це здається чудовим рішенням для ОП. Я за це проголосую. :)
— Лі Гріссом
1
За винятком випадків, якщо ви перебуваєте на іншій платформі, ніж Windows, вам слід віддати перевагу git-tfs! git-tf далеко не такий хороший, як git-tfs ... І філософія орієнтована на TFS, тоді як git-tfs орієнтована більше на git (і це те, що ми хочемо!)
— Philippe
15

Після деякого розслідування між «за» і «проти», компанія, з якою я брав участь, також вирішила піти на TFS. Не тому, що GIT не є хорошою системою управління версіями, а головне для повністю інтегрованого рішення ALM, яке постачає TFS. Якщо важлива лише функція контролю версій, вибір, можливо, був GIT. Однак стрімка крива навчання GIT для звичайних розробників може бути недооцінена.

Дивіться детальне пояснення в моєму блозі TFS як справжню платформу між технологіями .

— Пітер Гейсенс
джерело
3
Можливо, але кожну частину TFS погано і важко адмініструвати (адже вам потрібен справжній адміністратор для TFS). Подивіться Git> TFS (VCS), Jenkins> TFS (CI), nunit або xunit> mstest, IceScrum або ...> TFS (Управління проектами). TFS - це гарна ідея на початку, доки не використаєте її !!!
— Філіп
1
навіщо вам потрібен TFS, просто отримайте хороший спритний додаток. А потім скористайтеся Git або subversion і ви вже на шляху. TFS просто перешкоджає вам загрожувати проблемами.
— PositiveGuy
Оновлення: TFS 2013 (сервер) [і VS12-13) тепер підтримує git для контролю версій. Тож ви можете отримати найкраще з обох світів
— DarcyThomas
2
Звичайно, приємно мати повністю інтегрований ALM. Але не за рахунок гнучкості. ІМО. ALM повинен бути побудований з якомога більше технологій "кращої породи" ... або, принаймні, гнучкістю до інтеграції найкращих порід, оскільки вони, ймовірно, з часом змінюватимуться. Вибір TFS - це, в основному, ставка на землю, кажучи, що "мікрософт збирається виграти в усіх аспектах мого ALM", що нерозумно. Наприклад, я використовував Git w / Jira, який дозволив мені оновлювати / закривати проблеми на основі мого повідомлення про фіксацію. На мій досвід (достатньо і для TFS), це надзвичайно чудовий робочий процес.
— Скотт Сільві
1
Бічна панель - навіть при інтеграції з TFS / Git, ви, по суті, говорите: "дозволяє виводити VCS на Git, зберігаючи наше відстеження проблем" - принципово не відрізняється від використання Git w / будь-якого іншого програмного забезпечення для відстеження випусків. Тому я не впевнений, що аргумент ALM вже не дійсний, враховуючи спроби Microsofts щодо гнучкості (що я аплодую).
— Скотт Сільві
14

Вся розподілена річ Git насправді чудова. Це дає декілька можливостей, у яких Shelvesets не має (у поточному продукті), таких як локальний відкат та параметри фіксації (наприклад , локальна історія Eclipse ). Ви можете полегшити це за допомогою гілок розробників, але, якщо чесно, багато розробників не люблять розгалуження та об'єднання одного біта. Мене попросили ввімкнути функцію "ексклюзивного оформлення замовлення" в TFS кілька разів занадто часто (і відмовляти її щоразу).

Я думаю, що багато великих підприємств досить бояться, щоб дозволити розробнику просто перенести всю історію в локальну робочу область і взяти її з собою (наприклад, новому роботодавцю) ... Красти знімок - це погано, але забирати всю історію ще більш клопітно. (Не те, щоб ти не зміг отримати повну історію з TFS, про який ти хотів) ...

Зазначається, що це чудовий спосіб резервного копіювання, який чудово підходить для відкритого коду знову, коли оригінальний сервіс може перестати піклуватися і видаляє його версію, але для плану підприємства це знову не вистачає для багатьох підприємств, оскільки чіткого розподілу відповідальності немає. зберегти резервні копії. І важко було б розібратися, яку версію використовувати, якщо головний «проект» якось зникає. Яке схильне призначити одне сховище як провідне / центральне.

Що найбільше мені подобається в Git, це варіант Push / Pull, де ви можете легко вносити код до проекту без необхідності мати права на комісію. Я думаю, що ви можете використовувати дуже обмежених користувачів та полиці в TFS, щоб імітувати це, але це не так потужно, як варіант Git. Розгалуження командних проектів також може працювати, але з адміністративної точки зору це не реально для багатьох організацій, оскільки додавання командних проектів додає багато адміністративних витрат.

Я також хотів би додати до речей, згаданих у зоні контролю не джерела. Такі функції, як відстеження робочих елементів, автоматизація звітів та автоматизація збірок (включаючи управління лабораторією), значною мірою користуються центральним провідним сховищем. Вони стають набагато складніше, коли ви використовуєте чисту розподілену модель, якщо ви не зробите один із вузлів, що ведуть (і таким чином повернетесь до менш розподіленої моделі).

Якщо TFS Basic поставляється з TFS 11, можливо, не заздалегідь очікувати розподіленого TFS, який дозволяє синхронізувати локальний базовий TFS з центральним TFS в епоху TFS 12+. Я покладу свій голос за це у фаховому рахунку !

— вишукування
джерело
Вам також буде цікава ця нова функція, яку вам запропонувала Microsoft: gittf.codeplex.com
— jessehouwing
1
використовувати git-tfs. На даний момент це краще, ніж git-tf !!! github.com/git-tfs/git-tfs
— Філіп
3
Вся ця відповідь швидко застаріла. Microsoft додала підтримку Git до сервісу Team Foundation та додасть підтримку для Git до наступного великого випуску Team Foundation Server.
— jessehouwing
1
@Philippe: Я спробував і те, і інше. Пара відмінностей: 1) git-tf є кросплатформою, тоді як git-tfs працює лише в Windows. 2) git-tfs переписує описи фіксування, коли ви "натискаєте", щоб включити номер набору змін, тоді як git-tf залишає ваші локальні хеші фіксації недоторканими.
— Джої Адамс
@JoeyAdams 1) +1, це єдиний вагомий привід вибрати git-tf 2) Ви також можете це зробити з git-tfs, використовуючи checkinкоманду (замість rcheckin). Але я віддаю перевагу rcheckin, тому що це більше git спосіб робити речі, і тому ми вирішили використовувати git;)
— Philippe
9

Для мене головна відмінність - це всі допоміжні файли, які TFS додасть у ваше рішення (.vssscc) до «підтримки» TFS - у нас були недавні проблеми з цими файлами, які закінчуються, перенесені на неправильну гілку, що призводить до цікавої налагодження ...

— Падді
джерело
2
Хороший момент тут. Git додасть .gitпапку для відстеження всіх реквізитів сховища. TFS як мінімум змінить ваші .sln(чи це .csproj?) Файли, щоб помістити в нього розташування віддаленого сховища.
— CodingWithSpike
5
Я б забув, як сильно ненавиджу, як VSS змінює ваші файли "на" вас.
— Падді
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.