Starten Sie eine Git-Commit-Nachricht mit einem Hashmark (#).

283

Git behandelt Zeilen, die mit beginnen #, beim Festschreiben als Kommentarzeilen. Dies ist sehr ärgerlich, wenn Sie mit einem Ticket-Tracking-System arbeiten und versuchen, die Ticket-Nummer am Anfang der Zeile zu schreiben, z

#123 salt hashed passwords

git entfernt einfach die Zeile aus der Commit-Nachricht. Gibt es eine Möglichkeit, dem Hash zu entkommen? Ich habe es versucht \und !, aber nichts funktioniert. Whitespaces zuvor #bleiben erhalten, sodass sie auch keine funktionierende Lösung für das Problem darstellen.

— stricken
quelle

8

@AlexBudovski, weil es Wert auf Kürze gibt.

— Xavi

8

Ermöglicht seit git 1.8.2 (Februar 2013) git config core.commentchardie Konfiguration dieses Kommentarzeichens. Siehe meine Antwort unten

— VonC

3

Seit Git v2.0.0 (2014.05.21) git commit --cleanup=scissorswird flexibler. Siehe Detail in meiner Antwort

— Sungam

4

Ich muss sagen, ich bin überrascht, dass die GitHub-Leute nicht über dieses Problem nachgedacht haben, als sie beschlossen haben, Ausgabenummern mit Hashes zu markieren!

— Michael Scheper

1

@ Michael Um fair zu sein, wurde diese Konvention bereits von Mantis, Trac, Redmine und wahrscheinlich anderen verwendet. Ich nehme an, GitHub hat sich einfach entschieden, ihm zu folgen, anstatt das Rad neu zu erfinden. Siehe stackoverflow.com/questions/40495/…

— Kelvin

235

Dieses Verhalten ist Teil des git commitStandardverhaltens für die Bereinigung. Wenn Sie die Zeilen beginnen lassen möchten, können #Sie einen alternativen Bereinigungsmodus verwenden.

Z.B

git commit --cleanup=whitespace

Wenn Sie dies tun, müssen Sie darauf achten, alle #Zeilen zu entfernen , die nicht im Commit angezeigt werden sollen.

— CB Bailey
quelle

Die nächste Frage lautet: Wo kann ich die von git eingeführten Commit-Nachrichtenkommentare bearbeiten, die standardmäßig mit einem # beginnen?

— Alex

2

@Alex: Es wird von der commit.templateGit-Konfigurationsvariablen gesteuert .

— CB Bailey

23

Dies eignet sich auch hervorragend zur Änderung bestehender Commits. ZB:git commit --amend --cleanup=whitespace

— James Andres

@ CharlesBailey: Ich hatte erwartet, den vordefinierten Text mit git commit -t / dev / null loszuwerden, aber es zeigt immer noch, dass

— Alex

Da Sie in der Lage sind, eine Commit-Nachricht mit dem Titel "# 123 Commit-Nachricht" sowie Kommentare in Clients wie GitHub für Mac und SourceTree zu erhalten, denke ich, was diese Clients tun, ja?

— Phil Ostler

134

Beachten Sie, dass Sie seit git1.8.2 (Februar 2013) ein anderes Zeichen als ' #' für die kommentierte Zeile in der Festschreibungsnachricht verwenden können .

Auf diese Weise können Sie ' #' als Referenz für die Fehlernummer verwenden.

Verschiedene "Hinweis" -Zeilen, die Git gibt, wenn der Benutzer aufgefordert wird, Nachrichten im Editor zu bearbeiten, sind #standardmäßig mit ' ' auskommentiert.

Die core.commentCharKonfigurationsvariable kann verwendet werden, um dieses ' #' an ein anderes Zeichen anzupassen .

Theoretisch könnten Sie ein core.commentCharWort (mehrere Zeichen) eingeben, aber Git 2.0.x / 2.1 wird strenger (Q3 2014).

Siehe Commit 50b54fd von Nguyễn Thái Ngọc Duy ( pclouds) :

config: Seien Sie streng bei core.commentChar

Wir unterstützen keinen Kommentar - Strings (zumindest noch nicht). Die Mehrbyte-Zeichencodierung kann ebenfalls falsch interpretiert werden.

Der Test mit zwei Kommas wird aktualisiert, da er dies verletzt. Es wurde mit dem Patch hinzugefügt, der core.commentCharin eff80a9 eingeführt wird (Benutzerdefiniertes "Kommentarzeichen zulassen" - 16.01.2013). Mir ist nicht klar, warum dieses Verhalten erwünscht ist.

Git 2.0.x / 2.1 (Q3 2014) fügt eine automatische Auswahl hinzu für core.commentChar:
Siehe Commit 84c9dc2

Wenn core.commentChar" auto" ist, beginnt das Kommentarzeichen #wie standardmäßig mit ' ', aber wenn es bereits in der vorbereiteten Nachricht enthalten ist, suchen Sie ein anderes Zeichen in einer kleinen Teilmenge. Dies sollte Überraschungen stoppen, da Git einige Zeilen unerwartet entfernt.

Beachten Sie, dass git nicht intelligent genug ist, um ' #' als Kommentarzeichen in benutzerdefinierten Vorlagen zu erkennen und zu konvertieren, wenn das endgültige Kommentarzeichen anders ist.
Es werden '#' Zeilen in benutzerdefinierten Vorlagen als Teil der Festschreibungsnachricht betrachtet. Verwenden Sie dies also nicht mit benutzerdefinierten Vorlagen.

Die Liste der Kandidatenzeichen für "auto" lautet:

# ; @ ! $ % ^ & | :

Das bedeutet, dass ein Befehl wie git commit -m '#1 fixed issue'das commentChar automatisch auf ' ;' umschaltet , da ' #' in der Festschreibungsnachricht verwendet wurde.

— VonC
quelle

1

Um die Syntax HL danach zu korrigieren,

— lesen

@Guten Richtig, ich habe die Antwort umformuliert, um dies widerzuspiegeln.

— VonC

1

@newbyca mit welcher Version von Git sehen Sie, die während einer interaktiven Rebase nicht unterstützt wird?

— VonC

2

$ git config --global core.commentchar ';'

— Um

6

Ich liebe diese Antwort. Oneliner für die neue vorgeschlagene Lösung:git config --global core.commentChar auto

— über den

81

Die Antworten hier sind gut und detailliert, aber für einen Git-Neuling wie mich ist das Anpassen der Git-Konfigurationsoptionen nicht so offensichtlich. Hier ist ein Beispiel zum Ändern von #zu ;für Kommentarzeichen:

git config core.commentChar ";"

Das ist alles was Sie tun müssen.

— Matthieu Napoli
quelle

3

Dies auch ändert den Standard kommentierte Text , dass git fügt hinzu , um eine Nachricht zu begehen , wenn man verwendet git commitden konfigurierten Editor bearbeiten zu öffnen , eine Nachricht zu begehen!

— Michael Trouw

1

Verwenden Sie für einmalige Korrekturen Folgendes: git -c core.commentChar="|" commit --amend(Ersetzen Sie sie |durch das, was Sie möchten).

— Droogans

62

Sie können die Befehlszeilenoption verwenden -m:

git commit -m "#123 fixed"

— Olivier Verdier
quelle

35

Aber das ist eine schreckliche Commit-Nachricht. Stellen Sie sicher, dass Sie angeben, was der Fehler war und wie er behoben wurde

— Good Person

3

Die Commit-Nachrichten sind in Ordnung, solange es eine Reihe von Fehlern gibt

— Trident D'Gao

6

Nicht, wenn das Bug-Tracking-System plötzlich beschädigt wird und Sie kein Backup haben! :)

