ver tag oneline modificados log crear archivos git github changelog

oneline - git tag



Buenas formas de administrar un registro de cambios con git? (12)

He estado usando Git por un tiempo, y recientemente comencé a usarlo para etiquetar mis lanzamientos para poder realizar un seguimiento más fácil de los cambios y poder ver qué versión están ejecutando cada uno de nuestros clientes (desafortunadamente el código exige actualmente que cada cliente tiene su propia copia del sitio PHP; estoy cambiando esto, pero es lento).

En cualquier caso, estamos comenzando a construir algo de impulso, pensé que sería muy bueno poder mostrarle a la gente lo que ha cambiado desde la última versión. El problema es que no he estado manteniendo un registro de cambios porque no tengo una buena idea de cómo hacerlo. Para este momento en particular, puedo ejecutar el registro y crear uno manualmente, pero eso se agotará muy rápidamente.

Intenté buscar en Google "git changelog" y "git manage changelog", pero no encontré nada que realmente hablara sobre el flujo de trabajo de los cambios de código y cómo eso coincide con el registro de cambios. Actualmente estamos siguiendo el flujo de trabajo de desarrollo de Rein Henrichs y me encantaría algo que vaya junto con eso.

¿Existe un enfoque estándar que me falta, o es este un área donde todos hacen lo suyo?

Muchas gracias por sus comentarios / respuestas!

Basado en bithavoc , enumera la last tag hasta HEAD . Pero espero enumerar los registros entre 2 etiquetas.

// 2 or 3 dots between `YOUR_LAST_VERSION_TAG` and `HEAD` git log YOUR_LAST_VERSION_TAG..HEAD --no-merges --format=%B

Lista de registros entre 2 etiquetas.

// 2 or 3 dots between 2 tags git log FROM_TAG...TO_TAG

Por ejemplo, v1.0.1 registros de v1.0.0 a v1.0.1 .

git log v1.0.0...v1.0.1 --oneline --decorate

Dado que la mejor práctica es crear una etiqueta por versión, es posible que desee dividir su registro de cambios por versión. En ese caso, este comando podría ayudarlo a:

git log YOUR_LAST_VERSION_TAG..HEAD --no-merges --format=%B

El gitlog-to-changelog es útil para generar un ChangeLog estilo GNU.

Como se muestra en gitlog-to-changelog --help , puede seleccionar los commits usados ​​para generar un archivo ChangeLog usando cualquiera de las opciones --since :

gitlog-to-changelog --since=2008-01-01 > ChangeLog

o pasando argumentos adicionales después de -- , que se pasará a git-log (llamado internamente por gitlog-to-changelog ):

gitlog-to-changelog -- -n 5 foo > last-5-commits-to-branch-foo

Por ejemplo, estoy usando la siguiente regla en el Makefile.am de nivel superior de uno de mis proyectos:

.PHONY: update-ChangeLog update-ChangeLog: if test -d $(srcdir)/.git; then / $(srcdir)/build-aux/gitlog-to-changelog / --format=''%s%n%n%b%n'' --no-cluster / --strip-tab --strip-cherry-pick / -- $$(cat $(srcdir)/.last-cl-gen).. / >ChangeLog.tmp / && git rev-list -n 1 HEAD >.last-cl-gen.tmp / && (echo; cat $(srcdir)/ChangeLog) >>ChangeLog.tmp / && mv -f ChangeLog.tmp $(srcdir)/ChangeLog / && mv -f .last-cl-gen.tmp $(srcdir)/.last-cl-gen / && rm -f ChangeLog.tmp; / fi EXTRA_DIST += .last-cl-gen

Esta regla se usa en el momento del lanzamiento para actualizar ChangeLog con los últimos mensajes de confirmación aún no grabados. El archivo .last-cl-gen contiene el identificador SHA1 de la última confirmación registrada en ChangeLog y se almacena en el repositorio de Git. ChangeLog también se registra en el repositorio, de modo que se puede editar (por ejemplo, para corregir errores tipográficos) sin alterar los mensajes de confirmación.

Esto fue hace unos 3-4 años, pero por el bien de los buscadores futuros, ahora es posible generar magníficos registros con:

git log --oneline --decorate

O, si lo quiere aún más bonito (con color para terminal):

git log --oneline --decorate --color

Las tuberías que dan salida a ChangeLog es lo que uso actualmente en todos mis proyectos, es simplemente increíble.

