Коммить как про
Создание коммитов - одна из наиболее обыденных вещей, которую многие разработчики делают, участвуя в репозитории git. Вы вносите свои изменения в стейджинг и коммитите их, чтобы они сохранились в истории. Но что насчет лучших практик? Есть ли разница между грязно написанным коммитом и чисто и свежо написанным? Стоит ли использовать эмодзи в сообщении коммита? В этой статье мы поговорим о некоторых наиболее распространенных соглашениях и лучших практиках git commit, чтобы научиться делать идеальные коммиты.
1. Стадия стейджинга
Представьте, что ваши правки - это актеры. Прежде чем вы сделаете коммит, у ваших правок должны быть какие-то роли, которые они сыграют на сцене. Если они проявят себя хорошо, то получат право на коммит, в противном случае их следует отбросить. Поэтому не имеет смысла коммитить изменения, если им не удается хорошо "сыграть".
1.1. Когда и что добавлять в стейджинг
Вы должны убедиться, что ваши изменения в коде имеет связь между собой. Если вы можете описать изменения в нескольких словах, чтобы следующий разработчик(и) мог легко понять, что вы сделали, основываясь на сообщении вашего коммита, то все в порядке. Но не смотря на то, что вы можете расписать сообщение коммита на несколько строк, никогда не объединяйте несвязанные изменения вместе.
2. Стадия создания коммита
Нет ничего страшного в том, если в истории вашего репозитория будут сотни коммитов. Git оптимально сохраняет историю файлов, которые есть в вашем проекте, чтобы не отнимать лишнее место и ресурсы, поэтому не стесняйтесь делать коммиты тогда, когда это необходимо.
2.1. Что коммитить
Git - это система контроля версий, основанная на строках кода. Это означает, что она отслеживает строки, которые были изменены, а не фразы или слова. Если вы измените один символ в строке, то вся строка будет отслеживаться, а не слово. Как мы узнали выше, убедитесь, что строки, которые вы изменили, связаны друг с другом: то есть, они реализуют одну функцию или служат какой-то другой цели.
2.2. Как собрать правки в коммит
У вас могут быть изменения в разных частях разных файлов, и вы можете выбрать, какие из них закоммитить. Представьте, например, что у вас веб-проект с файлами CSS и JS. Вы добавили параграф в HTML и стили для него в CSS. Параллельно вы добавили функцию в JS для формы обратной связи в одном из шаблонов. С помощью git add --patch вы можете выбрать, какие из этих правок добавить в стейджинг, ответив на несколько вопросов.
2.3. Сообщения коммитов
Сообщение коммита - это точка вашего контакта с разработчиком, который будет вносить изменения в те же строки кода, что и вы, в будущем. Пусть этот разработчик окажется доволен вашим сообщением.
Итак, когда вы коммитите изменения, вам нужно прикрепить к ним сообщение. Каждое сообщение коммита имеет заголовок, описание и кое-какие метаданные. Заполнять заголовок обязательно, однако описание является опциональным. Лучше всего, если сообщение будет коротким и ясным, чтобы другие разработчики могли понять смысл ваших изменений, прочитав только заголовок сообщения.
2.4. Управляйте issue с помощью ключевых слов в сообщении коммита
Некоторые платформы, использующие git для управления репозиториями, такие как GitHub, пошли дальше и реализовали особые возможности для пользователей git. Например, если вы напишете одно из ключевых слов Close, Closes, Closed, Fix и пр. перед хэштегом issue, то как только ваш HEAD будет равен этому коммиту, упомянутый issue будет закрыт. (Не совсем корректно, issue будет закрыт, когда коммит будет замержен в главную ветку репозитория. Прим. пер.) Таким образом, вы можете автоматически закрыть issue из сообщения коммита.
git commit -m 'Устаревание исправлено Closes #215'2.5. Не используйте эмодзи
Я видел репозитории, у которых есть собственные соглашения о сообщениях коммитов. Они могут использовать эмодзи, чтобы показывать статус коммита, будь то фикс, тест или что-то иное.
Лично я стараюсь не использовать эмодзи в своих коммитах. У вашего репозитория могут быть участники с разных платформ. Поскольку эмодзи используют специальные коды Unicode (которые редко используются и зачастую не поддерживаются в текстовых интерфейсах, таких как CLI), и большинству терминалов требуется сторонний пакет или шрифт для работы с ними, то такое соглашение может показаться не всем удобным. Они могут столкнуться с проблемами при чтении истории изменений и сообщений коммитов. (Например, эмодзи в заголовке сообщения могут отображаться как нечитаемые символы или вопросительные знаки).
В такой ситуации лучше всего использовать префиксы, чтобы показать категорию коммита. Например, [СЛОВОМ] в скобках в начале строки. На следующем изображении, кстати, используется формат тип коммита: сообщение:
2.6. Описание сообщения
Если вы добавите свои изменения в стейджинг и откроете текстовый редактор для написания сообщения коммита, вы сможете добавить дополнительную информацию о коммите, например, причины сделанных правок, исправленные баги, TODO (если они есть) и так далее. Заголовок по-прежнему является самой важной частью сообщения. Несмотря на то, что описания необязательны, не стесняйтесь заполнять их для своих коммитов. Если ваши изменения достаточно сложны и требуют дополнительных разъяснений, описание сообщения коммита - это то самое место, где вы можете их оставить.
Кроме того, если вы поддерживаете свои коммиты такими же простыми и короткими, как их сообщения, вы почти достигнете идеала в искусстве создания коммитов.
3. Разные соглашения git
Git вообще не навязывает соглашения сам по себе. Они создаются компаниями и командами. Одна команда может посчитать эмодзи полезной практикой в своей работе, а другая хочет сохранить простоту и наглядность. Одна команда может пушить непосредственно в main (это соглашение также известно как single-branch convention), а у другой команды есть ветка development, и она пушит в main только релизные коммиты. Даже если вы не поддерживаете соглашения, принятые в вашем месте работы, вам лучше все равно следовать им. То время, которое вы потратите на то, чтобы переубедить коллег, возможно, лучше потратить на поиск и исправление багов.
Заключение
В этой статье мы раскрыли некоторые основные соглашения и лучшие практики git commit. Мы поговорили о плюсах и минусах каждой практики и, наконец, выяснили, что Git не несет ответственности за них, так как их создают компании и стартапы.
Материал подготовлен с ❤️ редакцией Кухни IT.