— caveman_dick

38

Wenn Sie eine interaktive Rebase durchführen, zeigt Ihnen git, wenn Sie Ihre Commit-Nachricht mit nichts darin speichern (da sie #am Anfang zu einem Kommentar gemacht wurde und daher ignoriert wurde), was zu tun ist:

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

Ändern Sie einfach die Nachricht:

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

und setzen Sie die Rebase fort:

git rebase --continue

— Owain Williams
quelle

Dies ist richtig für jemanden, der das Commit bereits gepusht hat, aber die Nachricht ändern möchte

— Hoang Trinh

Dies gilt auch für neue Commits, wenn Sie eine Nachricht mit Ihrem Editor eingeben und am Anfang ein Hash steht.

— Owain Williams

29

git commit --cleanup=scissorssollte benutzt werden. Es wurde am 21.05.2014 zu Git v2.0.0 hinzugefügt

von 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
quelle

Ich verstehe nicht, wie dies besser ist, als Kommentare von Hand zu verwenden commit.cleanup = whitespaceund zu entfernen # …, wie @CharlesBailey bereits vorgeschlagen hat. scissors-mode bereinigt nur zusätzlich die von git format-patch/ mailinfo/ verwendete Scherensyntax am; es ist nicht die Verwendung …-- >8 --…Syntax , wenn Kommentar Hinzufügen von Nachrichten zu begehen .

— Slipp D. Thompson

1. Ich denke, es ist besser, weil ich den # ...Kommentar nicht " hart " entfernen muss . 2. Ich bin mir beim zweiten Teil Ihres Kommentars nicht so sicher, der scissorsModus ist definitiv in der git commit --help. Welche Version von verwenden gitSie? @ SlippD.Thompson

— Sungam

Huh? whitespaceDer Modus bietet das Entfernen von 1. führenden und nachfolgenden Leerzeilen, 2. nachfolgenden Leerzeichen und 3. Reduzieren aufeinanderfolgender Leerzeilen. scissorsbietet das Entfernen von 1. führenden und nachfolgenden Leerzeilen, 2. nachfolgenden Leerzeichen, 3. Reduzieren aufeinanderfolgender Leerzeilen, 4. alles von (und einschließlich) der Zeile # -…- >8 -…-. Scherenlinien ( # -…- >8 -…-) werden jedoch nur bei Verwendung von git-format-patch/ mailinfo/ eingefügt am. Daher bietet der Abisoliermodus für einen normalen git-commit/ merge/ rebase/ cherry-pickWorkflow scissorskeine Vorteile gegenüber dem whitespaceModus. v2.11.0

— Slipp D. Thompson

@ SlippD.Thompson Welche Version von Git verwenden Sie? Ich verwende 2.8.3 und git commit --cleanup=scissors stelle die # ------------------------ >8 ------------------------Zeile vor die git statusInfo. Wie unten: `# ------------------------> 8 ------------------- ----- # Berühren Sie nicht die obige Linie. # Alles unten wird entfernt. # Auf dem Zweigmaster # # Erstes Festschreiben # # Zu übernehmende Änderungen: # Neue Datei: .gitignore `

— Sungam

1

Ich glaube, ich bin dem auf den Grund gegangen. Git fügt in der Tat # ------------------------ >8 ------------------------vor dem Status txt "Es sieht so aus, als ob Sie ..." _ ein, wenn Sie verwenden scissors; Es wird jedoch die Scherenlinie nach dem # Conflicts: …Text eingefügt. Ich hatte commit.status = falsein meinem festgelegt .gitconfig, so dass ich keinen Statustext sah, nur den Konflikttext. Ich stehe korrigiert; zu upvote wechseln.

— Slipp D. Thompson

3

Verwenden Sie ein anderes Präfix für die Ticketnummer. Oder stellen Sie der Ticketnummer ein Wort voran, z. B. "Bug # 42". Oder stellen Sie der Zeile ein einzelnes Leerzeichen voran; Wenn Sie dieses Leerzeichen entfernen möchten, können Sie dafür einen Commit-Hook hinzufügen.

Ich persönlich würde diese Art der Manipulation von Commit-Nachrichten lieber nicht von einem Hook ausführen lassen, da dies sehr irritierend sein kann, wenn es ausgelöst wird, wenn Sie es nicht möchten. Die einfachste Lösung besteht wahrscheinlich darin, das Problem zu überdenken.

— wilhelmtell
quelle

1

Eine andere Formulierung ist nur eine Problemumgehung für das Problem. Wenn in den Projektrichtlinien festgelegt ist, dass eine Festschreibungsnachricht mit der Ticket-ID beginnen muss, funktioniert sie nicht. und ein Post-Commit-Hook ist sehr hässlich. Ich denke, ich sollte diesen "Bug" den Git-Entwicklern

— melden

Mach dir keine Sorgen, das wäre falsch. Bitten Sie die Git-Entwickler nicht, gemäß Ihren Richtlinien zu arbeiten. Sie würden Dennis Ritchie nicht bitten, die C-Sprache zu ändern, damit Sie die Konvention für Variablennamen unterstützen, mit einem Hash-Zeichen zu beginnen, oder? Gleiches gilt hier. Wenn Commit-Nachrichten Kommentare zulassen, werden dadurch interessante Dinge unterstützt, z. B. das Öffnen des Commit-Editors mit dem hinzugefügten und auskommentierten Diff, sodass Sie sich nicht an Ihre genauen Änderungen erinnern müssen. Was ist falsch daran, den führenden Weltraumcharakter zu bewahren?

— Wilhelmtell

1

Es wäre keine so große Sache, Escape-Charaktere in Git's Commit-Nachricht zu unterstützen

— stricken Sie

5

Es ist eine absolut vernünftige Funktionsanforderung. Insbesondere angesichts der Tatsache, dass Trac, AFAICT, einem Fehlerbeleg kein Commit zuordnet, wenn die Festschreibungsnachricht nicht mit der Belegnummer beginnt, sondern mit einem Hash. Es sind also nicht nur die Standards von jemandem, sondern auch die erforderliche Syntax eines Tools. Lassen Sie die Git-Entwickler entscheiden, ob es sich lohnt oder nicht. (Und ja, Trac könnte das Problem auch beheben. Es ist nichts Falsches daran, Git zu bitten, das zu tun, was es kann.)

— Luke Maurer

"Insbesondere angesichts der Tatsache, dass Trac, AFAICT, einem Fehlerbeleg kein Commit zuordnet, wenn die Festschreibungsnachricht nicht mit der Belegnummer beginnt, sondern mit einem Hash." - Nach meiner begrenzten Erfahrung mit Trac wird so etwas wie das #xxxAuftreten irgendwo in der Festschreibungsnachricht mit dem Problem verknüpft. Es muss nicht zu Beginn des Commits sein. Vielleicht hat sich das in den letzten fünf Jahren geändert?

— Guildenstern

1

Alle meine Commits beginnen mit, #issueNumberalso lege ich diese Boilerplate auf meine vim .git/hooks/commit-msg:

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

Nehmen wir also an, wir haben einen Zweig #15und machen eine Commit-Nachricht add new awesome feature. Mit diesem Ansatz wird die endgültige Festschreibungsnachricht sein #15 add new awesome feature.

— valignatev
quelle