tag practices name drop delete commits commands best git mercurial

name - git tags best practices



Git/Mercurial(hg) opinión (10)

En primer lugar, permítanme decir que no soy un programador profesional, sino un ingeniero que tenía una necesidad y que tenía que aprender. Siempre trabajé solo, así que fuimos solo yo y mis siete personalidades divididas ... y trabajamos muy bien como equipo :) La mayoría de mis cosas se hace en C / Fortran / Matlab y hasta ahora he estado aprendiendo git to administrarlo todo. Sin embargo, aunque no he tenido problemas irresolubles, nunca he estado "feliz" con eso ... por todo lo que no puedo hacer, tengo que buscar un libro. Y, desde hace un tiempo, he estado escuchando muchas cosas buenas sobre Mercurial.
Ahora, un colega mío tendrá que trabajar conmigo en un proyecto (casi lo siento por él) y comenzó a aprender Mercurial (dice que le gusta más), y estoy considerando el cambio yo mismo.

Trabajamos casi exclusivamente en la plataforma Windows (aunque administro relativamente bien usando herramientas Unix y cosas que provienen de esa parte del mundo).

Entonces, me preguntaba, en un escenario descrito, qué problemas podría esperar con el cambio. Escuché que Mercurial es bastante más fácil de usar para los usuarios de Windows, con respecto a las interfaces de usuario.

¿Cómo maneja los repositorios? ¿Los crea de la misma manera que git (solo un subdirectorio en un directorio de trabajo) y puedo copiar todo el directorio del proyecto (incluido git repo) y simplemente llevarlos a otro lugar sin pensarlo? (Realmente me gustó eso cuando elegí git / svn).

¿Hay algún buen libro que puedas recomendar (algo así como Pro Git, solo para Mercurial)?

Cuáles son buenas maneras de implementar Mercurial en Visual Studio / GVim para Windows o en el Explorador de Windows para que pueda trabajar con relativa facilidad (me gustaría evitar usar la línea de comandos para todo lo relacionado con él, como en git shell).

¿Hay algo más de lo que deba estar al tanto? (Por favor, no me dirijan a otras preguntas ... simplemente me dan un montón de información, y no estoy seguro de qué es lo que debería tomar como importante, y qué ignorar). Intento recortar algo de tiempo, ya que no puedo perder todo ese tiempo volviendo a aprender Mercurial, como hice por git.

También escuché que git es c project, mientras que mercurial es python ... ¿hay alguna diferencia notable en la velocidad? git fue bastante rápido ... me encontraré esperando mientras trabajo.

Aviso: Todos mis proyectos son, digamos, de tamaño medio ... en su mayoría simulaciones numéricas ... 10-15000 líneas (tamaño mediano?)

En cuanto a tus puntos:

  • Mercurial es mejor para los usuarios de Windows, más fácil de instalar, sin corrupción terminal absurda :) - básicamente más con menos trabajo, en mi humilde opinión.
  • Git es más rápido que Mercurial - los puntos de referencia muestran esto. Esto es, como dijiste, porque Git está escrito en C. Sin embargo, no encuentro a Mercurial tan lento para ser honesto.
  • Si su amigo usa Mercurial, use Mercurial para ese proyecto. Son muy similares en su interfaz básica y funcionalidad: podría recoger Hg muy fácilmente viniendo de Git.
  • Puedo estar equivocado, pero mi percepción es que Git tiene una comunidad de usuarios más grande, probablemente debido a que es utilizada por el kernel de Linux.
  • Gracias a los comentaristas: Git tiene Github , uno de los mejores sitios de alojamiento de código de la historia . (¡Créeme!)
  • Muchos proyectos de alto perfil usan Git (kernel, Rails, JQuery), la página de repositorios de Github es interesante. ¡Estoy sorprendido de cuántos proyectos reconozco y uso a diario con Git!
  • Mercurial tiene un muy buen tutorial escrito por Joel Spolsky en hginit.com . ¡Es el mejor tutorial sobre control de fuentes que jamás haya leído! :)

Git Pros:

  • Ultrafast (escalas de proyectos muy grandes)
  • Flexibilidad extrema
  • C herramientas que encajan bien con la filosofía de Unix

Git Contras:

  • Curva de aprendizaje empinada
  • Existen herramientas GUI, pero (IMO) no son tan sólidas

HG Pros:

  • Muy rápido (aunque no tan rápido como GIT) - Las demoras no deberían ser un problema significativo en un proyecto de 15-20k líneas
  • Buenas herramientas GUI, incluso en Windows (TortoiseHg es bueno y muy maduro, y hay otros también)
  • Bien documentado, e incluso la versión de Windows tiene una buena GUI con una vista gráfica de conjuntos de cambios
  • Curva de aprendizaje un poco más fácil que GIT (imo)

HG Contras:

  • Algo más lento que git
  • Posiblemente un poco menos flexible

Hay otras diferencias significativas, pero estas son las más importantes en mi mente. Honestamente, si estuviera trabajando principalmente en Windows, probablemente iría con Mercurial.

