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

25

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.

version-control git mercurial Gregory Eric Sanderson
fuente
2
git tiene mucho poder habilitado de forma predeterminada, pero todos los que he hablado dicen que mercurial es más fácil de aprender, y me inclino a estar de acuerdo en base a mis experiencias al usar ambos. Y sí, las herramientas mercuriales son más fáciles de instalar en Windows en comparación con sus equivalentes git. Dicho esto, espera guiar a las personas y señalarles tutoriales durante la primera semana (o más ...).
wkl
1
Es probable que el uso de un DVCS desde el principio sea la forma más simple de administrar las contribuciones combinadas de múltiples contribuyentes que trabajan en paralelo. Si encuentra confusas las cabezas anónimas, no las use (mercurial admite ramas con nombre).
Stephen C. Steel
2
¿Es hora de volver a vincular a esta publicación de blog? Git es un Harrier Jump Jet .
sbi
1
Nunca entendí por qué todo el asunto "demasiado difícil de aprender" importa. De acuerdo, entonces toma 20 minutos aprender cómo comprometerse y ramificarse, en lugar de 10 ... ¿Gran cosa?
alternativa
1
Observe a (uno de ellos) pasar por hginit.com y tomar medidas basadas en sus reacciones.
chelmertz

Respuestas:

49

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.

Torre
fuente
44
+ para "VCS es una herramienta". No había considerado las "pequeñas cosas" como un factor, pero es cierto que cuando sumas pequeños problemas aquí y allá pueden convertirse en una verdadera molestia.
Gregory Eric Sanderson
8
"El sistema de control de versiones no debería ser algo que uno pase tiempo aprendiendo". Esto es un montón de basura. Siempre debe pasar tiempo aprendiendo sus herramientas. Pasas tiempo aprendiendo tu compilador; pero el VCS es una herramienta tan crítica para su programación como lo es su compilador.
JesperE
99
+1. Especialmente el argumento de 'ciudadano de segunda clase en Windows' es absolutamente importante en esta situación.
tdammers
+1 para "WTF (s) / minuto" ( osnews.com/story/19266/WTFs_m ). Estos niños deben aprender las habilidades :-)
Ross Patterson
1
@ Mark es solo el resultado de una diferencia de terminología ... Una sucursal en Git es realmente solo un nombre.
alternativa
10

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.

John Fisher
fuente
Siendo yo mismo un "adicto a la consola", nunca antes había usado las aplicaciones Tortoise {Svn, Git, Hg}, así que no sabía que TortoiseHg tenía un gráfico de rama. Tendré que ir a comprobar eso
Gregory Eric Sanderson
4

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.

Spencer Rathbun
fuente
He escuchado cosas buenas sobre fósiles, pero desafortunadamente no tengo tanto tiempo para familiarizarme con un nuevo DVCS. Prefiero usar algo a lo que estoy acostumbrado (si es posible) ya que ya sé cómo solucionar los escollos más comunes. Pero gracias por la sugerencia, definitivamente lo investigaré una vez que tenga tiempo.
Gregory Eric Sanderson
+1; El fósil es poco conocido, pero es tan fácil de trabajar y tan autónomo (dvsc + wiki + tickets + servidor web) que es una alternativa real a todo el trac o incluso github.
Javier
Pero los fósiles no se verán tan bien en el CV de los estudiantes como git o hg, ya que muy pocos lo tienen difícil.
Ian
Mercurial también ha incorporado la funcionalidad hg serve. Se echa de menos un rastreador de errores y wiki, por supuesto. Pero también hay bitbucket.com
Johannes Rudolph
3

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.

Stephen C. Steel
fuente
2

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.

dan_waterworth
fuente
+1 por mencionar hginit. Aunque, Pro Git también es bastante bueno.
Tamás Szelei
@ TamásSzelei, gracias, no había visto Pro Git antes.
dan_waterworth
0

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.

Mark Booth
fuente
No tiene que eliminar la rama git una vez que haya terminado; Es solo personalizado. También -1 para malinterpretar los usos del índice: no lo usa para organizar confirmaciones erróneas, lo usa para organizar pasos parciales de una serie más grande de confirmaciones. Por lo general, esto sucede durante un rebase cuando está limpiando su historial.
alternativa el
@mathepic: si no elimina los nombres de las sucursales y coloca todas sus ramas 'arregladas' locales en remoto, terminará con una gran cantidad de referencias, al igual que terminará con una gran cantidad de ramas antiguas en svn. En hgestos nombres de rama siempre son topológicamente locales, por lo que solo los verá si los busca.
Mark Booth el
@mathepic - En cuanto a tu -1, creo que estás malinterpretando lo que digo. No puedo imaginar por qué alguien intencionalmente haría un mal compromiso, pero con git es fácil hacerlo por accidente. Si se olvida de ese archivo cimplementa una interfaz modificada en el archivo i, y sin querer comprometerse el isin ccontinuación, si alguien tira en sus cambios antes de que haya encontrado el momento de cometer csu compilación fallará. Si usa el flujo de trabajo stash / compile / commit en su lugar, este error simplemente no va a suceder ya que su propia compilación se romperá primero. Sin embargo, he tratado de aclarar mi respuesta.
Mark Booth el