Git vs Mercurial для разработчиков .NET?
df = pd.DataFrame({'A': 'foo bar foo bar foo bar foo foo'.split(),
'B': 'one one two three two two one three'.split(),
'C': np.arange(8), 'D': np.arange(8) * 2})
df[df['A']=='foo']
OUTPUT:
A B C D
0 foo one 0 0
2 foo two 2 4
4 foo two 4 8
6 foo one 6 12
7 foo three 7 14
6 ответов
I have been using Mercurial for over a year now for doing .NET development, and it has been working out great. I do admit I don't use any of the fancy tools (explorer add-ons and Visual studio tools), but they are available (e.g. TortoiseHg). I have found that using the command line tools is just as easy - just specify a few wildcards in .hgignore (as in Blaenk's answer) and you're good to go.
I'm not sure how well git integrates with hg, but for the reverse siutation I have used hg-git in the past and it worked fine. It is however still somewhat unstable as new releases of hg come out.
So you should be able to use github from mercurial, and for native mercurial repos there is always the (imo) equally nice bitbucket.org. Edit: Note also that codeplex, which is focused on .NET open source projects, now offers Git and Mercurial repositories.
And I should mention that "popularity" is a very difficult criterion to base your choice on. Either DVCS has high-profile users. Git has the linux kernel, of course, while notable hg users include the mozilla and Python projects.
EDIT: Since this seems to get regular upvotes. Everything I wrote above was true at the time of writing, but I no longer agree with my former self bitbucket is as nice as GitHub. GitHub has better functionality, and from my point of view (mostly F# open source development) everyone else is there so you get much better network effects. I moved all my project from codeplex/bitbucket to GitHub a while ago and immediately started getting contributions, whereas on codeplex/bitbucket next to nothing happened.
I think that given git's exponential popularity growth, git's good support for windows (akin to that of subversion's with something like tortoiseSVN) is bound to arrive, it is only a matter of time. The two projects that seem to be the most popular are msysgit, and TortoiseGit (also uses msysgit) which is similar to tortoiseSVN. git keeps becoming more and more popular, that if you were to run into any problems which is unlikely now and is becoming even more unlikely as git tools on windows become further developed, you will be able to find fixes a lot easier due to the large userbase.
In the meantime, I have found this series of guides to be very helpful.
Issues you might run into may be ignoring certain files, which should be easy if you lookup how to use .gitignore, which is really straightforward, here is the list of files and wildcards that the series mentions:
obj
bin
_ReSharper.*
*.csproj.user
*.resharper.user
*.resharper
*.suo
*.cache
*~
*.swp
Also I have seen some issues regarding line endings. For that, you will want to check out this question.
На момент написания я использовал как TortoiseGit , так и TortoiseHg (для mercurial) в разных проектах, преимущественно java и .net. . Я должен сказать, что TortoiseHg лидирует, поскольку он намного более стабильный и полнофункциональный из двух.
Существует плагин Mercurial для Visual Studio 2008 , но я бы посоветовал придерживаться TortoiseHg пока сам плагин не станет стабильным. Не уверен в интеграции с git, но есть некоторые разговоры о плагине для VS здесь .
Я не использовал Mercurial всерьез, но только что закончил переход на Git с Subversion для разработки .NET. Я использую дистрибутив Git Extensions , который устанавливает стандартный (msys) Git, а также графический интерфейс, некоторую интеграцию с Windows Explorer и подключаемый модуль Visual Studio. Он также поставляется с хорошей документацией. Интеграция с проводником не обеспечивает аккуратных маркеров состояния на значках файлов, как в TortoiseSVN, а просто добавляет необходимые элементы в контекстное меню. Все эти инструменты работают нормально.
Самая большая проблема, которую я обнаружил, заключается в том, что Git требует от вас понимания концепций для получения хороших результатов. Графические интерфейсы Git Extensions - это просто тонкие оболочки над средствами Git, поэтому, если вы боретесь, скажем, с подмодулями, тогда ни один из инструментов, предоставляемых Git Extensions, не решит эту проблему. Тем не менее, сейчас в Интернете есть множество учебных пособий и видеороликов о Git.
По умолчанию сборки Git для Windows конвертируют окончания строк в CRLF; поскольку мы полностью являемся магазином MS, это правильное поведение для нас.
У Git есть большое преимущество, которое упростит жизнь при использовании VS, обнаружение переименования, если вы хотите просто использовать интерфейс командной строки, в HG у вас есть чтобы переименовать файлы, когда вы переименовываете его в VS, в Git будет легко обнаруживать ваши переименования (он отслеживает содержимое, а не файлы), даже если вы вносите некоторые изменения в файл, он также обнаружит переименование.
И Git, и Mercurial отлично подойдут для разработчика .NET, но хорошо известно, что Mercurial имеет лучшую поддержку Windows. Также, если вы рассматриваете коммерческий инструмент, почему бы вам не взглянуть на Plastic SCM, прочитав следующий учебник по распределенной разработке под Windows? http://codicesoftware.blogspot.com/2010/03/distributed-development-for-windows.html Обновление Теперь у Plastic SCM есть БЕСПЛАТНАЯ Community Edition.