Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 16
мне кажется или что-то было прям переведено гуглом.
Субъективно — тяжело читается. например вот это:
> Пользователь перенаправляется на домашнюю страницу после авторизации,
> что отличается от оригинальной запрошенной страницы до авторизационной
> формы, это создает некоторое неудобство пользования.
Субъективно — тяжело читается. например вот это:
> Пользователь перенаправляется на домашнюю страницу после авторизации,
> что отличается от оригинальной запрошенной страницы до авторизационной
> формы, это создает некоторое неудобство пользования.
Предложите автору свой вариант. Как по мне — вполне себе связное и подходящее для ситуации сообщение.
Предлагаю:
Линус Торвальдс теперь верстает сайты для молодых мам.
Как минимум не английский порядок слов:
Если вы употребляете в своём лексиконе:«авторизационная форма», то вы как минимум странный!)
После авторизации пользователь перенаправляется на домашню страницу,
которая отличается от запрошеной до появления формы авторизации. Это создаёт некоторое неудобство пользования сайтом|приложением.
Если вы употребляете в своём лексиконе:«авторизационная форма», то вы как минимум странный!)
После авторизации пользователь перенаправляется на домашню страницу,
которая отличается от запрошеной до появления формы авторизации. Это создаёт некоторое неудобство пользования сайтом|приложением.
Я так понимаю, что это привет от невозможности связать коммит с породившей его задачей?
Никогда не используйте флаги для сообщения -m / --message
Данные флаги позволяют создавать многострочное описание коммита. Если не закрывать строку, то можно добавлять переносы нажатием на Enter.
Я понял так, что автор имел ввиду, это чисто психологический аспект, чаще всего мы делаем коммит с консоли, используя -m "" и не вдумываемся в содержание, сделал и забыл, Caleb Thompson упирает на то, что бы каждый коммит имел смысл.
Практически всегда использую только однострочные комментарии при комите + номер тикета.
Т.е. в этом случае — что-то вроде "#NNNN After login, redirect customer to requested page instead of home page".
Это позволяет просматривать историю более компактно и избавляет от многострочных комитов, которые выглядят как
"#NNNN fixed redirect issue \n (много текста по сути изменения)".
А такое длинное описание — ему место в тикете (описание проблемы) + комментарии в коде.
Т.е. в этом случае — что-то вроде "#NNNN After login, redirect customer to requested page instead of home page".
Это позволяет просматривать историю более компактно и избавляет от многострочных комитов, которые выглядят как
"#NNNN fixed redirect issue \n (много текста по сути изменения)".
А такое длинное описание — ему место в тикете (описание проблемы) + комментарии в коде.
Как показала практика, проще всего подобрать описание в одну строчку, тогда легче найти что-то по истории.
Являюсь сторонником грамотно написанных сообщений к коммитам, но некоторые советы написанные в статье — это через чур, по крайней мере для моего workflow.
Покажу на примере — мне нужно сделать модальное окно для авторизации. Что делаем сначала? Правильно, создаем новую ветку в названии которой уже можно проследить, для чего она создана, к примеру — feature-authorization-on-modal-windows. Потом делаем частые маленькие коммиты, описывающие зачем мы это сделали (специально посмотрел сейчас log — в основном коммиты по 50-70 символов). Когда задача сделана и протестирована, вливаем ее в qa или основную ветку, а вот тут, в merge коммите и можем описать все что написано в 4 пункте и зачем, и почему именно так, и какие проблемы могут возникнуть.
В общем к чему это я — не копируйте слепо, то что вам советуют, применяйте к своему рабочему процессу. Ну и, конечно, пишите грамотные сообщения к коммитам, всегда думайте, а можно ли определить по этому сообщению, что именно я сделал, без использования diff.
autocmd Filetype gitcommit setlocal spell textwidth=72 и Никогда не используйте флаги для сообщения -mДостаточно спорные советы — если вы правильно пользуетесь гитом и у вас частые атомарные коммиты, то вы будете повторяться в сообщениях к каждому коммиту, просто для того чтобы обойти ограничение.
Покажу на примере — мне нужно сделать модальное окно для авторизации. Что делаем сначала? Правильно, создаем новую ветку в названии которой уже можно проследить, для чего она создана, к примеру — feature-authorization-on-modal-windows. Потом делаем частые маленькие коммиты, описывающие зачем мы это сделали (специально посмотрел сейчас log — в основном коммиты по 50-70 символов). Когда задача сделана и протестирована, вливаем ее в qa или основную ветку, а вот тут, в merge коммите и можем описать все что написано в 4 пункте и зачем, и почему именно так, и какие проблемы могут возникнуть.
В общем к чему это я — не копируйте слепо, то что вам советуют, применяйте к своему рабочему процессу. Ну и, конечно, пишите грамотные сообщения к коммитам, всегда думайте, а можно ли определить по этому сообщению, что именно я сделал, без использования diff.
Еще дополнение по поводу пункта 5:
Во многих проектах, таких как github, gitlab, redmine и прочих, можно прямо в сообщениях к коммиту делать ссылки на соответствующие issue, к примеру «Resolve bug with ugly modal window in IE9 #123» станет ссылкой на issue 123 в веб-интерфейсе. Можно даже управлять issue при помощи определенных слов, к пример «Resolve bug with ugly modal window in IE9,fix #123» автоматически закроет этот тикет.
Во многих проектах, таких как github, gitlab, redmine и прочих, можно прямо в сообщениях к коммиту делать ссылки на соответствующие issue, к примеру «Resolve bug with ugly modal window in IE9 #123» станет ссылкой на issue 123 в веб-интерфейсе. Можно даже управлять issue при помощи определенных слов, к пример «Resolve bug with ugly modal window in IE9,fix #123» автоматически закроет этот тикет.
пользуйтесь багтрекером и вставляйте номер тикета в сообщение коммита (если он в default) или именуйте бранчипо номеру тикета (если бранч). тогда в коммите достаточно сказать «добавил тестов» или «поправил баг с авторизацией» а не писать простыни — IMHO это большооой overkill.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Пять полезных советов при составлении коммит сообщения