De bonnes façons de gérer un journal des changements avec git?

Question

J'ai été en utilisant Git pour un certain temps maintenant, et j'ai récemment commencé à utiliser de balise de mes sorties de sorte que je puisse plus facilement garder une trace de changements et d'être en mesure de voir la version de chacun de nos clients sont en cours d'exécution (malheureusement, le code exige actuellement que chaque client a sa propre copie du PHP site; je vais changer cela, mais c'est lent).

Dans tous les cas, nous commençons à construire un certain élan, j'ai pensé qu'il serait vraiment bon d'être en mesure de montrer aux gens ce qui a changé depuis la dernière version. Le problème est, je n'ai pas été le maintien d'un "changelog" parce que je n'ai pas une bonne idée de la façon d'aller à ce sujet. Pour cette fois, je peux courir à travers le journal et de créer manuellement un, mais qui va se lasser très rapidement.

J'ai essayé de googler "git changelog" et "git gérer changelog" mais je n'ai pas trouver quelque chose qui vraiment parlé du flux de travail des modifications de code et comment, qui coïncide avec le changelog. Nous sommes en train de Freiner Henrichs le développement de flux de travail et j'aimerais quelque chose qui allait de pair avec cela.

Est-il d'une démarche qui me manque, ou est-ce un domaine où tout le monde fait leur propre chose?

Merci beaucoup pour vos commentaires/réponses!

Answer 1

C’était il y a environ 3-4 ans, mais dans un souci de futurs chercheurs, il est maintenant possible de générer des logs magnifiques avec :

Ou, si vous voulez qu’il est encore plus jolie (avec la couleur pour terminal) :

Tuyauterie que sortie de ChangeLog est ce que j’utilise actuellement dans tous mes projets, c’est tout simplement incroyable.

Answer 2

AVERTISSEMENT: je suis l'auteur de gitchangelog dont je parlerai dans la suite.

Si vous êtes sérieux au sujet de la génération de votre changelog de git log, vous devriez considérer:

1. Le stockage de l'information nécessaire avec un message de validation de la convention. (j'espère ne pas encombrant)
2. Utiliser un script qui utilise git pour tirer parti de votre convention et de sortie le changelog de vos rêves.

le message de validation de la convention de

Ce qui suit sont des suggestions sur ce qui pourrait être utile de penser à l'ajouter à vos messages de commit.

Vous pourriez vous voulez les séparer à peu près à ton s'engage dans de grandes sections:

