Запустите сообщение git commit с хешмарком (#)

283

Git обрабатывает строки, начинающиеся с #комментариев, при фиксации. это очень раздражает, когда вы работаете с системой отслеживания билетов и пытаетесь записать номер билета в начале строки, например

#123 salt hashed passwords

git просто удалит строку из сообщения коммита. есть ли способ избежать хеша? я попробовал \и !, но ничего не работает. До этого пробелы #сохраняются, поэтому они также не являются рабочим решением проблемы.

knittl
источник
8
@AlexBudovski, потому что в краткости есть ценность.
Хави
8
Начиная с git 1.8.2 (февраль 2013 г.), git config core.commentcharможно настроить этот символ комментария. Смотрите мой ответ ниже
VonC
3
Поскольку Git v2.0.0 (2014.05.21) git commit --cleanup=scissorsбудет более гибким. Смотрите подробности в моем ответе
Sungam
4
Должен сказать, я удивлен, что люди GitHub не подумали об этой проблеме, когда решили пометить номера выпусков хэшами!
Майкл Шепер
1
@ Майкл Честно говоря, эта конвенция уже использовалась Mantis, Trac, Redmine и, возможно, другими. Я предполагаю, что GitHub просто решил следовать этому, а не изобретать велосипед. См. Stackoverflow.com/questions/40495/…
Кельвин

Ответы:

235

Это поведение является частью git commitстандартного поведения очистки. Если вы хотите сохранить строки, начинающиеся с, #вы можете использовать альтернативный режим очистки.

Например

git commit --cleanup=whitespace

Если вы делаете это, вы должны быть осторожны, чтобы удалить все #строки, которые вы не хотите отображать в коммите.

CB Bailey
источник
Следующий вопрос: где я могу редактировать комментарии к сообщению коммита, которые вводит git и которые по умолчанию начинаются с #?
Алекс
2
@Alex: Управляется commit.templateпеременной конфигурации git.
CB Bailey
23
Это прекрасно работает и для внесения изменений в существующие коммиты. Например:git commit --amend --cleanup=whitespace
Джеймс Андрес
@CharlesBailey: я ожидал избавиться от предопределенного текста с помощью git commit -t / dev / null, но он все еще показывает это
Alex
Так как вы можете получить сообщение коммита «123 Сообщение коммита», а также комментарии в клиентах, таких как GitHub для Mac и SourceTree, я думаю, что эти клиенты делают, да?
Фил Остлер
134

Обратите внимание, что начиная с git1.8.2 (февраль 2013 г.) , вы можете использовать символ, отличающийся от ' #' для закомментированной строки в сообщении фиксации.

Это позволяет вам использовать ' #' для ссылки на номер ошибки.

Различные строки «подсказки», которые Git дает, когда просит пользователя редактировать сообщения в редакторе, #по умолчанию закомментированы с помощью ' '.

core.commentCharПеременная конфигурации может использоваться для настройки этого « #» на другой символ.


Теоретически вы можете поместить core.commentCharслово (несколько символов), но git 2.0.x / 2.1 будет более строгим (3 квартал 2014 года).

См совершать 50b54fd по Nguyễn THAI Нгок Duy ( pclouds) :

config: быть строгим на core.commentChar

Мы не поддерживаем строки комментариев (по крайней мере, пока). И многобайтовая кодировка символов также может быть неверно истолкована.

Тест с двумя запятыми обновляется, потому что это нарушает это. Он добавлен с патчем, который вводится core.commentCharв eff80a9 (Разрешить пользовательский «комментарий char» - 2013-01-16). Мне не ясно, почему это поведение требуется .


git 2.0.x / 2.1 (3 квартал 2014 г.) добавит автоматический выбор для core.commentChar:
См. commit 84c9dc2

Когда core.commentChar"" auto", символ комментария начинается с" #", как по умолчанию, но если он уже находится в подготовленном сообщении, найдите другой символ в небольшом подмножестве. Это должно остановить сюрпризы, потому что git неожиданно удаляет некоторые строки.

Обратите внимание, что git недостаточно умен, чтобы распознавать ' #' как символ комментария в пользовательских шаблонах и преобразовывать его, если последний символ комментария отличается.
Он считает строки # в пользовательских шаблонах частью сообщения о коммите. Так что не используйте это с пользовательскими шаблонами.

Список символов-кандидатов для «авто»:

# ; @ ! $ % ^ & | :

Это означает, что команда like git commit -m '#1 fixed issue'автоматически переключит commentChar на ' ;', потому что ' #' использовалось в сообщении фиксации.

VonC
источник
1
Чтобы исправить синтаксис HL после этого, см. Следующий связанный вопрос: stackoverflow.com/questions/16164624/…
Алоис Махдал
@Guten Правда, я перефразировал ответ, чтобы отразить это.
VonC
1
@newbyca, с какой версией git вы видите, что она не поддерживается во время интерактивной перезагрузки?
VonC
2
Итак, чтобы установить это вы можете сделать, например:$ git config --global core.commentchar ';'
davetapley
6
Мне нравится этот ответ. Oneliner для нового предлагаемого решения:git config --global core.commentChar auto
aross
81

Ответы здесь хорошие и подробные, но для такого мерзавца, как я, настройка параметров git config не так очевидна. Вот пример , чтобы перейти от #к ;для комментариев символов:

git config core.commentChar ";"

Это все, что вам нужно сделать.

Матье Наполи
источник
3
Это также изменяет текст комментария по умолчанию, который git добавляет к сообщению фиксации, когда кто-либо использует его, git commitчтобы открыть сконфигурированный редактор для редактирования сообщения фиксации!
Майкл
1
Для одноразовых исправлений используйте это: git -c core.commentChar="|" commit --amend(замените |на что хотите).
Дрооганс
62

Вы можете использовать параметр командной строки -m:

git commit -m "#123 fixed"
Оливье Вердиер
источник
35
Но это ужасное сообщение. не забудьте указать, что это за ошибка и как она была исправлена
Good Person
3
сообщения о фиксации в порядке, пока есть номер ошибки
Trident D'Gao
6
Нет, если система отслеживания ошибок внезапно повреждена и у вас нет резервной копии! :)
caveman_dick
38