Si estás contento con git, dudo que haya una razón realmente convincente para cambiar, aunque me gusta mucho Hg. Git tiene TortoiseGit / GitCheetah, aunque creo que TortoiseHg es un poco mejor y estable en mi humilde opinión.

Es posible que desee ver este video gratuito utilizando Hg y TortoiseHg (así como el complemento Visual Studio Hg) en tekpub / codeplex . El video te dará una idea de Hg.

Me gustaría decir algo sobre el tema de los puntos de referencia. Hay un dicho que me gusta: "Nunca confíes en un punto de referencia que no hayas falsificado tú mismo" :-)

Sí, la wiki de Git enumera los puntos de referencia que te dicen que Git es más rápido. Deberías tomar todos los puntos de referencia con un grano de sal y dos granos si provienen de uno de los contendientes. Por ejemplo, estos puntos de referencia de Git se toman en un repositorio limpio de Git, pero no incluyen el tiempo necesario para limpiarlo.

Verá, Git tiene dos formatos de repositorio: uno es muy rápido para hacer commits, pero es extremadamente ineficiente en el espacio y a medida que el repositorio aumenta de tamaño, otras operaciones se vuelven más lentas. Es por eso que agregaron un segundo formato de repositorio que limpia los archivos no utilizados y almacena los datos de manera más eficiente, lo que reduce la huella y mejora el rendimiento. Esto es lo que hace el comando "git-gc" ("gc == recolección de basura").

Entonces adivina que pasa? Cuando un punto de referencia de Git informa un tiempo de compromiso rápido, es decir, con un formato, y cuando informan una huella pequeña o alguna operación rápida, es decir, con el segundo formato. Y ninguno de los benchmarks muestra el costo del ciclo de recolección de basura. El resultado es que Git está hecho para verse más rápido.

Nota, no estoy diciendo que Git sea lento. Pero creo que los puntos de referencia en el sitio web de Git sobreestiman su velocidad, y en particular, no estoy seguro de que Git sea realmente más rápido que Mercurial.

Mercurial usa un formato eficiente que le da un tiempo de compromiso "casi" tan rápido como el formato "gordo" de Git, y un tamaño de disco "casi" tan pequeño como el formato "delgado" de Git, sin el costo del ciclo de recolección de basura en Entre.

Por supuesto, otra forma en que nunca se debe confiar en los puntos de referencia es que hay muchos aspectos en el rendimiento y las personas tienden a informar los que se ajustan a sus ideas preconcebidas. Por ejemplo, podría señalar que cuando salió Google Code solo admitieron a Mercurial y no a Git porque el rendimiento de Git era demasiado pobre en comparación con Mercurial. Pero entonces, estaría omitiendo el hecho de que esto era específicamente un problema con el rendimiento en lugar de http.

Lo tomaré punto por punto ...

Considero que Hg es relativamente intuitivo, fácil de usar y, cuando eso falla, está bien documentado.

Mercurial tenía una ventaja en Windows, pero creo que Git también mejoró allí, así que probablemente no sea un buen diferenciador.

En lo que respecta a las interfaces de usuario, puede considerar que TortoiseHg (la integración de shell de Windows que mencionó) sea útil si no le gusta la línea de comando. Trabajando en Windows, no te culpo. :)

Mercurial crea repositorios de la misma manera que Git: uno, subdirectorio oculto bajo la raíz direcory. Puedes moverlo como quieras (ponerlo en un bastón, llevarlo a otra parte, etc.) ¿Por qué fue un problema con svn?

Me alegra decir que, considerando que Hg es una herramienta para hacer un trabajo, no he sentido la necesidad de encontrar un "buen libro". Puede haber algunos, pero los documentos en línea disponibles fueron más que adecuados para lo que quería hacer.

Mientras que Git cuenta con su velocidad, no está claro si es más rápido que Mercurial, pero el punto es discutible: de todos modos, son muy rápidos.

Para parafrasear mi propia publicación de blog sobre el tema, lo que creo que importa mucho es que Git no puede cambiar su reputación por ser difícil de trabajar. Una cita que encontré unas cuantas veces ilustra esto mejor que cualquier cosa que me viene a la mente: "¡Git ha cambiado, hombre! No es como solía ser, ¡ahora es totalmente intuitivo! ¡Solo tienes que aprender cómo almacena los datos!

Para concluir, soy un usuario de Mercurial (no he usado Git, pero lo he leído un poco) y es raro que disfrute el uso de un producto de software porque el 95% o más del tiempo, son crudos, tienen bordes irregulares , errores, etc. ¡Mercurial es realmente una solución que disfruto usar y lo recomiendo!

He estado usando git y mercurial alternativamente durante aproximadamente 3 años. Recomiendo mercurial si necesita un sistema de control de fuente estable. Tuvimos graves problemas de estabilidad cuando git usó con Atlassian Stash . Entonces pasamos a mercurial y usamos SCM como capa de autorización.

