Si tengo un montón de cambios no confirmados y quiero dejarlos de lado mientras trabajo en otra cosa, y luego (después de varios días) volver a ellos y seguir trabajando. ¿Cuál sería el flujo de trabajo más sencillo para lograr esto? (Hasta ahora solo tengo experiencia con la funcionalidad básica de Mercurial). Mi método habitual era crear una nueva rama usando clon, pero podría haber mejores formas.
Respuestas:
Tienes varias opciones:
Guarde los artículos. Esto guarda los cambios y los elimina del directorio de trabajo para que la rama pueda continuar. No crea un conjunto de cambios.
hg shelve --all --name "UnfinishedChanges"
hg unshelve --name "UnfinishedChanges"
Actualizar / Editar : Es posible que sea necesario usar versiones más nuevas de mercurial
hg shelve -n "UnfinishedChanges"
hg unshelve "UnfinishedChanges"
Todavía puede usarlo --namecomo una alternativa -n, pero Mercurial ya no parece gustarle --name. Además, --allya no es necesario y Mercurial se asustará con él.
Ponga en cola los elementos usando mq. Esto no es muy diferente para archivarlo en algunos aspectos, pero se comporta de manera diferente. El resultado final es el mismo, los cambios se eliminan y, opcionalmente, se pueden volver a aplicar más tarde. Cuando se presionan, los parches son conjuntos de cambios lógicos, cuando se abren, se guardan en otro lugar y no forman parte del historial de conjuntos de cambios.
hg qnew "UnfinishedWork"
hg qrefresh
hg qpop
hg qpush "UnfinishedWork"
Confírmelos localmente, actualice al conjunto de cambios anterior y continúe trabajando y haga uso de ramas anónimas (o múltiples cabezas). Si luego desea los cambios, puede fusionar cabezas. Si no desea los cambios, puede eliminar el conjunto de cambios.
hg commit -m"Commiting unfinished work in-line."
hg update -r<previous revision>
hg strip -r<revision of temporary commit>
Confíelos a una rama con nombre. El flujo de trabajo pasa a ser el mismo que en la opción 3: fusionar o eliminar cuando esté listo.
hg branch "NewBranch"
hg commit -m"Commiting unfinished work to temporary named branch."
hg update <previous branch name>
Personalmente, uso la opción 3 o 4, ya que no me importa eliminar los conjuntos de cambios o registrar el código parcial (siempre que eso no se presione finalmente). Esto se puede utilizar junto con la nueva fase material de para ocultar sus conjuntos de cambios locales de otros usuarios si es necesario.
También utilizo el rebasecomando para mover conjuntos de cambios para evitar fusiones donde una fusión no agregaría nada al historial del código. Fusiones Tiendo a ahorrar para la actividad entre ramas importantes (como las ramas de lanzamiento) o la actividad de una rama de características de mayor duración. También está el histeditcomando que uso para comprimir conjuntos de cambios donde la "charla" de ellos reduce el valor.
Las colas de parches también son un mecanismo común para hacer esto, pero tienen semántica de pila. Usted empuja y abre parches, pero un parche que está "debajo" de otro parche en la pila requiere que el que está en la parte superior también se inserte.
Advertencia , al igual que con todas estas opciones, si los archivos tienen más cambios desde los cambios temporales que ha dejado en la estantería / en la cola / ramificado, se requerirá una resolución de fusión al deshacer la estantería / empujar / fusionar.
--allno se reconoce la opción . es un comportamiento predeterminado archivar todos los cambios de todos modos.
Personalmente, no me gusta ninguna de las respuestas publicadas hasta ahora:
shelvepara arreglos rápidos (solo para mover mis cambios no comprometidos a otra rama, si me doy cuenta de que estoy en la incorrecta). Estás hablando de días, de ninguna manera dejaría algo por días.mqes demasiado complicado para una situación tan ordinaria.Creo que la mejor manera es simplemente confirmar los cambios, luego volver al conjunto de cambios antes de comenzar estos cambios y trabajar desde allí. Hay algunos problemas menores, permítanme ilustrar:
Supongamos que tiene el conjunto de cambios A. Luego comienza los cambios. En este punto, debe dejarlo a un lado por un tiempo. Primero que nada, compromete tu trabajo:
hg ci -m "Working on new stuff"
Si lo desea, puede agregar un marcador para que sea más fácil volver más tarde. Siempre creo marcadores para mis ramas anónimas.
hg bookmark new-stuff
Regrese al conjunto de cambios antes de estas modificaciones
hg update A
Desde aquí, trabaja y genera el conjunto de cambios C. Ahora tiene 2 cabezas (B y C), se le advertirá cuando intente presionar. Puede enviar solo una rama especificando el encabezado de esa rama:
hg push -r C
O puede cambiar la fase de la new-stufframa a secreta. No se enviarán conjuntos de cambios secretos.
hg phase -r new-stuff --secret --force
mqes un poco complicado solo para esta situación, pero tiene una amplia gama de usos, incluido este, que vale la pena invertir el tiempo para dominarlo.
Para mantener los cambios locales no comprometidos, la forma más fácil para mí es guardarlos como un archivo de parche.
hg diff > /tmp/`hg id -i`.patch
y cuando necesite volver al estado anterior:
hg up <REV_WHERE_SAVED>
hg patch --no-commit /tmp/<REV_WHERE_SAVED>.patch
/tmpy hg id -itambién funcionará en Windoze.
hg upno se necesita allí.
Puede clonar su repositorio varias veces. Tiendo a tener un clon raíz, luego varios hijos de allí. Ejemplo:
Los 4 hijos son todos clonados desde la raíz y empujan / tiran hacia / desde la raíz. La raíz luego empuja / extrae del repositorio maestro en la red / Internet en algún lugar. La raíz actúa como una especie de área de preparación personal.
Entonces, en su caso, simplemente clonaría un nuevo repositorio y comenzaría a trabajar. Deje su trabajo 'archivado' solo en el otro repositorio. Es así de simple.
El único inconveniente es el uso de espacio en disco, pero si eso fuera una preocupación, no estaría usando DVCS en absoluto de todos modos;) Ah, y contamina la lista de "proyectos recientes" de Visual Studio, pero qué diablos.
[Editar los siguientes comentarios]: -
Para concluir entonces ... lo que estás haciendo está completamente bien y es normal. Yo diría que es la mejor manera posible de trabajar cuando se cumplen las siguientes condiciones: 1) es de corta duración 2) no es necesario colaborar con otros desarrolladores 3) los cambios no necesitan salir de su PC hasta que se confirmen / empujar el tiempo.