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

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

Я думаю, заявление

все ненавидят это кроме меня

лишает всякого дальнейшего обсуждения: когда вы продолжаете использовать Git, они будут обвинять вас, если что-то пойдет не так.

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

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

Но, как я уже сказал: я думаю, что вы ведете проигранную битву: когда все ненавидят Git, не используйте Git. Это может помочь вам узнать, почему они ненавидят Гита, а не пытаться убедить их.

Если они просто не хотят этого, потому что это ново для них и не желают учиться чему-то новому: уверены ли вы, что будете успешно работать с этим персоналом?

Действительно ли каждый человек ненавидит Git или на него влияют некоторые лидеры мнений? Найдите лидеров и спросите их, в чем проблема. Убедите их, и вы убедите всю команду.

Если вы не можете убедить лидеров: забудьте об использовании Git, возьмите TFS. Сделает вашу жизнь проще

Основное различие между этими двумя системами заключается в том, что TFS - это централизованная система контроля версий, а Git - распределенная система контроля версий.

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

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

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

Например, если я работаю над большой функцией, мне может потребоваться неделя, чтобы написать код и полностью протестировать его. Я не хочу регистрировать нестабильный код в середине недели и прервать сборку, но что произойдет, если я приближаюсь к концу недели и случайно уволил всю свою рабочую копию? Если я не совершал все это время, я рискую потерять свою работу. Это не эффективный контроль версий, и TFS подвержена этому.

С DVCS я могу выполнять коммиты постоянно, не беспокоясь о нарушении сборки, потому что я фиксирую свои изменения локально . В TFS и других централизованных системах отсутствует концепция локальной регистрации.

Я даже не думал о том, насколько лучше ветвление и слияние в DVCS, но вы можете найти множество объяснений здесь, в SO или через Google. По опыту могу сказать, что ветвление и слияние в TFS не очень хорошо.

Если аргументом для TFS в вашей организации является то, что он работает лучше в Windows, чем в Git, я бы предложил Mercurial, который отлично работает в Windows - есть интеграция с Windows Explorer (TortoiseHg) и Visual Studio (VisualHg).

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

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

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

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

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

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

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

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

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

В довершение всего сказанного (

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 предоставляет единый пункт назначения.

Если ваша команда использует TFS и вы хотите использовать Git, возможно, вы захотите использовать мост «git to tfs». По сути, вы работаете изо дня в день, используя Git на своем компьютере, затем, когда вы хотите отправить изменения, вы отправляете их на сервер TFS.

Там есть пара (на github). Я использовал один на моем последнем месте (вместе с другим разработчиком) с некоторым успехом. Видеть:

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

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

После некоторого расследования за и против, компания, с которой я был связан, также решила пойти на TFS. Не потому, что GIT не является хорошей системой контроля версий, а важнее всего для полностью интегрированного решения ALM, которое обеспечивает TFS. Если бы важна была только функция контроля версий, возможно, выбор был за GIT. Крутая кривая обучения GIT для обычных разработчиков, однако, не может быть недооценена.

Смотрите подробное объяснение в моем блоге TFS как настоящую кросс-технологическую платформу .

Распределенная штука Git действительно великолепна. он предоставляет некоторые функции, которые не имеют Shelvesets (в текущем продукте), такие как локальный откат и параметры фиксации (такие как функция локальной истории Eclipse ). Вы можете облегчить это, используя ветки для разработчиков, но давайте будем честными, многим разработчикам не нравится ветвление и слияние. Меня попросили включить функцию «Эксклюзивная проверка» в старом стиле в TFS несколько раз слишком часто (и отказывали в этом каждый раз).

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

Упоминается, что это отличный способ резервного копирования, который отлично подходит для открытого исходного кода, когда первоначальный сопровождающий может перестать заботиться и удалить свою версию, но для корпоративного плана это снова не подходит для многих предприятий, поскольку нет четкого распределения ответственности хранить резервные копии. И было бы трудно определить, какую версию использовать, если основной «проект» как-то исчезнет. Который будет склонен назначить один репозиторий в качестве ведущего / центрального.

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

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

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

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