Lancer un message de validation git avec un hashmark (#)

Git traite les lignes commençant par # comme lignes de commentaire lors de la validation. Cela est très ennuyeux lorsque vous travaillez avec un système de suivi des tickets et que vous essayez d’écrire le numéro de ticket au début de la ligne, par exemple

 #123 salt hashed passwords 

git va simplement supprimer la ligne du message de validation. y a-t-il un moyen d’échapper au hash? j’ai essayé \ et ! , mais rien ne fonctionne. les espaces avant le # sont conservés, ils ne sont donc pas non plus une solution pratique au problème.

Ce comportement fait partie du comportement de nettoyage par défaut de git commit . Si vous souhaitez conserver des lignes commençant par # vous pouvez utiliser un autre mode de nettoyage.

Par exemple

 git commit --cleanup=whitespace 

Si vous faites cela, vous devez faire attention à supprimer toutes les lignes # que vous ne voulez pas voir apparaître dans le commit.

Notez que, depuis git1.8.2 (février 2013) , vous pouvez utiliser un caractère différent de ‘ # ‘ pour la ligne commentée du message de validation.

Cela vous permet d’utiliser ‘ # ‘ pour votre référence de numéro de bogue.

Différentes lignes de “conseil” que Git donne lorsqu’il demande à l’utilisateur de modifier les messages dans l’éditeur sont commentées par défaut avec ” # “.

La variable de configuration core.commentChar peut être utilisée pour personnaliser ce ‘ # ‘ avec un caractère différent.


En théorie, vous pouvez mettre un mot core.commentChar (plusieurs caractères), mais git 2.0.x / 2.1 sera plus ssortingct (troisième sortingmestre 2014).

Voir commit 50b54fd par Nguyễn Thái Ngọc Duy ( pclouds ) :

config: soyez ssortingct sur core.commentChar

Nous ne supportons pas les chaînes de commentaires (du moins pas encore). Et le codage de caractères multi-octets pourrait également être mal interprété.

Le test avec deux virgules est mis à jour car il viole cela. Il est ajouté au correctif qui introduit core.commentChar dans eff80a9 (Autoriser la personnalisation du commentaire – 2013-01-16). Je ne comprends pas pourquoi ce comportement est recherché.


git 2.0.x / 2.1 (Q3 2014) appenda une sélection automatique pour core.commentChar :
Voir commit 84c9dc2

Lorsque core.commentChar est ” auto “, le caractère de commentaire commence par ” # ” par défaut, mais s’il se trouve déjà dans le message préparé, recherchez un autre caractère dans un petit sous-ensemble. Cela devrait arrêter les sursockets car git dépouille certaines lignes de manière inattendue.

Notez que git n’est pas assez intelligent pour reconnaître ” # ” comme caractère de commentaire dans les modèles personnalisés et le convertir si le commentaire final est différent.
Il considère les lignes ‘#’ dans les modèles personnalisés comme faisant partie du message de validation. Donc, n’utilisez pas cela avec des modèles personnalisés.

La liste des caractères candidats pour “auto” est:

 # ; @ ! $ % ^ & | : 

Cela signifie qu’une commande comme git commit -m '#1 fixed issue' basculera automatiquement le commentaireChar sur ‘ ; ‘, car’ # ‘a été utilisé dans le message de validation.

Vous pouvez utiliser l’option de ligne de commande -m :

 git commit -m "#123 fixed" 

Les réponses ici sont bonnes et détaillées, mais pour un git noob comme moi, la personnalisation des options de configuration de git n’est pas si évidente. Voici un exemple pour passer de # à ; pour les caractères de commentaire:

 git config core.commentChar ";" 

C’est tout ce que vous devez faire.

Si vous faites un rebase interactif, alors lorsque vous enregistrez votre message de validation avec rien dans celui-ci (parce que le # au début a fait un commentaire et qu’il a donc été ignoré), git vous montrera ce qu’il faut faire:

 Aborting commit due to empty commit message. Could not amend commit after successfully picking 5e9159d9ce3a5c3c87a4fb7932fda4e53c7891db... 123 salt hashed passwords This is most likely due to an empty commit message, or the pre-commit hook failed. If the pre-commit hook failed, you may need to resolve the issue before you are able to reword the commit. You can amend the commit now, with git commit --amend Once you are satisfied with your changes, run git rebase --continue 

Donc, modifiez simplement le message:

 git commit --amend -m "#123 salt hashed passwords" 

et continuez le rebase:

 git rebase --continue 

git commit --cleanup=scissors doivent être utilisés. Il est ajouté à Git v2.0.0 2014.05.21

à partir de git commit --help

 --cleanup= scissors Same as whitespace, except that everything from (and including) the line "# ------------------------ >8 ------------------------" is truncated if the message is to be edited. "#" can be customized with core.commentChar. 

Utilisez un préfixe différent pour le numéro de ticket. Ou ajoutez un mot au numéro du ticket, par exemple “Bug # 42”. Ou append un seul caractère d’espace à la ligne; Si vous souhaitez supprimer cet espace, vous pouvez append un hook de validation pour cela.

Personnellement, je préférerais ne pas faire ce genre de manipulation de message de validation par un hook car cela peut être très irritant quand il se déclenche quand vous ne le voulez pas. La solution la plus simple consiste probablement à repenser le problème.

Tous mes commits commencent par #issueNumber alors je mets ce passe-partout dans mon vim .git/hooks/commit-msg :

 NAME=$(git branch | grep '*' | sed 's/* //') echo "$NAME"' '$(cat "$1") > "$1" 

Donc, supposons que nous ayons la twig #15 et que nous faisons en sorte que le message de validation add new awesome feature . Avec cette approche, le message de validation final sera #15 add new awesome feature .