Avvia un messaggio di commit git con un cancelletto (#)

283

Git tratta le righe che iniziano #come righe di commento durante il commit. questo è molto fastidioso quando si lavora con un sistema di tracciamento dei biglietti e si cerca di scrivere il numero del biglietto all'inizio della riga, ad es

#123 salt hashed passwords

git rimuoverà semplicemente la linea dal messaggio di commit. c'è un modo per sfuggire all'hash? ho provato \e !, ma niente funziona. gli spazi bianchi prima #vengono conservati, quindi non rappresentano nemmeno una soluzione funzionante al problema.

— Knittl
fonte

8

@AlexBudovski perché c'è valore nella brevità.

— Xavi

8

Da git 1.8.2 (febbraio 2013), git config core.commentcharconsente di configurare quel carattere di commento. Vedi la mia risposta qui sotto

— VonC

3

Poiché Git v2.0.0 (2014.05.21) git commit --cleanup=scissorssarà più flessibile. Vedi i dettagli nella mia risposta

— Sungam,

4

Devo dire che sono sorpreso che le persone GitHub non abbiano pensato a questo problema quando hanno deciso di contrassegnare i numeri di emissione con gli hash!

— Michael Scheper,

1

@Michael Per essere onesti, questa convenzione era già stata utilizzata da Mantis, Trac, Redmine e probabilmente da altri. Suppongo che GitHub abbia appena deciso di seguirlo invece di reinventare la ruota. Vedi stackoverflow.com/questions/40495/…

— kelvin il

235

Questo comportamento fa parte del comportamento git commitpredefinito di "pulizia". Se si desidera mantenere le linee che iniziano con #è possibile utilizzare una modalità di pulizia alternativa.

Per esempio

git commit --cleanup=whitespace

In questo caso, devi fare attenzione a rimuovere tutte le #righe che non desideri vengano visualizzate nel commit.

— CB Bailey
fonte

La domanda successiva è: dove posso modificare i commenti del messaggio di commit che git introduce che iniziano di default con un #?

— Alex,

2

@Alex: è controllato dalla commit.templatevariabile di configurazione git.

— CB Bailey,

23

Funziona benissimo anche per modificare gli commit esistenti. Ad esempio:git commit --amend --cleanup=whitespace

— James Andres,

@CharlesBailey: mi aspettavo di sbarazzarmi del testo predefinito con git commit -t / dev / null ma lo sta ancora dimostrando

— Alex

Dato che sei in grado di avere un messaggio di commit di "Messaggio di commit n. 123", nonché commenti nei client come GitHub per Mac e SourceTree, credo che cosa stiano facendo questi client?

— Phil Ostler,

134

Si noti che, da git1.8.2 (febbraio 2013) , è possibile utilizzare un carattere diverso da " #" per la riga commentata nel messaggio di commit.

Ciò ti consente di usare ' #' come riferimento per il numero di bug.

Varie linee di "suggerimento" fornite da Git quando chiede all'utente di modificare i messaggi nell'editor sono commentate con ' #' di default.

La core.commentCharvariabile di configurazione può essere utilizzata per personalizzare questo ' #' con un carattere diverso.

In teoria, si potrebbe mettere una core.commentCharparola (più caratteri), ma git 2.0.x / 2.1 sarà più severa (3 ° trimestre 2014).

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

config: sii severo su core.commentChar

Non supportiamo le stringhe di commento (almeno non ancora). E la codifica dei caratteri multi-byte potrebbe anche essere interpretata erroneamente.

Il test con due virgole viene aggiornato perché viola questo. Viene aggiunto con la patch che introduce core.commentCharin eff80a9 (Consenti "commento char" personalizzato - 2013-01-16). Non mi è chiaro perché si desideri questo comportamento.

git 2.0.x / 2.1 (Q3 2014) aggiungerà una selezione automatica per core.commentChar:
Vedi commit 84c9dc2

Quando core.commentCharè " auto", il carattere di commento inizia con " #" come predefinito, ma se è già nel messaggio preparato, trova un altro carattere in un piccolo sottoinsieme. Questo dovrebbe fermare le sorprese perché git elimina alcune righe inaspettatamente.

Nota che git non è abbastanza intelligente da riconoscere ' #' come carattere di commento nei modelli personalizzati e convertirlo se il carattere di commento finale è diverso.
Ritiene le linee "#" nei modelli personalizzati come parte del messaggio di commit. Quindi non usarlo con modelli personalizzati.

L'elenco dei caratteri candidati per "auto" sono:

# ; @ ! $ % ^ & | :

Ciò significa che un comando simile git commit -m '#1 fixed issue'commuterà automaticamente commentChar su ' ;', perché ' #' è stato utilizzato nel messaggio di commit.

— VonC
fonte

1

Per risolvere la sintassi HL dopo questo, vedere questa domanda correlata: stackoverflow.com/questions/16164624/...

— Alois Mahdal

@Guten True, ho riformulato la risposta per riflettere ciò.

— VonC,

1

@newbyca con quale versione di git vedi che non è supportata durante un rebase interattivo?

— VonC,

2

Quindi, per impostare questo è possibile fare, ad esempio:$ git config --global core.commentchar ';'

— davetapley,

6

Adoro questa risposta. Oneliner per la nuova soluzione suggerita:git config --global core.commentChar auto

— intorno al

81

Le risposte qui sono buone e dettagliate, ma per un gob noob come me la personalizzazione delle opzioni di configurazione git non è così ovvia. Ecco un esempio per cambiare da #a ;per i caratteri di commento:

git config core.commentChar ";"

Questo è tutto ciò che devi fare.

— Matthieu Napoli
fonte

3

Questo cambia anche il testo commentato predefinito che git aggiunge a un messaggio di commit quando si usa git commitper aprire l'editor configurato per modificare un messaggio di commit!

— Michael Trouw,

1

Per le correzioni singole, utilizzare questo: git -c core.commentChar="|" commit --amend(sostituire |con quello che si desidera).

— Droogans

62

È possibile utilizzare l'opzione della riga di comando -m:

git commit -m "#123 fixed"

— Olivier Verdier
fonte

35

Ma questo è un orribile messaggio di commit. assicurati di includere qual era il bug e come è stato corretto

— Good Person

3

i messaggi di commit sono ok fintanto che c'è un numero del bug

— Trident D'Gao

6

Non se il sistema di tracciamento dei bug viene improvvisamente danneggiato e non hai un backup! :)

