Я представил Git моей команде разработчиков, и все это ненавидит, кроме меня. Они хотят заменить это с Team Foundation Server. Я чувствую, что это огромный шаг назад, хотя я не очень хорошо знаком с TFS. Может ли кто-нибудь с опытом сравнить поддержку ветвления на TFS на Git ветвление? Кроме того, в общем, каковы плюсы и минусы TFS? Я буду ненавидеть это после используя Git в течение нескольких лет?
Git vs Team Foundation Server
Ответ 1
Я думаю, утверждение
все ненавидят его, кроме меня
приводит к дальнейшему обсуждению отходов: когда вы продолжаете использовать Git, они будут обвинять вас, если что-то пойдет не так.
Кроме того, для меня Git имеет два преимущества перед централизованным VCS, который я ценю больше всего (частично описанный Rob Sobers):
- автоматическое резервное копирование всего репо: каждый раз, когда кто-то тянет с центрального репо, он/она получает полную историю изменений. Когда теряется одно репо: не беспокойтесь, возьмите один из присутствующих на каждой рабочей станции.
- автономный доступ к репо:, когда я работаю дома (или в самолете или поезде), я могу видеть полную историю проекта, каждую проверку, не запуская мое VPN-соединение работать и работать, как я был на работе: checkin, checkout, branch, anything.
Но, как я сказал: я думаю, что вы сражаетесь с проигранной битвой: когда все ненавидят Git, не используйте Git. Это может помочь вам узнать больше, почему они ненавидят Git вместо того, чтобы убеждать их.
Если они просто не хотят, чтобы это было ново для них, и они не хотят изучать что-то новое: уверены ли вы, что вы будете успешно работать с этим персоналом?
Действительно ли каждый человек ненавидит Git или на него влияют некоторые лидеры общественного мнения? Найдите лидеров и спросите их, в чем проблема. Убедите их, и вы убедите остальных в команде.
Если вы не можете убедить лидеров: забудьте об использовании Git, возьмите TFS. Сделайте вашу жизнь проще.
Ответ 2
Ключевое различие между двумя системами заключается в том, что TFS является централизованной системой управления версиями, а Git является распределенной системой управления версиями.
С TFS репозитории хранятся на центральном сервере, а разработчики проверяют рабочую копию, которая представляет собой моментальный снимок кода в определенный момент времени. С помощью Git разработчики клонируют весь репозиторий на свои машины, включая всю историю.
Одним из преимуществ наличия полного хранилища на ваших машинах-разработчиках является избыточность в случае, если сервер умирает. Другим приятным преимуществом является то, что вы можете перемещать свою рабочую копию туда и обратно между версиями, не разговаривая с сервером, что может быть полезно, если сервер не работает или просто недоступен.
Для меня реальным преимуществом является то, что вы можете совершать изменения в своем локальном репозитории, не разговаривая с сервером или не внося потенциально нестабильные изменения в своей команде (т.е. нарушая сборку).
Например, если я работаю над большой функцией, мне может потребоваться неделя, чтобы закодировать и протестировать ее полностью. Я не хочу проверять нестабильный код в середине недели и прерывать сборку, но что произойдет, если я приближаюсь к концу недели, и я случайно обручу всю свою рабочую копию? Если я не совершал все это время, я рискую потерять свою работу. Это не эффективный контроль версий, и TFS восприимчив к этому.
С DVCS я могу совершать постоянно, не беспокоясь о нарушении сборки, потому что я совершаю свои изменения локально. В TFS и других централизованных системах нет понятия локальной регистрации.
Я даже не понял, насколько лучше разветвление и слияние происходит в DVCS, но вы можете найти массу объяснений здесь на SO или через Google. Я могу сказать вам по опыту, что ветвление и слияние в TFS не очень хорошо.
Если аргументом для TFS в вашей организации является то, что он лучше работает в Windows, чем Git, я бы предложил Mercurial, который отлично работает на Windows - там интеграция с Windows Explorer (TortoiseHg) и Visual Studio (VisualHg),
Ответ 3
Люди должны положить оружие, отойти от уступа и подумать на минутку. Оказывается, для DVCS есть объективные, конкретные и неоспоримые преимущества, которые сделают ОГРОМНОЕ различие в производительности команды.
Все сводится к разделению и слиянию.
Прежде чем DVCS, основным принципом было: "Молитесь Богу, чтобы вам не приходилось входить в ветвление и слияние. И если вы это сделаете, попросите Его, чтобы он был очень и очень простым".
Теперь, с DVCS, разветвление (и слияние) значительно улучшилось, руководящим принципом является "Сделайте это при падении шляпы, это даст вам массу преимуществ и не вызовет у вас никаких проблем".
И это ОГРОМНЫЙ усилитель производительности для любой команды.
Проблема заключается в том, что для людей, чтобы понять, что я только что сказал, и убедиться, что это правда, они должны сначала инвестировать немного в учебную кривую. Им не нужно изучать Git или любые другие DVCS... им просто нужно узнать, как Git выполняет ветвление и слияние. Читайте и перечитывайте некоторые статьи и сообщения в блогах, делая это медленно и работая через него, пока не увидите его. Это может занять большую часть 2 или 3 полных дня.
Но как только вы это увидите, вы даже не подумаете о выборе не DVCS. Потому что действительно существуют ясные, объективные, конкретные преимущества для DVCS, а самые большие победы в области ветвления и слияния.
Ответ 4
Оригинал: @Rob, в TFS есть что-то, называемое Shelving ", которое касается вашей озабоченности по поводу совершения незавершенного производства без это влияет на официальную сборку. Я понимаю, что вы видите, что контроль центральной версии является препятствием, но в отношении TFS проверка кода на полке может рассматриваться как сила b/c, тогда на центральном сервере есть копия вашей незавершенной работы в редком случае ваша локальная машина сбой или потеряна/украдена или вам необходимо быстро переключать передачи. Я хочу сказать, что TFS следует уделять должное внимание в этой области. Кроме того, разветвление и слияние в TFS2010 было улучшено из предыдущих версий, и неясно, какую версию вы имеете в виду, когда говорите"... из опыта, что ветвление и слияние в TFS не очень хорошо". Отказ от ответственности: я умерший пользователь TFS2010.
Edit Dec-5-2011. В OP одна вещь, которая беспокоит меня о TFS, заключается в том, что она настаивает на том, чтобы все локальные файлы были "доступны только для чтения", когда вы не работаете на них. Если вы хотите внести изменения, поток состоит в том, что вы должны "выгрузить" файл, который просто очищает атрибут readonly в файле, чтобы TFS знал, чтобы следить за ним. Это неудобный рабочий процесс. Способ, которым я бы предпочел, чтобы он работал, это то, что он автоматически обнаруживает, изменил ли я изменения и вообще не беспокоюсь/не беспокоюсь об атрибутах файлов. Таким образом, я могу изменить файл либо в Visual Studio, либо в "Блокноте", либо с помощью любого инструмента, который мне нравится. Система контроля версий должна быть максимально прозрачной в этом отношении. Существует расширение Windows Explorer (TFS PowerTools), который позволяет работать с вашими файлами в проводнике Windows, но это не упрощает рабочий процесс очень.
Ответ 5
В дополнение ко всему сказанному (
fooobar.com/questions/33194/...
),
что верно, TFS - это не просто VCS. Одной из основных функций, предоставляемой TFS, является встроенная функция отслеживания ошибок. Изменения связаны с проблемами и могут отслеживаться. Поддерживаются различные политики для проверок, а также интеграция с доменом Windows, что и люди, которые запускают TFS. Тесно интегрированный графический интерфейс с Visual Studio - это еще одна точка продажи, которая обращается к меньше, чем средняя мышью, и щелкните разработчиком и его менеджером.
Следовательно, сравнение Git с TFS не является правильным вопросом. Правильный, хотя и непрактичный, вопрос заключается в сравнении Git с только функциями VCS TFS. При этом Git удаляет TFS из воды. Тем не менее, любой серьезной команде нужны другие инструменты, и именно здесь TFS обеспечивает одноразовое назначение.
Ответ 6
Если ваша команда использует TFS и вы хотите использовать Git, вы можете рассмотреть мост "git to tfs". По существу, вы работаете изо дня в день с помощью Git на вашем компьютере, а затем, когда вы хотите нажать свои изменения, вы нажимаете их на сервер TFS.
Там пара (на github). Я использовал один на своем последнем месте (вместе с другим разработчиком) с некоторым успехом. См:
Ответ 7
После некоторого расследования между про и минусами компания, с которой я была связана, также решила пойти на TFS. Не потому, что GIT не является хорошей системой управления версиями, но, самое главное, для полностью интегрированного решения ALM, которое предоставляет TFS. Если важна только функция контроля версий, возможно, выбор был GIT. Крутая кривая обучения GIT для обычных разработчиков может не быть недооценена.
См. подробное объяснение в своем сообщении в блоге TFS как настоящая кросс-технологическая платформа.
Ответ 8
Вся распределенная вещь Git действительно отличная. он предоставляет несколько функций, которые у Shelvesets нет (в текущем продукте), такие как параметры локального отката и фиксации (например, функция Eclipse localhistory). Вы могли бы облегчить это, используя ветки разработчиков, но, если честно, многим разработчикам не нравится разветвление и объединение одного бита. Меня попросили включить функцию "эксклюзивного контроля" старого стиля в TFS несколько раз слишком часто (и отрицали ее каждый раз).
Я думаю, что многие крупные предприятия очень напуганы, чтобы позволить разработчику просто привести всю историю в локальную рабочую область и взять ее с собой (например, для нового работодателя)... Кража снимка плохая, но убирающая вся история еще более хлопотная. (Не то, чтобы вы не могли получить полную историю из TFS, которую вы хотели)...
Он упомянул, что это отличный способ резервного копирования, который отлично подходит для использования с открытым исходным кодом снова, где первоначальный сопровождающий может перестать ухаживать и удалять свою версию, но для корпоративного плана это снова не подходит для многих предприятий, поскольку нет четкого назначение ответственности за резервное копирование. И было бы трудно понять, какую версию использовать, если основной "проект" как-то пропадает. Который имел тенденцию назначать один репозиторий как ведущий/центральный.
Что мне больше всего нравится в Git, это опция Push/Pull, где вы можете легко вносить код в проект без необходимости иметь права на фиксацию. Я думаю, вы могли бы использовать очень ограниченных пользователей и полки в TFS, чтобы имитировать это, но это не так сильно, как опция Git. Взаимодействие между командами также может работать, но с административной точки зрения это не реально для многих организаций, поскольку добавление командных проектов добавляет много административных накладных расходов.
Я также хотел бы добавить к вещам, упомянутым в области управления без источника. Такие функции, как отслеживание рабочих элементов, отчетность и автоматизация сборки (в том числе управление лабораторией), значительно выигрывают от центрального ведущего репозитория. Это становится намного сложнее, если вы используете чистую распределенную модель, если только вы не сделаете один из ведущих узлов (и, следовательно, вернитесь к менее распределенной модели).
При запуске TFS Basic с TFS 11, возможно, не слишком далеко ожидать распределенной TFS, которая позволяет синхронизировать ваш локальный TFS файл с центральной TFS в эпоху TFS 12+. Я поставлю свой голос за это в uservoice!
Ответ 9
Для меня основное отличие - это все вспомогательные файлы, которые TFS добавит к вашему решению (.vssscc), чтобы "поддерживать" TFS. У нас были недавние проблемы с этими файлами, заканчивающимися сопоставлением с неправильной ветвью, что приводит к некоторые интересные отладки...