¿Git versus Mercurial para desarrolladores de .NET?

Me he estado preguntando ¿cuál es el mejor DVCS para los desarrolladores de .NET? A partir de la lectura de información diversa, parece que Mercurial funciona mejor en Windows, pero otra información afirma que Git ha alcanzado y superado a Mercurial al ofrecer herramientas de calidad para Windows y Visual Studio. ¿Alguien tiene buena información reciente o experiencia en probar ambos en un entorno de desarrollo .NET?

He estado usando Mercurial durante más de un año para hacer desarrollo de .NET, y ha estado funcionando muy bien. Admito que no uso ninguna de las herramientas sofisticadas (complementos de explorador y herramientas de Visual Studio), pero están disponibles (por ejemplo, TortoiseHg). He descubierto que usar las herramientas de command-line es igual de fácil: solo especifique algunos comodines en .hgignore (como en la respuesta de Blaenk ) y ya está listo.

No estoy seguro de cuán bien se integra git con hg, pero en el caso inverso he usado hg-git en el pasado y funcionó bien. Sin embargo, sigue siendo algo inestable a medida que salen nuevas versiones de hg.

Por lo tanto, debería poder usar github de mercurial, y para repositorys mercuriales nativos siempre existe el (imo) igualmente agradable bitbucket.org . Editar: Tenga en count también que codeplex , que se centra en proyectos de fuente abierta .NET, ahora ofrece repositorys Git y Mercurial.

Y debo mencionar que la "popularidad" es un criterio muy difícil para basar su elección. O bien DVCS tiene usuarios de alto perfil. Git tiene el kernel de Linux, por supuesto, mientras que los usuarios notables de hg incluyen los proyectos de Mozilla y Python.

EDITAR : ya que esto parece get votos ascendentes regulares. Todo lo que escribí arriba era cierto al momento de escribir, pero ya no estoy de acuerdo con mi anterior auto bitbucket es tan bueno como GitHub. GitHub tiene una mejor funcionalidad, y desde mi punto de vista (sobre todo desarrollo de código abierto F #) todos los demás están ahí para que obtengas mejores efectos de networking. Moví todo mi proyecto de codeplex / bitbucket a GitHub hace un time e inmediatamente comencé a recibir contribuciones, mientras que en codeplex / bitbucket casi nada sucedió.

Creo que dado el crecimiento de popularidad exponencial de git, la buena compatibilidad de git para Windows ( similar a la de la subversión con algo así como tortuga SVN ) está destinada a llegar, es solo cuestión de time. Los dos proyectos que parecen ser los más populares son msysgit y TortoiseGit (también usa msysgit) que es similar a tortugaSVN. git sigue volviéndose más y más popular, que si se topa con algún problema que ahora es poco probable y es aún más improbable a medida que las herramientas git en Windows se desarrollan aún más, podrá encontrar soluciones mucho más fáciles debido al gran tamaño usuario base.

Mientras tanto, he encontrado que esta serie de guías es muy útil.

Los problemas con los que se puede encontrar pueden estar ignorando ciertos files, lo que debería ser fácil si .gitignore cómo usar .gitignore , lo cual es muy sencillo, aquí está la list de files y comodines que la serie menciona:

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

También he visto algunos problemas con respecto a los finales de línea. Para eso, querrá ver esta pregunta .

En el momento de escribir estas líneas, he usado tanto TortoiseGit como TortoiseHg (para mercurial) en diferentes proyectos, principalmente proyectos Java y .net. Tengo que decir que TortoiseHg está a la cabeza, ya que es mucho más estable y con todas las funciones de los dos.

Existe un plugin de Mercurial para Visual Studio 2008 , pero sugiero que se quede con TortoiseHg hasta que el plugin sea estable. No estoy seguro acerca de la integración con git, pero se habla de un complemento para VS aquí .

Aunque git es un atractivo natural para los usuarios de Unix / Linux, ha ido mejorando para los usuarios de Windows y .net. mercurial sin embargo, puede ser una mejor opción entre los dos. a diferencia del desarrollador centralizado, donde hay una gran cantidad de opciones, hay muy pocas herramientas de hardware "verdaderas". por lo que sé, solo hay un sistema comercial, scm de plástico y las dos herramientas OSS antes mencionadas. Vengo del lado del claro y tengo experiencia con pvcs, p4 y otras herramientas scm tradicionales. me tropecé con el plástico, tal vez a través de este sitio y por lo que he evaluado, parece funcionar bien desde el punto de vista visual. si usted es más una tienda de Windows como dice, puede ser de plástico, mercurial y git en ese order. si eres más unix / linux, git es probablemente la primera opción lógica. ¡espero que esto ayude!

Tanto Git como Mercurial funcionarán bien para un desarrollador de .NET, pero es bien sabido que Mercurial tiene un mejor soporte de Windows. Además, si considera una herramienta comercial, ¿por qué no echa un vistazo a Plastic SCM leyendo el siguiente tutorial sobre desarrollo distribuido en Windows? http://codicesoftware.blogspot.com/2010/03/distributed-development-for-windows.html Actualizar ahora Plastic SCM tiene una Edición de comunidad GRATUITA.

No he usado a Mercurial en serio, pero acabo de cambiar a Git de Subversion para el desarrollo de .NET. La distribución que estoy usando es Git Extensions , que instala el estándar (msys) Git, además de una interfaz gráfica, algunas integraciones de Windows Explorer y un plugin de Visual Studio. También se envía con buenos documentos. La integración de Explorer no proporciona los nítidos marcadores de estado en los íconos de files que TortoiseSVN hace, sino que simplemente agrega los elementos esenciales al menu contextual. Todas estas herramientas funcionan bien.

El mayor problema que he encontrado es que Git requiere que entiendas los conceptos para get buenos resultados. Las interfaces gráficas de las Extensiones de Git son simplemente conchas finas sobre las instalaciones de Git, por lo que si tiene problemas con, digamos, submodules, entonces ninguna de las herramientas provistas por Git Extensions resolverá ese problema. Ahora hay montones de tutoriales y videos sobre Git en línea.

Por defecto, las comstackciones de Windows de Git convierten los finales de línea en CRLF; como somos completamente una tienda de MS, este es el comportamiento correcto para nosotros.

Git tiene una gran ventaja que le facilitará la vida al usar VS, la detección de cambio de nombre, si solo quiere usar la interfaz de Línea de Comando, en HG debe cambiar el nombre de los files cuando lo cambie de nombre en VS, en Git detectará sus cambios de nombre sin problemas (rastrea contenidos, no files), incluso si hace algunos cambios en el file, también detectará el cambio de nombre.