— caveman_dick,

38

Se stai facendo un rebase interattivo, quando salvi il tuo messaggio di commit senza nulla (perché #all'inizio lo ha reso un commento e quindi è stato ignorato) git ti mostrerà cosa fare:

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

Quindi, basta modificare il messaggio:

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

e continua il rebase:

git rebase --continue

— Owain Williams
fonte

Questo è corretto per qualcuno che ha già inviato il commit, ma vuole cambiare il messaggio

— Hoang Trinh,

Si applica anche ai nuovi commit se inserisci un messaggio usando il tuo editor e all'inizio ha un hash.

— Owain Williams,

29

git commit --cleanup=scissorsdovrebbe essere usato. È stato aggiunto a Git v2.0.0 il 2014.05.21

a partire dal git commit --help

--cleanup=<mode>
  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.

— Sungam
fonte

Non capisco come sia meglio dell'uso commit.cleanup = whitespacee della rimozione # …manuale dei commenti, come ha già suggerito @CharlesBailey. scissors-mode semplicemente pulisce ulteriormente la sintassi delle forbici usata da git format-patch/ mailinfo/ am; esso non usa la …-- >8 --…sintassi quando l'aggiunta di commenti a commettere i messaggi .

— Slipp D. Thompson,

1. Penso che sia meglio perché non ho bisogno di "rimuovere i # ...commenti di tanto in tanto. 2. Non sono così sicuro della seconda parte del tuo commento, la scissorsmodalità è sicuramente in git commit --help. Quale versione di gitstai usando? @ SlippD.Thompson

— Sungam

Eh? whitespacela modalità offre lo stripping di 1. linee vuote iniziali e finali, 2. spazi vuoti finali, 3. compressione righe vuote consecutive. scissorsoffre lo stripping di 1. linee vuote iniziali e finali, 2. spazi bianchi finali, 3. comprimi linee vuote consecutive, 4. tutto da (e incluso) la linea # -…- >8 -…-. Tuttavia, le linee delle forbici ( # -…- >8 -…-) vengono inserite solo quando si utilizza git-format-patch/ mailinfo/ am. Pertanto, per un normale git-commit/ merge/ rebase/ cherry-pickflusso di lavoro, la scissorsmodalità di stripping offre zero vantaggi rispetto alla whitespacemodalità. v2.11.0

— Slipp D. Thompson

@ SlippD.Thompson Quale versione di git stai usando? Sto usando 2.8.3 e git commit --cleanup=scissors FA anteporre la # ------------------------ >8 ------------------------riga prima della git statusinformazioni. Come sotto: `# ------------------------> 8 ------------------- ----- # Non toccare la linea sopra. # Tutto ciò che verrà rimosso verrà rimosso. # On branch branch # # Initial commit # # Modifiche da impegnare: # nuovo file: .gitignore `

— Sungam

1

Credo di essere arrivato al fondo di questo. Git infatti inserisce # ------------------------ >8 ------------------------prima lo stato txt "Sembra che tu possa essere ..." _ durante l'utilizzo scissors; tuttavia, inserisce la linea delle forbici dopo il # Conflicts: …testo. Avevo commit.status = falseimpostato il mio .gitconfig, quindi non vedevo alcun testo sullo stato, ma solo il testo dei conflitti. Sono corretto; cambiando in votazione.

— Slipp D. Thompson,

3

Utilizzare un prefisso diverso per il numero del biglietto. O anteporre una parola al numero del biglietto, ad esempio "Bug # 42". O anteporre un singolo carattere spazio alla linea; se desideri rimuovere quello spazio bianco puoi aggiungere un hook di commit per quello.

Personalmente preferirei non fare questo tipo di manipolazione dei messaggi di commit da parte di un hook perché può essere molto irritante quando si innesca quando non lo vuoi. La soluzione più semplice è probabilmente ripensare il problema.

— wilhelmtell
fonte

1

una diversa formulazione è solo una soluzione per il problema. se le linee guida del progetto affermano che un messaggio di commit deve iniziare con l'id ticket, non funzionerà. e un hook post-commit è molto brutto. penso che dovrei segnalare questo "bug" agli sviluppatori git

— knittl

Non preoccuparti, sarebbe sbagliato. Non chiedere agli sviluppatori git di lavorare secondo le tue linee guida. Non chiederesti a Dennis Ritchie di cambiare il linguaggio C in modo che supporti la convenzione con i nomi delle variabili di iniziare con un carattere hash, giusto? Lo stesso vale qui. Se i messaggi di commit consentono commenti, questo aggiunge il supporto per cose interessanti, come l'apertura dell'editor di commit con il diff aggiunto e commentato, quindi non è necessario ricordare le modifiche esatte. Cosa c'è di sbagliato nel preservare il personaggio spaziale principale?

— Wilhelmtell,

1

sostenere i personaggi di escape nel messaggio di commit di git non sarebbe un grosso problema

— knittl

5

È una richiesta di funzionalità perfettamente ragionevole. Soprattutto alla luce del fatto che Trac, AFAICT, non associa un commit a un bug slip se il messaggio di commit non inizia con il numero di slip, iniziando con un hash. Quindi non sono solo gli standard di qualcuno, è la sintassi richiesta da uno strumento. Lascia che gli sviluppatori Git decidano se valga la pena o meno. (E sì, Trac potrebbe anche risolvere il problema. Non c'è niente di sbagliato nel chiedere a Git di fare anche quello che può.)

— Luke Maurer,

"Soprattutto alla luce del fatto che Trac, AFAICT, non associa un commit a un bug slip se il messaggio di commit non inizia con il numero di slip, a cominciare da un hash." - nella mia esperienza limitata con Trac, qualcosa come quello che si #xxxverifica in qualsiasi punto del messaggio di commit si collegherà al problema. Non deve essere all'inizio del commit. Forse questo è qualcosa che è cambiato negli ultimi cinque anni?

— Guildenstern,

1

Tutto il mio impegno inizia con #issueNumberquindi ho messo questo boilerplate sul mio vim .git/hooks/commit-msg:

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

Supponiamo quindi che abbiamo una filiale #15e facciamo un messaggio di commit add new awesome feature. Con questo approccio il messaggio di commit finale sarà #15 add new awesome feature.

— valignatev
fonte