littleguga
@littleguga
Не стыдно не знать, а стыдно не интересоваться.

Как правильно комментировать коммит?

Может есть какой-то стандарт, о котором я не знаю?

По правилам английского языка, если я добавил какую-то фичу, то действие произошло в прошлом - надо ставить во 2 форму(неправильный глагол или ed на конце).
Соответственно: "added header navigation". Но многие пишут "add header navigation"

Я понимаю, что скорее всего это не принципиально, но хотелось бы услышать Ваше мнение(граммар-наци, все дела).

Примеры:
Вот тут, большинство коммитов написано правильно с точки зрения англ языка.
Но тут везде пишут add/remove/clean - то есть в настоящем времени, что немного странно.
  • Вопрос задан
  • 1216 просмотров
Решения вопроса 6
saboteur_kiev
@saboteur_kiev
software engineer
Чаще встречал стандарт писать в настоящем
add, remove

Но дело не в граммар наци.
В CI часто бывает автоматические отчеты по сделанным изменениям, или например в каждый билд идет автоматом экстракт изменений из всех коммитов, автоматическая генерация release notes

То, что вы закоммитили изменения, еще не значит что они были применены к самому приложению, его еще нужно обновить. И тогда
"При установке данного фикса будет выполнено следующее"
add...
remove...
Ответ написан
vicodin
@vicodin
Имею некоторый опыт
я воспринимаю это как команды, ну то есть этот коммит добавляет такой-то функционал, прошедшее время неуместно в описании действия
Ответ написан
@abcd0x00
Может есть какой-то стандарт, о котором я не знаю?

Вообще, сам git скачай в виде исходников, там есть файл SubmittingPatches.

Выдержка оттуда
(1) Make separate commits for logically separate changes.

Unless your patch is really trivial, you should not be sending
out a patch that was generated between your working tree and
your commit head.  Instead, always make a commit with complete
commit message and generate a series of patches from your
repository.  It is a good discipline.

Give an explanation for the change(s) that is detailed enough so
that people can judge if it is good thing to do, without reading
the actual patch text to determine how well the code does what
the explanation promises to do.

If your description starts to get too long, that's a sign that you
probably need to split up your commit to finer grained pieces.
That being said, patches which plainly describe the things that
help reviewers check the patch, and future maintainers understand
the code, are the most beautiful patches.  Descriptions that summarise
the point in the subject well, and describe the motivation for the
change, the approach taken by the change, and if relevant how this
differs substantially from the prior version, are all good things
to have.

Make sure that you have tests for the bug you are fixing.  See
t/README for guidance.

When adding a new feature, make sure that you have new tests to show
the feature triggers the new behaviour when it should, and to show the
feature does not trigger when it shouldn't.  Also make sure that the
test suite passes after your commit.  Do not forget to update the
documentation to describe the updated behaviour.

Speaking of the documentation, it is currently a liberal mixture of US
and UK English norms for spelling and grammar, which is somewhat
unfortunate.  A huge patch that touches the files all over the place
only to correct the inconsistency is not welcome, though.  Potential
clashes with other changes that can result from such a patch are not
worth it.  We prefer to gradually reconcile the inconsistencies in
favor of US English, with small and easily digestible patches, as a
side effect of doing some other real work in the vicinity (e.g.
rewriting a paragraph for clarity, while turning en_UK spelling to
en_US).  Obvious typographical fixes are much more welcomed ("teh ->
"the"), preferably submitted as independent patches separate from
other documentation changes.

Oh, another thing.  We are picky about whitespaces.  Make sure your
changes do not trigger errors with the sample pre-commit hook shipped
in templates/hooks--pre-commit.  To help ensure this does not happen,
run git diff --check on your changes before you commit.


(2) Describe your changes well.

The first line of the commit message should be a short description (50
characters is the soft limit, see DISCUSSION in git-commit(1)), and
should skip the full stop.  It is also conventional in most cases to
prefix the first line with "area: " where the area is a filename or
identifier for the general area of the code being modified, e.g.

  . archive: ustar header checksum is computed unsigned
  . git-cherry-pick.txt: clarify the use of revision range notation

If in doubt which identifier to use, run "git log --no-merges" on the
files you are modifying to see the current conventions.

The body should provide a meaningful commit message, which:

  . explains the problem the change tries to solve, iow, what is wrong
    with the current code without the change.

  . justifies the way the change solves the problem, iow, why the
    result with the change is better.

  . alternate solutions considered but discarded, if any.

Describe your changes in imperative mood, e.g. "make xyzzy do frotz"
instead of "[This patch] makes xyzzy do frotz" or "[I] changed xyzzy
to do frotz", as if you are giving orders to the codebase to change
its behaviour.  Try to make sure your explanation can be understood
without external resources. Instead of giving a URL to a mailing list
archive, summarize the relevant points of the discussion.

Ответ написан
sim3x
@sim3x
ИМО прошедшее неопределенное, стоит использовать, если ты не в курсе, когда что-то изменилось
Те в каких-то прошлых коммитах кто-то наваял, а в етом коммите тебе нужно обьяснить почему тебе пришлось что-то писать в текущем

Тема конечно спорная
stackoverflow.com/questions/3580013/should-i-use-p...

Главное правило - все должны писать в одном стиле
Ответ написан
@inapped
Например

add/remove/clean - то есть в настоящем времени, что немного странно.

Можно рассматривать заголовки коммитов как действия, применяемые к коду, а не рассказ о том, что в них было сделано.
Ответ написан
Freika
@Freika
Ruby on Rails developer
Я пишу примерно так:

Add some feature ... and delete obsolete feature code
Remove some code ...
Update ...
Fix ...

То есть строго информативные комментарии по конкретной задаче. Исправили код слайдера - пишите Fix slider implementation.
Ответ написан
Пригласить эксперта
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы