Git против Team Foundation Server [закрыто]


263

Я представил Git своей команде разработчиков, и все ненавидят его, кроме меня. Они хотят заменить его Team Foundation Server. Я чувствую, что это огромный шаг назад, хотя я не очень знаком с TFS. Может кто-то с опытом сравнить ветвление поддержки на TFS с ветвлением Git? Кроме того, в целом, каковы плюсы и минусы TFS? Собираюсь ли я ненавидеть это после использования Git в течение нескольких лет?


24
Вам предстоит тяжелая битва на этом. Git далеко не так совершенен, как svn / hg / tfs в Windows, что не сильно беспокоит ветеранов git, но является большой головной болью для новичков.
Марсело Кантос

7
@Jacko: последние несколько недель я проверял git-for-Windows. Хотя он заметно улучшился с тех пор, как я последний раз смотрел его около года назад, он еще далек от того, чтобы быть готовым к прайм-тайм с типичными разработчиками Windows. Например, плагин VS откровенно печален. Это не что иное, как набор пунктов меню под строкой главного меню, которые молча терпят неудачу, если вместо проекта выбрано решение. Я не могу получить инструмент фиксации для индексации фрагментов и строк, что является основной причиной, по которой я использую git, и переход к git gui (что является полным злодеянием из удобного для пользователя POV) в лучшем случае неудобен.
Марсело Кантос

6
Я буду честен с тобой, хотя; это убивает меня, чтобы бросить мерзавца. Вопреки распространенному мнению, что эти два стандарта, я считаю, что модель git гораздо более мощная и логичная. Mercurial не имеет ничего общего с индексом git, и я ненавижу его подход к ветвлению. Концепция ярлыков Git, которые вы перемещаете и синхронизируете между репозиториями, очень элегантна. Закладки Mercurial - единственное, что подходит близко, и это PITA, чтобы настроить для всех. Суть в том, что успех более вероятен при использовании svn → Mercurial, чем svn → git, учитывая штат и относительную зрелость инструментов.
Марсело Кантос

4
да, Git правит, когда дело доходит до власти и элегантности. Но не все к этому готовы.
Джако

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. Сделает вашу жизнь проще


22
Ударь, ёксы. Они обвиняют меня всякий раз, когда что-то идет не так. Не для того, чтобы не узнать, как это работает. Для меня Git так же близок к совершенству, как я когда-либо испытывал в системе контроля версий.
Джако

15
С другой стороны, TFS включает в себя отслеживание дефектов / рабочих элементов, отчеты, ... и другие функции. Так что Git vs TFS только на функциональности VCS, скорее всего, упускает из виду TFS.
Ричард

5
@ Дан увидеть ребаз, дерево фильтров ...
Artefacto

7
@Artefacto Я знаю, но затем все теги коммитов меняются, и все метаданные (обсуждения обзора кода и т. Д.) Становятся осиротевшими или требуют обновления. Тем не менее, месяц с TFS убедил меня, что он не входит в лигу Git как система контроля версий. Git освобождает разработчика от продуктивной работы, которая должна быть понятной для понимания. Ветвь как метафора блокнота очень злая.
Дан Соловай

6
@ Ричард Я бы сказал, что у 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
Если вы думаете о переходе на Mercurial, у Джоэла Спольски есть отличный учебный сайт для обучения вашей команды: hginit.com
Мартин Оуэн,

3
Возможно, стоит упомянуть, что git идеально подходит для эмуляции централизованной системы, и для всех пользователей обычно есть основной git-сервер, просто вам не нужно делать это таким образом.
Тим Абелл

7
если вы работаете над частью функциональности, которая может нарушить другие функции - не могли бы вы просто создать ветку в TFS? Конечно, филиал находится на центральном сервере, но разве это имеет значение? Похоже, что вы можете эффективно делать одно и то же в обоих случаях - кажется, больше вопрос о том, какую IDE вы используете и насколько хорошо с ней интегрирована система управления версиями -
William

13
Если вы работаете с большой функцией, которая потенциально может прервать работу команды, рекомендуется использовать ветку функций, а затем, когда все будет готово, слиться с веткой разработки.
Майк Чил

9
@MikeCheel Это отличный комментарий. Вы также можете создавать полки своего кода каждый день и удалять их, когда вы, наконец, зарегистрируете свою функцию (но идея ветвления - лучший способ сделать это)
RPDeshaies

86

Люди должны опустить пистолет, отойти от выступа и подумать минуту. Оказывается, что у DVCS есть объективные, конкретные и неоспоримые преимущества, которые сильно повлияют на производительность команды.

Все сводится к ветвлению и слиянию.

До DVCS руководящим принципом было: «Молитесь Богу, чтобы вам не приходилось заниматься ветвлением и слиянием. И если вы это сделаете, по крайней мере, умоляйте Его, пусть это будет очень, очень просто».

