Как комментировать каждое изменение в файлах, чтобы они были видны для git, но скрыты в реальных файлах - PullRequest
0 голосов
/ 16 февраля 2020

Когда я разрабатываю функцию, мне обычно нужно менять несвязанные файлы: утилиты, помощники. Но не только те. Бывают случаи, когда какое-то хранилище событий не связано с этой функцией, а просто содержит дополнительный код, позволяющий разработать основную функцию.

Изначально я просто пропустил эту проблему. Но теперь я понимаю, что трудно понять, почему я изменил некоторые файлы, если они не связаны с функцией, которую я зафиксировал. Мне нужно что-то вроде обычных комментариев в файлах, но они должны быть видны только для git: когда я просматриваю сообщение / историю коммитов, я хочу понять, почему я сделал конкретное c изменение. Я не могу комментировать каждое изменение. Самая большая проблема заключается в том, что мое изменение может заключаться не просто в добавлении строк кода, а в удалении. Никому не нужно видеть комментарии для отсутствующих строк.

Моя первая идея - зафиксировать изменения с комментариями в файлах, а затем сделать еще один коммит для удаления комментариев. Это как обходной путь. Я работаю в PhpStorm. И я всегда вижу git историю там. Я хочу открыть файл из коммита и посмотреть, почему я сделал некоторые изменения. Я был бы очень полезен для меня. Очень полезный. Для меня это дает ту же прибыль, что и я, получая сообщение о коммите.

Я не вижу других решений. Возможно, у кого-то еще была такая проблема.

Я также предполагаю, что другие git GUI программы могут иметь такую ​​функцию.

Ответы [ 2 ]

1 голос
/ 17 февраля 2020

Просто список идей, которые нужно попробовать.

  1. Используйте комментарии github или bitbucket. Они довольно милые. Недостатком является то, что они хранятся в собственном формате сервера и не доступны локально.

  2. Использовать заметки; запустите git notes add <commit>, тогда у вас есть редактор, куда вы можете вставить (частичные) различия и прокомментировать их. Они хранятся в базе данных git, и их было бы относительно удобно использовать, если вы можете позволить себе командную строку. Но популярные инструменты отстают в своей поддержке.

  3. Отдавайте изменения в файлы помощника. Таким образом, у вас есть специальное место, чтобы комментировать их. Но тогда вам не придется отказываться от sh ваших слияний по запросу, чтобы история сохранялась, или создавать отдельные PR.

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

  5. Не не удаляйте комментарии в файле. Если некоторые операции неочевидны из имени функции, возможно, стоит прокомментировать их обоснование.

1 голос
/ 16 февраля 2020

Ну, почему бы не использовать для этого сообщение git commit?

Вы можете добавить несколько строк в сообщение фиксации, указав множество параметров -m:

git commit -m "My commit message (headline)" -m "Second line" -m "third line..."

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

Чтобы настроить редактор, просто запустите:

git config core.editor vim

PS: я рекомендую посмотреть, как люди пишут сообщения коммитов в больших репозиториях, таких как linux one (https://github.com/torvalds/linux). Посмотрите, насколько информативны там сообщения и вдохновитесь:)

...