Если вы выполняете интерактивную перебазировку, то, когда вы сохраняете свое сообщение о коммите, в котором ничего нет (потому что #в начале это был комментарий, а потому его игнорировали), git покажет вам, что делать:

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

Итак, просто измените сообщение:

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

и продолжаем ребаз:

git rebase --continue
Оуайн Уильямс
источник
Это верно для тех, кто уже выдвинул коммит, но хочет изменить сообщение
Hoang Trinh
Это также относится к новым коммитам, если вы вводите сообщение, используя ваш редактор, и в начале у него есть хеш.
Оуайн Уильямс
29

git commit --cleanup=scissorsдолжен быть использован. Добавлен в Git v2.0.0 2014.05.21

из 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
источник
Я не понимаю, как это лучше, чем использовать commit.cleanup = whitespaceи удалять # …комментарии вручную, как уже предлагал @CharlesBailey. scissors-режим просто дополнительно очищает синтаксис ножниц, используемый git format-patch/ mailinfo/ am; он не использует …-- >8 --…синтаксис при добавлении комментариев для фиксации сообщений .
Слипп Д. Томпсон
1. Я думаю, что лучше, потому что мне не нужно «удалять # ...комментарии по-усердно». 2. Я не очень уверен насчет второй части вашего комментария, scissorsрежим определенно в git commit --help. Какую версию gitвы используете? @ SlippD.Thompson
Сунгам
А? whitespaceРежим предлагает удаление 1. начальных и конечных пустых строк, 2. конечных пробелов, 3. свертывание последовательных пустых строк. scissorsпредлагает удаление 1. ведущих и конечных пустых строк, 2. конечных пробелов, 3. свертывание последовательных пустых строк, 4. всего, начиная с (и включая) строки # -…- >8 -…-. Однако линии ножниц ( # -…- >8 -…-) вставляются только при использовании git-format-patch/ mailinfo/ am. Поэтому для нормального git-commit/ merge/ rebase/ cherry-pickрабочего процесса scissorsрежим зачистки дает ноль преимуществ по сравнению с whitespaceрежимом. v2.11.0
Слипп Д. Томпсон
@ SlippD.Thompson Какую версию Git вы используете? Я использую 2.8.3 и git commit --cleanup=scissors DOES предварять # ------------------------ >8 ------------------------строку перед git statusинформацией. Как показано ниже: `# ------------------------> 8 ------------------- ----- # Не трогайте строку выше. # Все ниже будет удалено. # На ветке master # # Первоначальная фиксация # # Изменения, которые будут приняты: # новый файл: .gitignore `
Sungam
1
Я считаю, что я дошел до сути этого. Git действительно вставляет # ------------------------ >8 ------------------------перед статусом txt «Похоже, вы можете быть…» _ при использовании scissors; однако, он вставляет строку ножницы после в # Conflicts: …тексте. Я commit.status = falseустановил в своем .gitconfig, так что я не видел текст статуса, только текст конфликта. Я исправлен; меняется на upvote.
Слипп Д. Томпсон
3

Используйте другой префикс для номера билета. Или добавьте слово к номеру билета, например, «Ошибка № 42». Или добавьте один пробел к строке; если вы хотите удалить этот пробел, вы можете добавить коммит-хук для этого.

Лично я предпочел бы, чтобы манипуляция сообщениями коммита не выполнялась с помощью хука, потому что это может быть очень раздражающим, когда оно срабатывает, когда вы этого не хотите. Возможно, самое простое решение - переосмыслить проблему.

wilhelmtell
источник
1
другая формулировка - только обходной путь для проблемы. если в руководстве проекта указано, что сообщение о коммите должно начинаться с идентификатора заявки, то оно не будет работать. и крюк после фиксации очень уродлив. я думаю, что должен сообщить об этой "ошибке" разработчикам git
knittl
Не беспокойся, это было бы неправильно. Не просите разработчиков git работать в соответствии с вашими рекомендациями. Вы бы не попросили Денниса Ритчи изменить язык Си, чтобы он поддерживал соглашение об именах переменных, начиная с символа хеша, верно? То же самое относится и здесь. Если в сообщениях коммитов разрешены комментарии, это добавляет поддержку интересных вещей, таких как открытие редактора коммитов с добавлением и закомментированием различий, поэтому вам не нужно запоминать свои точные изменения. Что плохого в сохранении ведущего космического персонажа?
Вильгельмтель
1
поддержка escape-символов в сообщении коммита git не была бы такой большой
проблемой
5
Это совершенно разумный запрос. Особенно в свете того факта, что Trac, AFAICT, не связывает фиксацию с ошибкой, если сообщение фиксации не начинается с номера квитанции, начиная с хеша. Так что это не просто чьи-то стандарты, это необходимый синтаксис инструмента. Пусть разработчики Git решат, стоит ли это того или нет. (И да, Trac также мог бы решить проблему. Нет ничего плохого в том, чтобы попросить Git сделать то, что он тоже может.)
Люк Маурер,
«Особенно в свете того факта, что Trac, AFAICT, не связывает фиксацию с ошибкой, если сообщение фиксации не начинается с номера квитанции, начиная с хеша». - из моего ограниченного опыта работы с Trac, что-то вроде того, что #xxxпроисходит в любом месте сообщения коммита, будет ссылаться на проблему. Это не обязательно должно быть в начале коммита. Может быть, это то, что изменилось за последние пять лет?
Гильденстерн
1

Все мои коммиты начинаются с #issueNumberтого, что я положил этот шаблон к своему vim .git/hooks/commit-msg:

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

Итак, давайте предположим, что у нас есть ветвь, #15и мы делаем сообщение коммита add new awesome feature. При таком подходе окончательное сообщение коммита будет #15 add new awesome feature.

valignatev
источник