En primer lugar, permítanme decir que no soy un programador profesional, sino un ingeniero que tenía una necesidad y que tenía que aprender.

Ingeniero aquí, también. He usado Mercurial, Subversion, BitKeeper y CVS. Aún no he llegado a Git.

Escuché que hg es bastante más fácil de usar para los usuarios de Windows, con respecto a las interfaces de usuario.

No estoy seguro de lo que se quiso decir aquí, Git y Mercurial son herramientas de línea de comandos en el corazón.

¿Cómo maneja los repositorios?

Es un sistema de control de versiones distribuidas (DVCS), al igual que Git.

¿Los crea de la misma manera que git (solo un subdirectorio en un directorio de trabajo) y puedo copiar todo el directorio del proyecto (incluido git repo) y simplemente llevarlos a otro lugar sin pensarlo? (Realmente me gustó eso cuando elegí git / svn).

Sí. El repositorio de Mercurial vive en un directorio .hg en el directorio de trabajo. Además, Mercurial tiene un sistema de nombres en su repositorio para evitar colisiones de nombre de archivo si lo usa con un sistema de archivos insensible a mayúsculas y minúsculas como FAT, NTFS o HFS +.

¿Hay buenos libros que puedas recomendar (algo así como Pro Git, solo para Hg)?

Yo recomendaría el sitio web: https://www.mercurial-scm.org/guide

Cuáles son buenas maneras de implementar hg en Visual Studio / GVim para Windows, o en el Explorador de Windows para que pueda trabajar con relativa facilidad (me gustaría evitar usar la línea de comandos para todo lo relacionado con él, como en git shell).

Hay una herramienta llamada TortoiseHG . No puedo dar fe de lo bueno que es, ya que suelo usar la versión de línea de comandos a través de Cygwin.

También escuché que git es c project, mientras que mercurial es python ... ¿hay alguna diferencia notable en la velocidad? git fue bastante rápido ... me encontraré esperando mientras trabajo.

Mercurial es bastante rápido. No sé cómo se acumula con Git, pero es mucho más rápido que Subversion.

Aviso: Todos mis proyectos son, digamos, de tamaño medio ... en su mayoría simulaciones numéricas ... 10-15000 líneas (tamaño mediano?)

Suena como mis cosas. Sin contar los datos sin procesar, por supuesto.

Y fuera del tema ...

La mayoría de mis cosas se hace en C / Fortran / Matlab y hasta ahora he estado aprendiendo git para administrarlo todo.

Me he mudado de Matlab a Python recientemente ...

  • Sin preocupaciones de licencia y mantenimiento.
  • Es todo de código abierto.
  • NumPy, SciPy y MatPlotLib hacen la mayor parte de lo que necesito.
  • Puedo tomar mi código e integrarlo fácilmente con un código basado en socket para hablar con la instrumentación. (Me encanta poder generar una forma de onda, descargarla a un generador de funciones, esperar a que se active el alcance, tomar su rastro y estadísticas, y poner todo eso en un bucle).
  • Puedo integrarlo con PyGtk, PyQt, un servidor web, un generador de PDF (ReportLib) y quién sabe qué más.
  • Puedo enviar mi código basado en Python sin tener que lidiar con licencias o regalías.
  • Python es mucho mejor para el desarrollo de software disciplinado que Matlab. El material de Matlab de una función por archivo y un directorio por clase es una locura.
  • Python es más fácil de extender con código C y C ++. Las bibliotecas por ahí son mejores.

Solo un pensamiento.

AÑOS DESPUÉS EDIT: hay una herramienta Mac DVCS llamada SourceTree con la que estoy muy contento. Es compatible con Git y Mercurial, y está disponible de forma gratuita en la App Store.

Mi transición de Git a Mercurial ha sido mucho más fácil después de leer una guía de ramificación en Mercurial , que también se refiere a la forma de ramificación de Git.

Si tiene IIS 7, puede configurar fácilmente un servidor Mercurial: configurar un servidor Mercurial bajo IIS7 en Windows Server 2008 R2 , y puede encontrar fácilmente tutoriales usando IIS 6 o Apache2. Por supuesto, para una sincronización rápida, el hg serve es invaluable: usar "hg serve" para impulsar los cambios

Integración de Visual Studio:

Alojamiento gratuito:

Para obtener guías y tutoriales, puede comenzar en la wiki de Mercurial .

Realmente no puedo hablar de Mercurial, pero puedo confirmar que git está escrito en C. Eche un vistazo a la gitweb de la fuente.

En cuanto a necesitar la línea de comandos para todo lo relacionado con git, no necesariamente es necesario. Hay una herramienta llamada TortoiseGit que se integra con el shell del explorador y administrará tus repositorios git por ti; si usas Eclipse, también hay EGit . En Linux, hay QGit aunque la CLI es mucho más poderosa.

Soy un desarrollador de Linux / C y, naturalmente, prefiero Git; También he oído cosas buenas de Mercurial, nunca me he molestado en aprenderlo.