Коммиты в git

Перейдите к следующему слайду, нажав кнопку Вправо

Разбираемся, что такое коммиты и зачем они нужны

Подготовлено онлайн-курсом

https://dvmn.org

Зачем мне ваши коммиты?

Представьте, что вы работаете над проектом. У вас есть рабочая версия сайта, которая приносит вам деньги. Теперь вы решили внести несколько изменений сразу в нескольких файлах, да ещё и в течение недели. Шаг влево - шаг вправо и всё сломалось. Вы замучились и решили вернуть как было. А вернуть уже не получается - изменений много.

Решение: хранить все версии в отдельных папках

Каждая папка будет весить как весь проект. А если вы решите проверить что вы поменяли в очередной папке - придётся это делать глазами.

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

версия1

версия2

версия2 без бага

версия антона

версия за 21.10.2018

Решение: использовать систему контроля версий

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

версия2

"Добавил новую фичу"

"Добавил новую фичу"

История коммитов

Как выглядят коммиты?

Короткое (50 или менее символов) описание

 

Более подробное описание, если оно нужно. Обычно оно не более 72 символов в строке. Отступ после заголовка коммита перед его описанием обязателен. Обычно описание оставляют пустым и пишут только заголовки.

 

Тут можно делать новые параграфы, в которых будет ещё больше текста.

 

  - Маркированные списки тоже поддерживаются

 

  - Обычно между пунктами ставят дополнительные переносы строк

Заголовок коммита.

Описание коммита

Ваша история всё ещё рискует выглядеть так

Критерии хорошего заголовка коммита

  • Атомарный
  • Не длиннее 50 символов
  • С большой буквы
  • Объясняет "что" и "зачем", а не "как"
  • В одном стиле
  • Желательно на английском

Атомарность

Пофиксил баг #34, баг #36, поправил опечатку, переименовал переменную

Как не надо:

Как лучше:

Пофиксил баг #34

Пофиксил баг #36

Поправил опечатку

Переименовал переменную для улучшения читаемости кода

Почему:

Если изменения атомарны - легче отменить какое-то одно из них.

Не длиннее 50 символов

Как не надо:

Как лучше:

Почему:

Если строчка слишком длинная - её не хочется читать. 50 символов - не строгое правило, но если коммит получился длиннее - стоит задуматься как перефразировать его. Или, может, разбить на два?

Поправил баг, связанный с фоном нашего сайта. Вместо синего цвета на нашем сайте показывался голубой, это было вызвано...

Поправил фон с голубого на синий

С большой буквы

Почему:

Это придаёт целостности истории коммитов, как будто она написана одним человеком.

Как лучше:

Как не надо:

Пофиксил баг #34

пофиксил баг #36

Поправил опечатку

пофиксил баг #38

поправил опечатку

Пофиксил баг #39

Пофиксил баг #34

Пофиксил баг #36

Поправил опечатку

Пофиксил баг #38

Поправил опечатку

Пофиксил баг #39

Объясняет "что" и "зачем", а не "как"

Почему:

Когда вы будете искать что-то в истории - будет удобнее искать тот коммит, где вы починили баг или добавили фичу, а не где вы "Поменял функцию foo()" или "Написал функцию bar()". Или вот смотрите вы на коммит и не понятно зачем вы меняли эти файлы. Сообщение всё объяснит.

Как не надо:

Как лучше:

Поменял функцию send_message()

Починил отправку сообщений для отправки писем самому себе

В одном стиле

Почему:

Имеется ввиду то, как вы будете это делать: в повелительном наклонении или нет, в прошедшем времени или нет... В интернете существует много споров насчёт того, как это делать правильно, но все согласны, что стиль должен быть един. Мы стараемся проговаривать в голове "Этот коммит..." перед названием коммита, чтобы фраза звучала целое

Как лучше:

Как не надо:

Пофиксил баг #34

Пофиксит баг #36

Поправляет опечатку

Баг #38 теперь исправлен

Опечатка исправится

Починил баг #39

Пофиксил баг #34

Пофиксил баг #36

Поправил опечатку

Пофиксил баг #38

Поправил опечатку

Пофиксил баг #39

Желательно на английском

Почему:

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

Для коммитов на английском есть и общепринятый стиль, проговаривать в голове "
If applied, this commit will" перед сообщением коммита, чтобы оно звучало как продолжение этой фразы.

Создано для онлайн-курса https://dvmn.org