Git по сравнению с Mercurial для разработчиков .NET?

Ответ 1

Я использую Mercurial уже более года для разработки .NET, и он отлично работает. Я признаю, что я не использую ни одного из причудливых инструментов (надстроек проводника и инструментов Visual Studio), но они доступны (например, TortoiseHg). Я обнаружил, что использование инструментов командной строки так же просто - просто укажите несколько подстановочных знаков в .hgignore(как в ответ Блаенка), и вам хорошо идти.

Я не уверен, насколько хорошо git интегрируется с hg, но для обратной siutation я использовал hg-git в прошлое, и все прошло отлично. Тем не менее, он по-прежнему нестабилен, поскольку появляются новые выпуски hg.

Итак, вы должны иметь возможность использовать github из mercurial, и для родных меркуриальных репозиций всегда есть (imo) одинаково приятный bitbucket.org. Изменить: Обратите внимание, что codeplex, который ориентирован на проекты с открытым исходным кодом .NET, теперь предлагает хранилища git и Mercurial.

И я должен упомянуть, что "популярность" - очень сложный критерий, основанный на вашем выборе. Либо у DVCS есть громкие пользователи. git имеет ядро ​​linux, конечно, в то время как известные пользователи hg включают проекты mozilla и Python.

РЕДАКТИРОВАТЬ: поскольку это, похоже, получает регулярные обороты. Все, что я написал выше, было правдой на момент написания, но я больше не согласен с моим прежним самоподобным битбакетом так же хорошо, как и GitHub. GitHub имеет лучшую функциональность, и с моей точки зрения (в основном, с открытым исходным кодом F #) все остальные есть, поэтому вы получаете гораздо лучшие сетевые эффекты. Я переместил весь свой проект с codeplex/bitbucket на GitHub некоторое время назад и сразу начал получать вклады, тогда как на codeplex/bitbucket рядом ничего не произошло.

Ответ 2

Я думаю, что при росте экспоненциальной популярности git git хорошая поддержка окон (сродни подрывной деятельности с чем-то вроде черепахиSVN) обязательно придет, это всего лишь вопрос времени. Два проекта, которые кажутся наиболее популярными, msysgit и TortoiseGit (также использует msysgit), который похож на tortoiseSVN. git продолжает становиться все более и более популярным, что если бы вы столкнулись с какими-либо проблемами, которые сейчас маловероятны, и становится еще более маловероятным, поскольку инструменты git для окон становятся более развитыми, вы сможете найти исправления намного проще из-за большой пользовательской базы.

Тем временем я нашел эту серию руководств, чтобы быть очень полезными.

Проблемы, с которыми вы могли столкнуться, могут игнорировать определенные файлы, что должно быть легко, если вы посмотрите, как использовать .gitignore, что очень просто, вот список файлов и подстановочных знаков, которые упоминаются в этой серии:

obj
bin
_ReSharper.*
*.csproj.user
*.resharper.user
*.resharper
*.suo
*.cache
*~
*.swp

Также я видел некоторые проблемы, касающиеся окончаний строк. Для этого вам нужно проверить этот вопрос.

Ответ 3

На момент написания я использовал TortoiseGit и TortoiseHg (для меркуриальных) в разных проектах, преимущественно java и .net проектах. Я должен сказать, что TortoiseHg лидирует, поскольку он намного более стабилен и полностью отличается от двух.

Существует плагин Mercurial для Visual Studio 2008, но я предлагаю придерживаться TortoiseHg, пока сам плагин не станет стабильным. Не уверен в интеграции с git, но есть некоторые разговоры о плагине для VS здесь.

Ответ 4

Хотя git является естественной ничье для пользователей unix/linux, он стал лучше для пользователей Windows и .net. меркуриальный, однако, может быть лучшим выбором между ними. в отличие от централизованного разработчика, где есть множество вариантов, там очень мало "истинных" инструментов dvcs. насколько я знаю, существует только одна коммерческая система, пластмассовый scm и два вышеупомянутых инструмента oss. я пришел со стороны прозрачного пространства и имею опыт работы с pvcs, p4 и другими традиционными инструментами scm. я споткнулся о пластик, может быть, через этот сайт и из того, что я оценил, кажется, преуспевает с визуальной точки зрения. если вы больше из магазина окон, как вы говорите, это может быть пластическое, меркуриальное и git в этом порядке. если вы больше unix/linux, git, вероятно, первый логический выбор. надеюсь, что это поможет!

Ответ 5

Оба Git и Mercurial отлично справятся с .NET-разработчиком, но хорошо известно, что Mercurial имеет лучшую поддержку Windows. Кроме того, если вы рассматриваете коммерческий инструмент, почему бы вам не взглянуть на Пластик SCM, прочитав следующий учебник по распределенным разработчикам в Windows? http://codicesoftware.blogspot.com/2010/03/distributed-development-for-windows.html Обновление Теперь у Пластикового SCM есть бесплатная версия Community Edition.

Ответ 6

Я серьезно не использовал Mercurial, но только что закончил переход на Git из Subversion для .NET. Распространение, которое я использую, Git Расширения, которые устанавливают стандарт (msys) Git, плюс графический интерфейс, некоторые Windows Explorer и плагин Visual Studio. Он также поставляется с хорошими документами. Интеграция с Explorer не обеспечивает четкие маркеры статуса на значках файлов, которые TortoiseSVN делает, а просто добавляет необходимые элементы в контекстное меню. Все эти инструменты работают нормально.

Самая большая проблема, которую я обнаружил, заключается в том, что Git требует, чтобы вы поняли концепции, чтобы получить хорошие результаты. Графические интерфейсы Git Расширения - это только тонкие оболочки поверх объектов Git, поэтому, если вы боретесь с, скажем, подмодулями, то ни один из инструментов, предоставляемых Git Extensions, не решит эту проблему. В настоящее время существует множество обучающих программ и видеороликов о Git в Интернете.

По умолчанию Windows строит Git преобразование строк в CRLF; так как мы полностью являемся магазином MS, это правильное поведение для нас.

Ответ 7

Git имеет большое преимущество, которое облегчит жизнь при использовании VS, обнаружение переименования, если вы хотите просто использовать интерфейс командной строки. В HG вы должны переименовать файлы при переименовании в VS, в Git будет легко обнаруживать ваши переименования (он отслеживает содержимое не файлов), даже если вы внесете некоторые изменения в файл, он также обнаружит переименование.