• par l'intention (par exemple: de nouvelles, corriger, modifier ...)
• par objet (par exemple: doc, de l'emballage, code ...)
• par le public (par exemple: dev, testeur, utilisateurs ...)

De plus, vous pourriez souhaiter pour la balise certains s'engage à:

• en tant que "mineur" s'engage à ne pas obtenir outputed à votre journal des modifications (changements cosmétiques, petite faute de frappe dans les commentaires...)
• "refactor" si vous n'avez pas vraiment tout signifiant les caractéristiques. Ainsi, ce ne devrait pas être aussi partie du changelog affiché à l'utilisateur final, par exemple, mais qui peut être intéressant si vous avez un développeur changelog.
• vous pourriez tag aussi avec "api" pour marquer les changements de l'api ou de la nouvelle api de trucs...
• etc ...etc...

Essayez d'écrire votre message de commit par cibler les utilisateurs (fonctionnalité) aussi souvent que vous le pouvez.

exemple

C'est la norme git log --oneline , pour montrer comment ces informations pourraient être stockées::

* 5a39f73 fix: encoding issues with non-ascii chars.
* a60d77a new: pkg: added ``.travis.yml`` for automated tests. 
* 8a544b6 new: python3 compatibility. 
* 57129ba new: much greater performance on big repository by issuing only one shell command for all the commits. (fixes #7)
* 7825e6c chg: dev: moved commit's attribute retrieval out of ``__init__`` towards ``__getattr__``. 
* 9f8a5c3 chg: dev: code optimization.
* 6b4b267 chg: dev: refactored out the formatting characters from GIT.
* 197b069 new: dev: reverse ``natural`` order to get reverse chronological order by default. !refactor 
* 198d217 new: dev: added a complete reference test. 
* 6b891bc new: add utf-8 encoding declaration !minor 

Donc, si vous l'avez remarqué, le format que j'ai choisi est:

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

Pour voir un réel résultat de sortie, on peut le voir à la fin de la PyPI page de gitchangelog

Comment générer exquis changelog de cette

Ensuite, il est assez facile de faire un changelog complet. Vous pourriez faire votre propre script assez rapidement, ou de l'utilisation gitchangelog.

Cet outil va générer un changelog (avec découpe de soutien en tant que New, Fix...), et est assez configurable à votre propre commettre des conventions. Il prend en charge la sortie de template par Mustache, Mako templating, et a une valeur par défaut héritage moteur écrit en raw python ; tous les 3 moteurs ont des exemples de la façon de les utiliser et de sortie peut changelog est aussi celui affiché sur le PyPI page de gitchangelog.

Je suis sûr que vous savez qu'il ya beaucoup d'autres git log de changelog outils là-bas aussi.

Answer 3

Vous pouvez utiliser de la saveur de la commande git log pour vous aider:

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

Si vous nommez vos branches bien, de sorte qu'une fusion de maître montre jusqu'à ce que quelque chose comme "Fusionné direction de la fonction-test", vous pouvez raccourcir les choses en ne montrant que les message, et non tous les petits s'engage à ce que vous fusionnées, qui, ensemble, forment la fonctionnalité:

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

Vous pourriez être en mesure de compléter cela avec un script de votre propre qui pourrait faire des choses comme la bande de la "Fusionné branche" bits, de normaliser la mise en forme, etc. À un certain point, vous devez écrire vous-même, bien évidemment.

Ensuite, vous pouvez créer une nouvelle section pour le changelog une fois par version:

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

et de s'engager à ce que dans votre version de commettre.

Si votre problème est que ceux qui commettent des sujets ne sont pas quelque chose comme ce que vous voulez mettre dans un changelog, vous avez deux options: continuer de faire tout manuellement (et essayer de suivre plus régulièrement au lieu de rattraper le temps perdu au temps de la libération), ou de réparer votre message de commit style. Une option, si les sujets ne vont pas le faire pour vous, serait de placer des lignes comme "le changement: ajout de la fonction toto" dans le corps de vos messages de validation, de sorte que plus tard, vous pourriez faire quelque chose comme git log --pretty=%B | grep ^change: récupérer uniquement les super-important bits des messages.

Je ne suis pas entièrement sûr de savoir comment beaucoup plus que cela git pourrait vraiment vous aider à créer vos modifications. Peut-être que j'ai mal interprété ce que tu veux dire par "gérer"?

Answer 4

Un plus pour le CHANGELOG de point. Dites-moi si vous les gens comme lui.

Answer 5

L' gitlog-to-changelog script est très utile pour générer un style GNU ChangeLog.

Comme indiqué par gitlog-to-changelog --help, vous pouvez choisir l'engage utilisé pour générer un ChangeLog fichier à l'aide de l'option --since:

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

ou en passant des arguments additionnels après l' --, qui sera transmis à l' git-log (appelée en interne par gitlog-to-changelog):

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

Par exemple, je suis en utilisant la règle suivante dans le haut-niveau Makefile.am d'un de mes projets:

.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

Cette règle est utilisée au moment de la libération de temps pour mettre à jour ChangeLog avec la dernière n'est pas encore enregistré des messages de commit. Le fichier .last-cl-gen contient le SHA1 identifiant du dernier commit enregistré dans ChangeLog et est stocké dans le dépôt Git. ChangeLog est également enregistré dans le référentiel, de sorte qu'il peut être modifié (par exemple, pour corriger les fautes de frappe) sans altérer les messages de validation.