этот коммит нигде не будет опубликован, а затем исправлен позже!

нтересно, возможно ли постепенно создавать сообщения git commit, документируя то, что я делаю, когда я делаю изменения кода:

Проверьте и начните работуВведите название сообщения коммита (т.е. сводка)Внести изменения в кодОбновите мое сообщение о коммите, чтобы описать изменениеПовторите 3 и 4, пока коммит не будет готов

Есть ли какой-нибудь механизм, встроенный в git для этого?

 Matt Greer25 янв. 2011 г., 23:13
Это больше о предпочтениях, чем объективности, но я не думаю, что ваши коммиты должны быть достаточно большими, чтобы требовать этого. Небольшие сплоченные коммиты являются находкой, когда приходит время откатиться или просмотреть историю изменений.
 Cascabel25 янв. 2011 г., 23:27
В дополнение к частому предложению о внесении поправок, вы также можете использовать rebase для объединения всех рассматриваемых коммитов (возможно, с помощью функции fixup / autosquash).
 MatrixFrog30 янв. 2011 г., 00:00
Подобный вопрос, возможно, даже дубликат:stackoverflow.com/questions/3743999/...
 mtbkrdave01 мар. 2012 г., 23:37
Небольшие атомные коммиты определенно предпочтительнее. Но даже можно работать над небольшими атомными коммитами в течение нескольких дней или недель, в зависимости от того, сколько внимания уделяется проекту. Я обычно стремлюсь к атомарности, которая хорошо вписывается в работу одного дня, но иногда это просто не работает таким образом.

Ответы на вопрос(3)

делать это так), попробуйте это:

Проверьте и начните работуСделайте некоторые изменения кодаgit commitСделайте некоторые дальнейшие изменения кодаgit commit --amendПовторите 4 и 5git commit --amend --reset-author для дальнейшего сброса метки времени
 mtbkrdave01 мар. 2012 г., 23:34
Это эффективно для решения проблемы, ноубедись этот коммит нигде не будет опубликован, а затем исправлен позже!

которое вы делаете, которое требует сообщения. Это особенно легко с распределенной системой управления версиями, такой как git, которую вы используете.

Проверьте и начните работуВнести изменения в кодВведите сообщение коммита и подтвердитеПовторите 2 и 3Push обновления

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

 William Pursell26 янв. 2011 г., 12:00
@medicdave Вот для чего нужны ветки тем. Каждый небольшой коммит может нарушить сборку, но вы выполняете слияние без ускоренной перемотки с master, поэтому все коммиты на master чистые и проходят набор тестов.
 Igor25 янв. 2011 г., 23:10
Это дает преимущество перечисления ваших фактических инкрементальных изменений с каждым коммитом (а не с одним большим).
 mtbkrdave25 янв. 2011 г., 23:13
В идеале да, это так. Но иногда небольшие изменения могут нарушить работу кода в других областях (особенно при поддержке кода с плохой связью, чтогм должно быть написано кем-то другим), требуя переделки, не связанной с первоначальным изменением. В таких ситуациях стремление к небольшим атомарным коммитам противоречит желанию только коммитить работающий, протестированный код. В этих ситуациях вы в конечном итоге портируете на diff-файлы, чтобы написать полезное сообщение о коммите после внесения изменений.
 mtbkrdave01 мар. 2012 г., 23:33
@WilliamPursell хороший вызов ... Я недавно начал использовать git-flow (и мне это нравится!), И поэтому мое понимание процесса ветвления в Git значительно улучшилось!
Решение Вопроса

git commit может принять сообщение из файла, используя-F вариант. Итак, вы можете сделать что-то вроде этого:

# Do some work
$ echo 'Did some work' > commit-msg.# Do some more work
$ echo 'Did some more work' >> commit-msg.
$ git commit -F commit-msg.
 mtbkrdave25 янв. 2011 г., 23:15
Отлично - если этот файл не размещен или находится за пределами репозитория, это хорошее решение для неоптимальной ситуации, указанной skco. Спасибо!
 Cascabel25 янв. 2011 г., 23:29
@medicdave: если вы пойдете с этим, вместо того, чтобы вносить поправки / сжатие, вы можете добавить commit-msg.txt в .git / info / exclude, чтобы он был проигнорирован в этом хранилище, чтобы вы не смогли случайно его поставить.

Ваш ответ на вопрос