Hg message de validation post-fusion, meilleure pratique?

Question

je me retrouve à faire ce qui suit beaucoup:

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 

Ma question est, ce qui est mieux/plus utile d'utiliser le message de validation après la fusion d'une traction à partir du référentiel. Y a-t-il des meilleures pratiques que les gens utilisent dans les systèmes de contrôle de version distribués pour ce genre de chose?

Answer 1

Si vous utilisez le fetch extension, il automatise le tirage, fusionne le pas en une seule étape, va chercher. Le message qu'il génère automatiquement est quelque chose du genre "fusion automatique". Les développeurs de hg semblent penser que c'est raisonnable car l'extension est maintenant distribuée avec la base.

Les messages de fusion ne semblent pas contenir une quantité d'informations particulièrement élevée. Votre message semble raisonnable.

[[offtopic, nous les utilisons parfois l'occasion d'un jeu de mots sur le mot fusion]]

Answer 2

Il n'y a pas de solution unique, voici ce que j'ai essayé de faire.

messages: Lors de la validation

rappelez-vous que ces jus messages sont les seules chaînes qui vous connecter à quelqu'un qui est d'essayer de déchiffrer les raisons de l'engagement. La clé est de fournir une description qui va être un commentaire utile sur le développement de code. Donc, quand quelqu'un utilise hg log, il a un bon commentaire sur la façon dont le logiciel est développé.

Quelques bonnes pratiques:

Lien avec votre système de gestion de bug:

1. fixe # 3456, nouvelle fonctionnalité # 2435 etc
2. ou plus descriptif une des modifications qu'elle apporte dans le repo
3. Donner des credits

En fait, ce que je fais surtout c'est. Regardez l'état actuel de "hg log" et voir quel message utile signifierait une progression logique dans la compréhension de la dernière validation.

Answer 3

Vous pouvez utiliser l'extension de rebasage, donc hg pull --rebase serait rebasage votre repo à la pointe du repo central. Cela annule le besoin de fusion après une traction.

j'ai ajouté un alias pour elle:

[alias] 
pure = pull -u --rebase 

fonctionne bien pour nous.

Plus de détails sont à la page RebaseProject.

Answer 4

Pour les fusions banales, où vous ne travaillez qu'avec un référentiel, je pense que "fusionner" suffit. Habituellement, vous ne savez même pas tout ce qui a été fusionné, car ce sont les changements de tous les autres.

La seule fois où je suggérerais d'être plus verbeux serait lorsque vous travaillez avec plus d'un dépôt. Si vous avez un devel repo et un repo stable, et que vous récupérez des corrections de bogues dans stable, je mentionnerais simplement cela dans la fusion: "fusionner avec stable". Ces fusions ont tendance à être plus grandes, donc cela aide à les expliquer aux gens qui arrivent plus tard.

Answer 5

Vous pouvez collecter toutes les engager nouvellement ajoutés changesets' messages dans un fichier par

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

puis modifier manuellement commit-message.txt, et enfin l'utiliser comme le message du journal:

$ hg commit -l commit-message.txt 

Answer 6

Tant que "Merg" est dans le message d'une manière ou d'une autre, nous nous sommes amusés à utiliser l'opportunité de remplir nos logs de mercure avec hilarité. Par exemple, nous avons utilisé des messages de fusion tels que «les prêts de fusion immobilière sont à un bas absolu» ou «une production télévisuelle de Merge Griffin».