Acabo de empezar a usar Git junto con Mercurial para familiarizarme con Git.git equivalente a hg mq?
Uso la extensión mq en Mercurial extensivamente para administrar parches locales, y estoy buscando un equivalente de Git.
¿Debo simplemente usar la rama Git? ¿O hay mejores formas de administrar parches locales que permitan aplicar y eliminar fácilmente los parches?
Gracias,
Echa un vistazo a la sección "Capas de interfaz de gestión de parches" de la página Interfaces, Frontends And Tools en Wiki Git. No se enumeran dos interfaces de administración de parches, más o menos equivalente a 'mq' mercuriales extensión:
Pero si no necesita un uso más avanzado, puede utilizar en su lugar "git rebase --interactive" para reordenar, aplastar y dividir parches. Y para administrar su sucursal contra la versión actual de upstream, "git rebase" generalmente sería suficiente.
¿Puedes nombrar uno de esos "usos avanzados"? Creo que 'git rebase --interactive' prácticamente elimina la necesidad de algo como Mq. – kizzx2
** @ kizzx2: ** 'git rebase --interactive' te obliga a tratar toda la serie en secuencia. Con las interfaces de administración de parches, puede ir y venir fácilmente entre parches para editarlos. También puedes ver el historial de un cambio en el parche, agregar un nuevo compromiso en el medio de la serie, seleccionar otra confirmación, etc. –
@jakub, ¿'git checkout' te permitirá ir y venir entre commits? Lo que es tan fácil de administrar parches. El objetivo de git es que caminar durante los commits es fácil. –
Git realmente no proporciona esta característica. Dependiendo de tus usos, es posible que puedas arreglártelas con "git stash" y/o sucursales, pero será bastante básico. Si las personas tienen necesidades de administración de parches más avanzadas con git, parecen recurrir a Quilt o StGit: ver http://git.or.cz/gitwiki/PatchManagement
Simplemente use una rama y vuelva a ajustarla contra su rama ascendente con regularidad. Esto es más fácil de administrar y más seguro que usar mq (al cual he perdido datos en el pasado).
Descargo de responsabilidad: No soy un usuario de hg, así que he leído sobre hg pero no tengo mucha experiencia de primera mano al usarlo.
git proporciona varias herramientas muy potentes y flexibles para administrar ramas en un estilo 'patch queue', por lo que para muchos casos básicos (e incluso algunos bastante complejos), el git nativo es lo suficientemente potente.
Normalmente, la mayoría de los proyectos mantienen una rama principal estable central que solo adquiere nuevas confirmaciones y nunca se 'rebobina', por lo que las confirmaciones en la rama maestra son fijas.
Además de esto, un mantenedor (o un desarrollador) puede mantener una o más ramas fluidas de parches de trabajo en progreso (es decir, confirmaciones) que se basan en la rama estable.
Las actividades típicas Gestión de parche incluyen:
rebase la cola de parche sobre la rama estable lastest - utilizar git rebase,
la duplicación de la cola de parche sobre una antigua rama maintentance - utilizar git branch y git rebase,
reordenando parches en la cola - use git rebase --interactive (también conocido como git rebase -i) usando un editor de texto para reordenar la cola.
parches aplastando - git rebase -i utilizan con la directiva de squash
parches que alteran o parche se comprometen mensajes - utilizar git rebase -i (detectar un tema?) Con la directiva de edición.
Cualquier actividad que altere un parche de alguna manera (es decir, su contenido, descripción o paternidad) creará un nuevo compromiso con un nuevo id. De confirmación para ese parche. El hecho de que los antiguos commits puedan ser descartados y reemplazados regularmente antes de ser promovidos a la rama principal estable es lo único que los convierte en una "cola de parches" en lugar de una sucursal, pero esta es una convención de proyecto más que cualquier diferencia física en los datos que componen los commits. Para git son objetos idénticos.
Para promover un parche a una confirmación "real", simplemente mueva el parche al principio de la cola y fúndalo en la rama principal. Después de mover el parche al principio de la cola, es lo mismo que una confirmación normal basada en la rama maestra, por lo que al fusionarlo solo se avanza rápidamente el puntero de la rama maestra para apuntar a la confirmación del parche.
Publicar este compromiso como un parche maestro "estable" es el acto que dice: esto es ahora un compromiso que no cambiará y es parte de la historia inmutable del proyecto.
Generalmente utilizo Mercurial, pero esta es probablemente la mejor descripción de las ramas de git racionales que he visto. ¡Gracias! :) – rpjohnst
Una característica de Mercurial Queues que utilizo extensamente en un proyecto es "exportarlos" simplemente copiando el directorio .hg/patches. Ser capaz de almacenar y administrar los parches externamente desde el repositorio es crucial. Es cierto que este uso es altamente inusual, pero ¿tiene algo que proporcione una funcionalidad similar? –
@PaulMoore Solo tiene que hacer un parche de formato 'git' en los parches que quiera exportar, posiblemente hasta guardarlos en un archivo mbox si lo desea, así que puede hacer un' git am' para aplicarlos todos a la vez . – kyrias
Lo que pasa es que necesitamos tal cosa en git en una ocasión muy rara. – shabunc