Фиксация изменений - это одна из самых распространенных вещей, которую делают многие разработчики, когда вносят какие-либо изменения в код. Вы это делаете, чтобы изменения можно было отследить в истории. Но как насчет каких-либо правил написания коммитов? Есть ли разница между грязным коммитом и чистым? Использование эмодзи для заголовка сообщения об изменениях? В этой статье мы поговорим о некоторых общих соглашениях и лучших практиках git commit для того, чтобы сделать идеальный #коммит .
1. Фаза постановки
Рассматривайте свои изменения как программист. Прежде чем вы зафиксируете свои изменения, ваши изменения должны что-то делать. Если они работают хорошо, они будут пригодны для документирования, в противном случае их стоит переделать. Поэтому не имеет смысла, если ваши изменения не работают, но вы их коммитите.
1.1. Когда и что ставить
Вы должны убедиться, что между изменениями, которые вы вносите в строки, есть связь. Если вы можете описать изменения в нескольких словах, чтобы следующий #разработчик мог легко понять, что вы сделали, основываясь на вашем сообщении о фиксации, то все в порядке. Даже если вы можете сделать несколько строк сообщений для ваших коммитов, никогда не объединяйте изменения вместе.
2. Фаза фиксации
Нет никакой проблемы, если в истории вашего проекта сотни коммитов. Git фактически хранит манифест файлов, которые есть в вашем проекте, так что у вас не закончится место и ресурсы, поэтому не стесняйтесь делать коммиты, когда это необходимо.
2.1. Что фиксировать
Git - это система контроля версий, основанная на строках, что означает, что она отслеживает строки, которые были изменены, а не фактическую фразу или слово. Если вы измените один символ в строке, будет отслеживаться эта строка, а не слово. Как мы узнали ранее, убедитесь, что строки, которые вы изменили, связаны друг с другом, так как они работают вместе, чтобы выполнять определённую функцию или служить чему-то.
2.2. Как объединять hunks в коммитах
Вы можете изменить несколько файлов в некоторых блоках и добавить эти блоки из любого файла, а затем скомпоновать их и подготовить к коммиту. Рассмотрим веб-проект, в котором есть несколько CSS и JS файлов. Представьте, что вы добавили несколько абзацев в файл index и теперь придаете им стиль в файле CSS. Тем временем вы создаете функцию в JS-файле для контактной формы в вашем шаблоне. Просто используйте команду git add --patch для установки этих конкретных блоков, ответив на несколько вопросов.
2.3. Сообщения о коммитах
#Commit Message - это место, где вы обращаетесь к следующему контрибьютору, который собирается внести свой вклад в ту же самую строку (строки) за один раз. Пусть они получат удовольствие, когда прочитают ваше сообщение. По сути, когда вы хотите зафиксировать поэтапные изменения, вам нужно поместить на них сообщение. Каждое сообщение о фиксации имеет заголовок, описание и некоторые метаданные. Разработчику необходимо заполнить заголовок. Однако заполнение описания является необязательной задачей. Лучше всего, если оно будет коротким и понятным, чтобы другие разработчики могли понять ваши изменения, прочитав заголовок коммита.
2.4. Управление проблемами с помощью специальных ключевых слов в Commit Message
Некоторые платформы, использующие Git в качестве контроллера репозитория, такие как #GitHub , пошли дальше и имеют специальные функции в сообщениях Git. Например, если вы используете ключевые слова Close, Closes, Closed, Fix и т.д. перед тегом проблемы, то как только ваш HEAD будет равен этому коммиту, упомянутая проблема будет закрыта. При этом вы можете просто закрывать проблемы в заголовке сообщения коммита. Подробнее об этой возможности читайте на GitHub.
$ git commit -m 'deprecation fixed Closes #215 '
2.5. Не используйте эмодзи
Наша редакция видела, что некоторые репозитории имеют свои собственные #соглашения в случае создания сообщений о фиксации. Они используют эмодзи, чтобы показать статус коммита, будь то исправление, тест или любой другой вид коммита.
Многие разработчики избегают использования эмодзи в своих сообщениях о фиксации. У вас могут быть участники с разных платформ и интерфейсов. Поскольку эмодзи используют специальные коды ASCII (не часто используемые и не поддерживаемые в текстовых интерфейсах, таких как CLI) и системы Unicode, а большинство интерфейсов командной строки нуждаются в сторонних пакетах или шрифтах для работы с ними, это соглашение может не всем понравиться. Они могут столкнуться с некоторыми проблемами в плане чтения историй и проверки сообщений о фиксации. (Например, символ эмодзи в заголовке сообщения может отображаться как его реальный ASCII-код или неизвестные вопросительные знаки).
В этом случае лучше всего использовать префиксный шаблон, чтобы показать категорию фиксации как слово в скобке в начале файла. На следующем изображении, кстати, используется формат type: message.
2.6. Описание сообщения
Если вы сохраните свои изменения и откроете текстовый редактор после фиксации изменений для отправки сообщения, вы можете добавить дополнительную информацию о самом коммите, например, о требованиях, ошибках, "что сделать" (возможно) и так далее. Раздел заголовка по-прежнему является самой важной частью сообщения о фиксации. Несмотря на то, что раздел описания является необязательным, не стесняйтесь их делать для своих коммитов. Если ваши изменения довольно сложны и требуют дополнительных объяснений, вы можете написать больше о различных аспектах ваших изменений в разделе описания.
Наконец, мы можем просто сказать, что если вы будете делать свои коммиты простыми и короткими, так же как и ваши сообщения о коммитах, вы почти попадете в цель.
3. Различные соглашения Git
Git вообще не создает соглашений - они разрабатываются компаниями и командами. Одна команда может найти эмодзи очень полезными в своей платформе, но другая хочет сохранить простоту. Одна команда может писать непосредственно в Main ветку (также известная как single-branch convention), но у другой команды есть ветка development, и она пишет в Main ветку только релизные #коммиты . Если вы работаете в месте, где их соглашения могут показаться для вас не очень хорошими, вам лучше следовать им. Время, которое вы потратите на то, чтобы переубедить их, возможно, поможет вам исправить некоторые ошибки.
Заключение
В этой статье мы познакомились с некоторыми основными соглашениями и лучшими практиками git commit. Мы поговорили о плюсах и минусах каждой практики и, наконец, выяснили, что Git не несет ответственности за соглашения, они создаются компаниями и стартапами.