Para los proyectos de GitHub podría ser útil: github-changelog-generator

Genera un registro de cambios de problemas cerrados de etiquetas y solicitudes de extracción combinadas.

Este CHANGELOG.md fue generado por este script.

Ejemplo:

Registro de cambios

1.2.5 (2015-01-15)

Registro de cambios completo

Mejoras implementadas:

  • Usar hito para especificar en qué versión de error se corrigió #22

Errores arreglados:

  • Error al intentar generar registro para repos sin etiquetas #32

Solicitudes de extracción combinadas:

  • La clase PrettyPrint está incluida en minúsculas ''pp'' #43 ( schwing )

  • soporte empresarial github a través de opciones de línea de comando #42 ( glenlovett )

Para un registro de cambios de estilo GNU , he cocinado la función

gnuc() { { printf "$(date "+%Y-%m-%d") John Doe <[email protected]>/n/n" git diff-tree --no-commit-id --name-only -r HEAD | sed ''s/^//t* /'' } | tee /dev/tty | xsel -b }

Con este:

  • Confirmo mis cambios periódicamente para realizar una copia de seguridad y volver a establecer una base de ellos antes de realizar la edición final de ChangeLog
  • luego ejecuta: gnuc

y ahora mi portapapeles contiene algo como:

2015-07-24 John Doe <[email protected]> * gdb/python/py-linetable.c (): . * gdb/python/py-symtab.c (): .

Luego uso el portapapeles como punto de partida para actualizar ChangeLog.

No es perfecto (por ejemplo, los archivos deben ser relativos a su ruta ChangeLog, por lo que python/py-symtab.c sin gdb/ ya que python/py-symtab.c el gdb/ChangeLog ), pero es un buen punto de partida.

Scripts más avanzados:

Sin embargo, tengo que estar de acuerdo con Tromey: duplicar los datos de confirmación de git en ChangeLog es inútil.

Si va a hacer un registro de cambios, haga un buen resumen de lo que está sucediendo, posiblemente como se especifica en http://keepachangelog.com/

Permití que el servidor de CI insertara lo siguiente en un archivo llamado CHANGELOG para cada nueva versión con la fecha establecida en el nombre de archivo de la versión:

>git log --graph --all --date=relative --pretty=format:"%x09 %ad %d %s (%aN)"

Puedes usar algo del registro de git para ayudarte:

git log --pretty=%s # only print the subject

Si asigna un nombre adecuado a sus ramas, de modo que una fusión con el máster se muestre como "Función de rama combinada-foobar", puede acortar las cosas mostrando solo ese mensaje, y no todos los pequeños commits que fusionó, que juntos forman el característica:

git log --pretty=%s --first-parent # only follow first parent of merges

Es posible que pueda aumentar esto con un script propio, que podría hacer cosas como quitar los bits de la "Fusión fusionada", normalizar el formateo, etc. En algún momento, debe escribirlo usted mismo, por supuesto.

Luego, podría crear una nueva sección para el registro de cambios una vez por versión:

git log [opts] vX.X.X..vX.X.Y | helper-script > changelogs/X.X.Y

y cometer eso en la versión de su versión commit.

Si su problema es que esas asignaturas de compromiso no se parecen en nada a lo que le gustaría poner en un registro de cambios, tiene prácticamente dos opciones: seguir haciendo todo de forma manual (e intentar seguirlo más regularmente en lugar de jugar catch- en el momento del lanzamiento), o arregle su estilo de mensaje de confirmación. Una opción, si los sujetos no lo van a hacer por usted, sería colocar líneas como "cambio: función añadida foobar" en el cuerpo de los mensajes de confirmación, para que luego pueda hacer algo como git log --pretty=%B | grep ^change: git log --pretty=%B | grep ^change: para captar solo esos bits súper importantes de los mensajes.

No estoy del todo seguro de cuánto más que ese git realmente podría ayudarlo a crear sus registros de cambios. ¿Tal vez malinterpreté lo que quiere decir con "administrar"?

Una más al punto CHANGELOG. Dime si a ti les gusta.

git log --since=1/11/2011 --until=28/11/2011 --no-merges --format=%B

DESCARGO DE RESPONSABILIDAD: soy el autor de gitchangelog de lo que gitchangelog continuación.

TL; DR: Es posible que desee comprobar el registro de cambios de gitchangelog o la salida de ASCII que generó el anterior.

Si desea generar un registro de cambios desde su historial de git, probablemente deba considerar:

  • el formato de salida . (ASCII personalizado puro, tipo de registro de cambios de Debian, Markdow, ReST ...)
  • algunos se comprometen a filtrar (es probable que no quiera ver todos los errores tipográficos o cosméticos en su registro de cambios)
  • algunas disputas de texto de compromiso antes de ser incluidas en el registro de cambios. (Asegurando que la normalización de los mensajes tenga una primera letra mayúscula o un punto final, pero también podría estar eliminando alguna marca especial en el resumen)
  • ¿Tu historial de git es compatible ? Fusionar, etiquetar, no siempre es tan fácilmente compatible con la mayoría de las herramientas. Depende de cómo administre su historial.

Opcionalmente, es posible que desee cierta categorización (cosas nuevas, cambios, correcciones de errores) ...

Con todo esto en mente, creé y gitchangelog . Tiene la intención de aprovechar una convención de mensajes de cometer git para lograr todos los objetivos anteriores.

Tener una convención de mensajes de compromiso es obligatoria para crear un buen registro de cambios (con o sin usar gitchangelog ).

cometer convención de mensajes

Las siguientes son sugerencias sobre lo que podría ser útil para agregar en sus mensajes de confirmación.

Es posible que desee separar aproximadamente sus compromisos en secciones grandes:

  • por intención (por ejemplo: nuevo, corregir, cambiar ...)
  • por objeto (por ejemplo: doc, packaging, código ...)
  • por audiencia (por ejemplo: dev, tester, usuarios ...)

Además, puede querer etiquetar algunas confirmaciones:

  • como commits "menores" que no deberían ser superados en su registro de cambios (cambios estéticos, pequeños errores en los comentarios ...)
  • como "refactor" si realmente no tiene cambios significativos en las características. Por lo tanto, esto no debería ser parte del registro de cambios que se muestra al usuario final, por ejemplo, pero podría ser de interés si tienes un registro de cambios del desarrollador.
  • también puedes etiquetar con "api" para marcar cambios de API o nuevas cosas de API ...
  • ... etc ...

Intente escribir su mensaje de compromiso apuntando a los usuarios (funcionalidad) tan a menudo como sea posible.

ejemplo

Este es el git log --oneline estándar de git log --oneline para mostrar cómo se puede almacenar esta información ::

* 5a39f73 fix: encoding issues with non-ascii chars. * a60d77a new: pkg: added ``.travis.yml`` for automated tests. * 57129ba new: much greater performance on big repository by issuing only one shell command for all the commits. (fixes #7) * 6b4b267 chg: dev: refactored out the formatting characters from GIT. * 197b069 new: dev: reverse ``natural`` order to get reverse chronological order by default. !refactor * 6b891bc new: add utf-8 encoding declaration !minor

Entonces, si lo has notado, el formato que elegí es:

{new|chg|fix}: [{dev|pkg}:] COMMIT_MESSAGE [!{minor|refactor} ... ]

Para ver un resultado de salida real, puede ver el final de la página PyPI de gitchangelog

Para ver una documentación completa de mi convención de mensajes de compromiso, puede ver el archivo de referencia gitchangelog.rc.reference

Cómo generar un registro de cambios exquisito a partir de este

Entonces, es bastante fácil hacer un registro de cambios completo. Podrías crear tu propio script bastante rápido, o usar gitchangelog .

gitchangelog generará un registro de cambios completo (con soporte de sección como New , Fix ...), y es razonablemente configurable para sus propias convenciones de confirmación. Es compatible con cualquier tipo de salida gracias a la creación de plantillas a través de Mustache , Mako templating , y tiene un motor heredado predeterminado escrito en raw python; todos los 3 motores actuales tienen ejemplos de cómo usarlos y pueden mostrar los registros de cambios como el que se muestra en la página PyPI de gitchangelog.

Estoy seguro de que usted sabe que hay muchos otros git log para herramientas de git log de changelog también.

git log --oneline --no-merges `git describe --abbrev=0 --tags`..HEAD | cut -c 9- | sort

Es lo que me gusta usar Obtiene todos los commits desde la última etiqueta. cut se deshace del commit hash. Si usa números de ticket al comienzo de sus mensajes de confirmación, se agrupan con sort . La ordenación también ayuda si prefieres ciertas confirmaciones con fix , typo , etc.