Теперь, с DVCS, ветвление ( и слияние ) настолько улучшено, что руководящий принцип гласит: «Делайте это без промедления. Это даст вам массу преимуществ и не вызовет никаких проблем».

И это ОГРОМНОЕ повышение производительности для любой команды.

Проблема в том, чтобы люди поняли то, что я только что сказал, и были убеждены, что это правда, они должны сначала инвестировать немного в обучение. Им не нужно изучать Git или любую другую DVCS ... им просто нужно узнать, как Git разветвляется и объединяется. Прочитайте и перечитайте некоторые статьи и посты в блоге, продолжайте работать медленно, пока не увидите это. Это может занять лучшую часть 2 или 3 полных дня.

Но как только вы это увидите, вы даже не подумаете о выборе не DVCS. Потому что действительно есть четкие, объективные, конкретные преимущества для DVCS, и самые большие победы в области ветвления и слияния.


3
Спасибо, Чарли. Я знаю это, и вы знаете это, но трудно дозвониться до людей, которые говорят, что «интеграция управления исходным кодом с Visual Studio - самая важная функция для меня»
Jacko

58
Я знаю. Мы с другом разбрасывали эту аналогию - представьте, что вам нужна серьезная реляционная база данных. Вы оцениваете Sql Server, Oracle и MS Access. В конечном итоге вы выбираете Access, потому что у него самый приятный графический интерфейс, несмотря на то, что он не может масштабироваться, не обеспечивает хорошего соблюдения ссылочной целостности и т. Д. Ветвление и слияние - это абсолютная основа системы контроля версий. Любая другая особенность - просто небольшая побрякушка на стороне. Но люди делают выбор, основываясь на побрякушках.
Чарли Флауэрс

17
Хотя я склонен согласиться с вашими утверждениями, я не понимаю, почему ветвление и слияние Git «лучше» только потому, что это «распределенная» система. Я не уверен, что наличие DVCS имеет какое-либо отношение к его способности объединяться. Я хотел бы объяснить, почему объединение легче в распределенной системе. По моему опыту, который в первую очередь относится к Git и Svn, объединение в SVN ужасно не потому, что это централизованная VCS, а потому, что она не отслеживает исправления между ветвями, как это делает GIT.
CodingWithSpike

8
@ Rally25rs - Я согласен с большинством из этого. Нет причин, по которым VCS не может быть хорош в слиянии. Там просто еще нет (что я знаю). Но часть, с которой я не согласен, заключается в том, что «просто путем написания лучших процедур слияния, которые лучше разрешают конфликты». Секретный соус заключается не в более совершенных процедурах слияния, а в принципиально ином подходе к тому, какую информацию вы храните в репо и как вы ее организовываете. В основном, делает коммиты основой внутреннего состояния. Комитеты - это не просто крутые болты ... они - основа возможностей.
Чарли Флауэрс

10
@ Rally25rs полностью согласен re: совершает атомную единицу работы. Мало того, что большинство централизованных систем не организуют данные таким образом, они не поощряют тот момент, когда разработчики должны выполнять действительно хорошую работу по ветвлению и слиянию. Распределенные системы поощряют то, что я называю «подходящими» коммитами (самодостаточные, небольшие коммиты соответствующей работы с хорошими описаниями), а централизованные системы поощряют то, что я называю «различными бомбами», когда вы прячетесь в пещере, пока не будете готовы, а затем отбросите дни (или недели) стоит работы в системе. Угадайте, какой вид лучше всего сливается?
Бен Коллинз

45

Оригинал : @Rob, в TFS есть что-то под названием « Стеллажи », которое решает вашу проблему с выполнением незавершенного производства, не влияя на официальную сборку. Я понимаю, что вы рассматриваете централизованное управление версиями как помеху, но в отношении TFS проверка вашего кода на полке может рассматриваться как сильная сторона, тогда как на центральном сервере в редком случае будет копия вашей незавершенной работы. ваша локальная машина выходит из строя или утеряна / украдена, или вам нужно быстро переключать передачи. Моя точка зрения заключается в том, что TFS следует отдать должное в этой области. Кроме того, ветвление и слияние в TFS2010 было улучшено по сравнению с предыдущими версиями, и неясно, на какую версию вы ссылаетесь, когда говорите «... из опыта, что ветвление и слияние в TFS не годятся». Отказ от ответственности: я умеренный пользователь TFS2010.

