¿Qué DVCS (git o hg) es más fácil para programar a los estudiantes? [cerrado]

Un poco de contexto: estoy en tercer año de universidad. los estudiantes se dividen en equipos de 4. Casi todos trabajarán bajo ventanas (excepto algunos como yo que están en Linux). Como parte del plan de estudios de la escuela, pronto comenzaremos a trabajar en un proyecto para un cliente real, pero otro equipo y yo nos preguntamos cuál sería la mejor manera de compartir nuestro código entre nosotros.

He trabajado a tiempo parcial durante 3 años y he tenido mucha experiencia usando git y mercurial en diferentes proyectos, por lo que no tengo ningún problema al usar un sistema u otro. Sin embargo, ninguno de mis compañeros de equipo ha usado un sistema de control de versiones antes. También hay otro equipo que ha intentado usar SVN pero ha tenido problemas importantes y preferiría probar otra cosa, por lo que me han pedido mi opinión.

Mis pensamientos: escuché que mercurial + TortoiseHg tiene una mejor integración bajo Windows, pero me pregunto si el concepto de cabezas anónimas podría confundirlos incluso si los explico. Por otro lado, encuentro que las ramas de git son más fáciles de entender para un principiante (separación clara del trabajo para cada programador) pero no funciona tan bien bajo Windows.

Mercurial, sin duda.

Por supuesto, esto es subjetivo y va de una persona a otra, pero la opinión general es que Mercurial es más fácil de asimilar, especialmente para alguien nuevo en VCS o alguien que viene de uno de los VCS de la generación anterior.

Puntos en mano:

1. Mercurial fue desarrollado con Windows en mente ; Git fue portado. No importa lo que alguien haya intentado decirme, Git sigue siendo un ciudadano de segunda categoría en Windows. Las cosas han mejorado sin dudas en los últimos años, pero aún se observan muchas disputas sobre por qué algo funciona o no funciona en Windows como lo hizo en * nix box. TortoiseHg funciona muy bien, y las implementaciones de Visual Studio son aún más fáciles de usar sin interrumpir su flujo de trabajo.

2. Si alguien comienza la discusión "Git es más poderoso después de ti ...", entonces lo está diciendo todo. Para el 95% de los usuarios, Mercurial parece más intuitivo. Comenzando por la falta de índice, a sus opciones más intuitivas (los interruptores de opciones son coherentes), a sus números locales para commits en lugar de hash SHA1 (¿quién pensó que los hash SHA1 son fáciles de usar?)

3. Las ramas de Mercurial no son menos poderosas que las de Git. Publicar describiendo algunas de las diferencias. Volver a alguna revisión anterior es tan simple como "actualizar la revisión anterior". A partir de ahí; solo haz un nuevo commit. Las ramas con nombre también están disponibles si se desea utilizarlas.

Ahora, sé que todos estos son detalles, y se pueden aprender y todo, pero la cosa es ... estas cosas se suman. Y al final, uno parece más simple e intuitivo que otro. Y el sistema de control de versiones no debe ser algo que uno pase tiempo aprendiendo: usted está allí para aprender a programar y luego a programar; VCS es una herramienta.

Solo para notar; Yo uso Git y Mercurial diariamente. No tenga problemas para usar ninguno de ellos. Pero cuando alguien me pide una recomendación, siempre recomiendo Mercurial. Aún recuerdo, cuando llegó por primera vez a mis manos, se sintió muy intuitivo. En mi experiencia, Mercurial solo produce menos WTF / minuto que Git.

Descubrí que la interfaz de usuario de TortoiseHg es una gran experiencia en Windows. Al experimentar con Git en el pasado, terminé yendo a la línea de comando. Para un usuario promedio, una buena interfaz de usuario es mucho más accesible que una línea de comando. Entonces, sugeriría usar Mercurial. (También incluye un bonito gráfico de rama en la ventana del banco de trabajo. Debería aclarar cualquiera de las dificultades básicas de ramificación).

Una vez que entienden las cosas desde la perspectiva de la interfaz de usuario, pueden terminar yendo a la línea de comando para hacer un script o realizar operaciones manuales, pero no es necesario.

