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

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

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

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

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

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

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

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

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

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

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

до DVCS руководящим принципом было " молитесь Богу, чтобы вам не пришлось входить в ветвление и слияние. И если да, то, по крайней мере, умоляй его, пусть это будет очень, очень простой."

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

и это огромный усилитель производительности для любой команды.

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

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

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

Редактировать Dec-5-2011: для OP одна вещь, которая беспокоит меня о TFS, заключается в том, что он настаивает на настройке всех ваших локальных файлов на " только для чтения" когда не работаешь над ними. Если вы хотите внести изменения, поток заключается в том, что вы должны "проверить" файл, который просто очищает атрибут readonly в файле, чтобы TFS знал, чтобы следить за ним. Это неудобный рабочий процесс. Я бы предпочел, чтобы он работал, это просто автоматически определяет, внес ли я изменения и не беспокоится/не беспокоится об атрибутах файла вообще. Таким образом, я могу изменить файл либо в Visual Studio, либо в Notepad, либо с помощью любого инструмента. Этот система контроля версий должна быть максимально прозрачной в этом отношении. Существует расширение Проводника Windows (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. Плотно интегрированный GUI с 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 действительно очень велика. это дает несколько функций, которые у полок нет (в текущем продукте), таких как локальный откат и параметры фиксации (например,функция локальной истории Eclipse). Вы можете облегчить это, используя ветви разработчиков, но, честно говоря, многим разработчикам не нравится ветвление и слияние одного бита. Меня попросили включить функцию "exclusive checkout" старого стиля в TFS несколько раз слишком часто (и отрицали это каждый время.)

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

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

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

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

с TFS Basic поставляется с TFS 11, это не может быть далеко ожидать распределенного TFS, который позволяет синхронизировать локальный TFS basic с центральным TFS в эпоху TFS 12+. Я положу свой голосовать за That down in the uservoice!

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