Hg post-merge commit message, best practice?

15

me encuentro haciendo lo siguiente mucho:Hg post-merge commit message, best practice?

C:\Code>hg pull 
pulling from http://server/FogBugz/kiln/Repo/Project/Rebuild/trunk 
searching for changes 
adding changesets 
adding manifests 
adding file changes 
added 2 changesets with 4 changes to 4 files (+1 heads) 
(run 'hg heads' to see heads, 'hg merge' to merge) 

C:\Code>hg merge 
4 files updated, 0 files merged, 0 files removed, 0 files unresolved 
(branch merge, dont forget to commit) 

C:\Code>hg commit -m "Merged" 

C:\Code>hg push 
pushing to http://server/FogBugz/kiln/Repo/Project/Rebuild/trunk 
searching for changes 
remote: kiln: successfully pushed 2 changesets

Mi pregunta es, ¿qué es una mejor/más útil mensaje de registro para usar después de la fusión de un tirón desde el repositorio. ¿Hay alguna mejor práctica que las personas usen en los sistemas de control de versiones distribuidas para este tipo de cosas?

Fuente

2010-10-20 automagic

+0

Suena como lo que hago ... Supongo que dos de nosotros (¡y todos los tipos con los que trabajo también!) Quizás no estén haciendo las mejores prácticas ... – jcolebrand

+0

En mi humilde opinión estos mensajes de combinación (y confirmaciones) son un defecto hg. En subversión tiene los mensajes de registro de las confirmaciones anteriores, luego svn up realiza una fusión automática y luego puede confirmar solo * sus * cambios, por supuesto, con el mensaje de registro correcto. Me gustaría en una versión futura de hg no solo tener mensajes de compromiso de fusión vacíos, sino también ningún evento en la línea de tiempo para eso. ¿Deberíamos usar siempre "hg pull --rebase" como se sugiere? ¿Me he perdido algo? por favor, indícame una explicación ... ;-). Saludos –

9

Si usa fetch extension automatiza la extracción, fusiona el paso en un solo paso, busca. El mensaje que genera automáticamente es algo similar a "fusión automática". Los desarrolladores de hg parecen pensar que esto es razonable ya que la extensión se distribuye ahora con la base.

Los mensajes de combinación no parecen contener una cantidad particularmente alta de información. Tu mensaje parece razonable.

[[offtopic, a veces utilizamos como una oportunidad para un juego de palabras con la palabra fusionar]]

Fuente

2010-10-20 21:02:56

+0

Perfecto, de hecho, ¡ya tenía esto instalado y ni siquiera lo sabía! ¡Gracias! – automagic

+1

La extensión de búsqueda atormenta su historial con mensajes de combinación sin sentido. Solo algo a considerar. –

+2

Solo para insertar una razón detrás de mi voto negativo: creo que la sugerencia de pyfunc de que den un "por qué" es realmente una mejor idea. Los míos tienden a ser cosas como "traer el número de corrección de errores de la rama de producción" o "extraer la nueva característica Y de Jim". La extensión de búsqueda se envía con mercurial, pero está desactivada por defecto y por una buena razón. –

6

No hay una sola manera, así que esto es lo que he tratado de cumplir.

En los mensajes de confirmación:

Jus recuerde que esos mensajes son las únicas cadenas que se conectarían a alguien que es tratar de descifrar las razones de la confirmación.

La clave es proporcionar una descripción que va a ser un comentario útil sobre el desarrollo de código. Entonces, cuando alguien usa el registro de hg, tiene un buen comentario sobre cómo se está desarrollando el software.

Algunas buenas prácticas:

se enlaza con un sistema de gestión de errores:

correcciones # 3456, nueva función # 2435 etc
o una más descriptivo uno de los cambios que se está trayendo el repositorio
dar créditos

De hecho, lo que hago principalmente es. Mire el estado actual de "hg log" y vea qué mensaje útil significaría una progresión lógica de para comprender el compromiso más reciente.

Fuente

2010-10-20 20:59:25 pyfunc

+0

buen consejo sobre el registro, no había pensado en eso – automagic

+0

Gracias por su respuesta. Seguimos una práctica muy similar y funciona muy bien. Intento basar mis propios mensajes en casos en los que he necesitado revisar la historia. En general, los mensajes que indican el objetivo principal del compromiso son los que me parecen más útiles. Más detalles más allá de eso en realidad pueden interponerse en el camino. – DaveInCaz

1

Se podría utilizar la extensión de rebase, por lo hg pull --rebase se rebase su cesión temporal a la punta de la repo central. Esto niega la necesidad de fusionarse después de un tirón.

he añadido un alias para ello:

[alias] 
pure = pull -u --rebase

funciona bien para nosotros.

Más detalles están en la página RebaseProject.

Fuente

2010-10-20 21:21:26

+1

Tenga en cuenta que esto tiene el mismo efecto que 'svn update', lo que significa que todavía está fusionando el código, simplemente se hace en segundo plano y sin una red de seguridad. Si la combinación falla debido a conflictos, no puede revertir e intentar nuevamente, debe extraer los cambios de los archivos .rej. También combina tus cambios con la fusión, por lo que algunos de los cambios que controlas también se fusionarán en los cambios de otras personas. TL; DR No tengas miedo de fusionarte, es más seguro. – tghw

+0

No utiliza archivos .rej. Guarda el paquete en la carpeta .hg, que puede desglosar si su operación va hacia el sur. Actualicé mi publicación con un enlace al RebaseProject, que proporciona más detalles. El análogo a 'svn update' es' hg pull -u'. Eche un vistazo a http://stackoverflow.com/questions/2354527/is-hg-pull-rebase-analogous-to-svn-update. No tengas miedo de probar algo diferente. –

0

Para fusiones mundanas, donde solo trabajas con un repositorio, creo que solo "fusionar" está bien. Por lo general, ni siquiera sabes todo lo que se fusionó porque de todos modos son los cambios de todos los demás.

La única vez que sugeriría ser más detallado sería cuando trabajas con más de un repositorio. Si tiene un repos de desarrollo y un repositorio estable, y está corrigiendo las correcciones de errores desde estable, solo mencionaría eso en la combinación: "fusionarse con estable". Esas fusiones tienden a ser más grandes, por lo que ayuda a explicarlas a las personas que llegan más tarde.

Fuente

2010-10-20 21:40:19 tghw

+0

Gracias por su respuesta.En la misma línea, lo bueno de la extensión fetch mencionada anteriormente es que hace exactamente eso; te dice exactamente qué repositorio extrajiste y fusionaste. – automagic

1

Puede recoger todos los conjuntos de cambios que acaba de agregar los mensajes de confirmación en un archivo por

$ hg log --rev 'reverse(p2():ancestor(p1(),p2())-ancestor(p1(),p2()))' \ 
     --template '{desc}\n' \ 
     > commit-message.txt

después editar manualmente cometer-message.txt, y finalmente utilizarlo como mensaje de registro:

$ hg commit -l commit-message.txt

Fuente

2012-09-07 13:49:57

2

Siempre y cuando "merg" esté en el mensaje de alguna manera, nos hemos divertido usando la oportunidad de llenar nuestros registros mercuriales con hilaridad. Por ejemplo, hemos utilizado mensajes de fusión tales como "préstamos de merchandising de bienes raíces están en su punto más bajo" o "una producción de televisión de Merge Griffin".

Fuente

2013-06-18 06:05:21 mstringer

+0

vea @mergemessage para ver un ejemplo – gabe

Hg post-merge commit message, best practice?

Respuesta

Cuestiones relacionadas