Предыдущий ролик Следующий ролик  

Видео урок: Написание сообщения для коммита

Git: обучение основам

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

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

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

Маркируйте то, что он делает. Он фиксит баг, а не я фикшу баг. Речь идет не о вас, речь идет о коммите. Если вам нужен список, в котором описано, что произошло, вы обычно используете звездочки или дефисы. Также вы можете использовать номера багов, или поддерживать запросы, или разработать сокращения в своей организации. Вы можете, например, в квадратных скобках впереди сообщения написать, что вы работаете с CSS или с JavaScript, или можете маркировать исправления багов при помощи bugfix:, или поставить впереди отслеживающий номер, который является ярлыком поддерживающего запроса.

Эти виды описаний на самом деле являются личными предпочтениями, вашими или согласованными в вашей организации. Однако это хорошо - принять стандарты, а затем придерживаться их, и таким образом каждый, кто работает с хранилищем, использует одинаковый набор соглашений для сообщений коммитов. Итак, нужно писать четкие и описательные сообщения, вот, например, "Исправить опечатку", это плохой коммит, в котором не говорится, что происходит. Хорошим коммитом было бы "Добавить отсутствующий > в раздел проекта в HTML. Гораздо более описательный коммит того, что происходит, в чем заключается опечатка, что нужно было сделать, чтобы ее исправить.

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

Это не имейл, и это не способ общения с другими членами команды, мы можем общаться и другим способом. Что нам нужно действительно сделать, это добавить хорошую метку, что находится внутри коммита. Давайте рассмотрим пример хорошего коммита. И вот это хорошее сообщение, в нем есть отслеживающий номер, это соглашение, которое использует данная компания для отслеживающей информации, t23094 - Фиксирует баг в логауте для администратора. Оно немного расплывчатое, но у нас есть некоторая информация в нем, которая делает его более описательным. Когда администратор выходит, он не может затем войти как член, поскольку сессия :user_id все еще установлена на ID администратора.

Этот патч исправляет баг, устанавливая сессию :user_id на nil, когда любой пользователь выходит из любой области. Обратите внимание, что в нем описано, в чем заключалась проблема и какое было решение. Так что все на месте. Если мы на него просто посмотрим, нам на самом деле не нужно просматривать код, ведь мы прекрасно понимаем, что пытался сделать создатель этого коммита. Это хорошая метка для коммита, которая показывает, что произойдет, если мы применим этот набор изменений к проекту. Итак, я упоминал, что первая строка должна быть менее 50 символов, а последующие строки должны быть меньше 72 символов.

Кстати, самая длинная строка в этом коммите занимает порядка 60 символов. И вот теперь вы понимаете, как поместить все на строке, вы можете пойти немного дальше, эта строка занимает 60 символов, а затем вам нужно просто нажать Return и продолжить писать дальше. Так вот, я надеюсь, вы поняли, что значит написать хорошее, описательное сообщение для коммита, так, чтобы все наши коммиты были хорошо маркированы. Это действительно важно при работе с Git, поскольку Git работает с этими слепками коммитов и позволяет нам обмениваться ими между репозиториями. Поэтому очень важно иметь хорошо маркированные коммиты, так чтобы, если Боб сделает коммит, а затем Мэри захочет вставить этот коммит в свой проект, она смогла посмотреть на него, понять, в чем состоит коммит, и вставить его в свой проект, чтобы он стал его частью.

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