Edit Dec-5-2011 : Для OP, одна вещь, которая беспокоит меня о TFS, это то, что он настаивает на установке всех ваших локальных файлов на «только для чтения», когда вы не работаете с ними. Если вы хотите внести изменение, процесс состоит в том, что вы должны «извлечь» файл, который просто очищает атрибут readonly для файла, чтобы TFS знал, что за ним следят. Это неудобный рабочий процесс. Я бы предпочел, чтобы это работало, так как он просто автоматически обнаруживает внесенные мной изменения и вообще не беспокоится об атрибутах файла. Таким образом, я могу изменить файл либо в Visual Studio, либо в Блокноте, или любым другим инструментом, который мне нравится. В этом отношении система контроля версий должна быть максимально прозрачной. Существует расширение для Windows Explorer ( TFS PowerTools), который позволяет работать с файлами в проводнике Windows, но это не сильно упрощает рабочий процесс.


2
Это отвечает на вопрос, это не должен быть комментарий, даже если у вас был представитель.
SingleNegationElimination

8
К вашему сведению - TFS «11» больше не требует бит только для чтения, если вы используете локальные рабочие пространства, которые сейчас используются по умолчанию. Он интеллектуально обнаруживает, какие файлы изменяются из любого приложения. Брайан Гарри имеет больше информации об улучшениях здесь: blogs.msdn.com/b/bharry/archive/2011/08/02/…
Эд Бланкеншип,

2
@EdBlankenship, большое спасибо за эту ссылку в блоге. Это отличная новость - видеть, что бессмысленная чепуха, предназначенная только для чтения, предназначена для упрощения использования следующей версии TFS.
Ли Гриссом

7
В отличие от коммитов в ветке, как вы делаете с Git, стеллажи нелегко понять и управлять. Вы не знаете, на каком коммите был сделан откладывание, и у вас часто возникают проблемы со слиянием (если вы с тех пор внесли изменения, они часто теряются). Git-ветка гораздо более мощная и понятная, чем стеллажи. Стеллажи предназначены для разработчиков, которые никогда не испытывали ничего другого ...
Филипп

2
Этот рабочий процесс «извлечения» файла напоминает Visual SourceSafe, так как это был обычный способ работы; файлы были получены из SourceSafe и хранятся локально как файлы только для чтения. Извлечение файла или группы файлов может быть помечено как эксклюзивное, что означает, что другие могут видеть набор файлов, над которым работает другой разработчик, чтобы предотвратить необходимость объединения при отключении ветвления (возможно, из-за того, что правая свинья в VSS).
Бретт Ригби

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. При этом Git выдувает TFS из воды. Тем не менее, любой серьезной команде нужны другие инструменты, и именно здесь TFS предоставляет единый пункт назначения.


4
Пожалуйста, вы можете получить те же инструменты, которые предоставляет TFS в любом гибком приложении. Ралли, ты называешь это.
PositiveGuy

2
Хотя я согласен с тем фактом, что TFS имеет более широкую цель, я бы перефразировал ее так: «ПОПЫТАЕТСЯ предоставить единый пункт назначения», но это не достаточно хорошо (по крайней мере, не самый лучший вариант) в любой из задач, которые он пытается выполнить. решить; так что это как тупой швейцарский нож.
slashCoder

@PositiveGuy вы не можете получить его без работы и настройки. TFS дает вам все это одним щелчком мыши. В данном случае вся экосистема теперь доступна в виде облачной службы, без необходимости настройки. Если я могу получить контроль версий, поддержку scrum, автоматизированные сборки, тестовую лабораторию и управление планами тестирования, все интегрированные вместе с собой и корпоративный LDAP (ложь AzureAD), за 10 долларов в месяц, почему я в здравом уме пойду пытаясь склеить кусочки самостоятельно?
Крейг Брунетти

1
@slashCoder, как можно ожидать, что любой полный пакет будет лучшим в каждой части? Действительно ли стоимость его неэффективности превосходит стоимость необходимости самостоятельно управлять интеграцией компонентов? ... может быть, в некоторых местах, я вижу это. Но иметь дело с такими вещами - это просто накладные расходы. Что произойдет, если ваш корпоративный GIT работает нормально, но ваш экземпляр JIRA не работает, а обновление Jenkins не работает? Правильно? Это как жонглирование бензопилами. В огне. Semi-завязанные глаза. :) :)
Крейг Брунетти

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 (и это то, что мы хотим!)
Филипп

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, по сути, ставит вопрос о том, что «Microsoft собирается победить во всех аспектах моего ALM», что глупо. Например, я использовал Git с Jira, что позволило мне обновлять / закрывать проблемы на основе моего сообщения о коммите. По моему опыту (много с TFS тоже), это значительно лучший рабочий процесс.
Скотт Сильви

1
Боковая панель - даже с интеграцией TFS / Git, вы в основном говорите: «позволяет подключать VCS к Git, сохраняя при этом наше отслеживание проблем» - принципиально ничем не отличается от использования Git с любым другим программным обеспечением для отслеживания проблем. Так что я не уверен, что аргумент ALM больше действителен, учитывая попытки Microsoft проявить гибкость (что я аплодирую).
Скотт Сильви

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 Service и добавит поддержку 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.