Si estás interesado en una tercera opción, te sugiero fósiles . Creo que la capacidad de lanzar un servidor web temporal para compartir código funciona muy bien en pequeños proyectos. Fossil es solo un ejecutable, por lo que puede ponerlo junto con su fuente en una memoria USB y usarlo desde cualquier computadora de la universidad.

Úselo fossil uipara iniciar un servidor web temporal donde quiera que sus compañeros se sincronicen con usted. También le ofrece un sistema de tickets, wiki y una interfaz web fácil de usar para cambiar ramas y etiquetar confirmaciones.

Solo asegúrese de que lean la guía de inicio rápido y / o el libro . Finalmente, hay un proyecto llamado winFossil para darles una interfaz de usuario más amigable que la interfaz de usuario web.

Dado que los equipos son nuevos en el control de versiones y muchos usan Windows, recomendaría mercurial sobre git.

El modelo conceptual de control de versiones utilizado por git y mercurial es muy similar, por lo que una vez que domine uno, es fácil elegir el otro (y por razones similares, es bastante fácil convertir un repositorio de uno a otro) . Esto significa que no es gran cosa si cambias de opinión más tarde.

En mi opinión, mercurial es más fácil de aprender para los nuevos usuarios. Hace que las cosas simples sean fáciles y las peligrosas difíciles. Git hace que las operaciones peligrosas sean fáciles (¡fácil de hacer, no necesariamente fácil de hacer correctamente!).

La interfaz TortoiseHg para Winodows también es muy agradable, y es otro argumento a favor del uso de mercurial.

Mi preferencia personal es para git.

Sin embargo, como algunas personas usarán Windows y la excelente existe tutorial hginit , recomendaría enseñarles mercurial.

Como muchas personas han sugerido, Mercurial través de TortoiseHg tiene una barrera de entrada muy baja.

Para aquellos en Windows, es un solo instalador en lugar de dos instaladores (y un montón de cosas de las que quizás no quieran aprender) y la interfaz de usuario THg está mucho más pulida que TortoiseGit + Msysgit .

Cabezas anónimas

Si crees que se confundirían con cabezas anónimas, no fomentes su uso. Máshg libros adoptan un enfoque equilibrado y enseñan ramas topológicas y con nombre, y permiten al lector determinar cuál es el más apropiado para su uso.

Ramas nombradas

Una cosa que realmente extraño gitson hglas ramas con nombre , así que esa es una opción.gitlas ramas están bien mientras trabaja en ellas, pero una vez que ha fusionado ese trabajo en otra rama, pierde gran parte del contexto de esos cambios.

En hgpodría crear una rama llamada Jira#1234y siempre poder encontrar todas las revisiones asociadas con esa corrección . En git, una vez que se ha fusionado su rama y se ha eliminado la referencia, debe inferir qué revisiones fueron parte de la corrección de la topología del árbol de revisiones. Incluso si no elimina la referencia, solo conoce la última confirmación en esa rama, no cuáles de sus antepasados ​​fueron parte de esa cadena de confirmaciones.

Marcadores

Alternativamente, si no desea usar ramas con nombre, pero desea un gitflujo de trabajo de estilo con sus ramas anónimas, puede usar marcadores lugar.

Este podría ser el mejor de ambos mundos: pueden aprender un gitflujo de trabajo, pero pueden usar los hgcomandos más simples .

Área de índice / caché / puesta en escena

Personalmente, creo que es mucho más probable que los estudiantes se confundan con el área gitde índice / caché / puesta en escena que con hglas cabezas anónimas. Prefiero hghacer que esta funcionalidad avanzada sea opcional en la línea de comandos, por gitsupuesto supone que siempre desea / necesita usarla.

También creo que el área de ensayo fomenta los commits que no han sido probados ni compilados. Dado que muchos de los lugares en los que he trabajado han tenido una regla de no confirmar si no compila , preferiría archivar / guardar los cambios que no quiero en este momento, volver a ejecutar pruebas unitarias y confirmar una versión que Sé compilaciones.

Cuando más tarde encuentres un error usando hg bisect o git bisect , te agradecerás que puedas probar todas las revisiones, no solo las que compilan.