11 Советы по коммитам: сообщения, ярлыки и количество файлов

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

Вы становитесь вечно ответственными за совершенные вами изменения

«Себя»

Перед советами по фиксации я люблю начинать с перевода. Обязательство можно перевести как:

• «совершать» в смысле «делать», «выполнять».
• Или «совершить», потому что вы находитесь с ним в серьезных отношениях.

Поэтому для того, чтобы эти отношения имели счастливый конец, прислушайтесь к этим советам:

Локальная фиксация и удаленная фиксация

Первый совет по фиксации может показаться довольно простым. Так и есть.

Но интересно понять разницу между локальными коммитами (на вашем компьютере) и коммитами в удаленном репозитории:

• Если они одинаковы, то вы находитесь в актуальном состоянии
• Если в локальном хранилище есть коммиты, которых нет в удаленном, вам нужно в какой-то момент переместить их с помощью git push.
• Если все наоборот, вам нужно сделать git pull.
• Если в истории есть разные коммиты, существует вероятность возникновения конфликтов во время git pull.

Это как если бы у вас на компьютере была папка Google Drive с вашим TCC, синхронизированная с облаком. Разница в том, что для каждой синхронизации необходимо создать небольшой пакет под названием commit. И этот пакет содержит один или несколько файлов.

Один или несколько? Сколько файлов?

Сколько файлов включить в фиксацию

Ответ на этот вопрос такой же, как и всегда: зависит от обстоятельств!

Я склонен делать небольшие коммиты, то есть то, что можно легко объяснить и описать. Таким образом, в будущем будет легче найти конкретное изменение.

Часто изменения в одном и том же файле должны принадлежать разным коммитам.

Представьте себе ситуацию, когда вы изменили верхний и нижний колонтитулы и некоторые разделы главной страницы сайта.

Здесь фиксация может быть выполнена двумя способами:

Пример 1: все файлы только в одном коммите

Коммит будет выглядеть следующим образом:

[28ea8b4] Alterações no header, footer e seções da home
# Changes to be committed:
#       modified:   header.html
#       modified:   index.html
#       modified:   footer.html
#

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

Когда вы откроете коммит 28ea8b4, вы увидите несколько измененных файлов, включая заголовочные файлы. Это загрязняет историю фиксации и затрудняет поиск в будущем (что, поверьте мне, произойдет).

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

Пример 2: несколько файлов, разделенных на большее количество коммитов

Один из моих любимых советов по фиксации.

Гораздо приятнее делать коммиты с меньшим количеством файлов. Посмотрите, как выглядела бы предыдущая ситуация:

[28ea8b4] Alterações no header
# Changes to be committed:
#       modified:   header.html

[bfbfff1] Alterações no footer
# Changes to be committed:
#       modified:   footer.html

[c23a7cb] Alterações nas seções da home
# Changes to be committed:
#       modified:   index.html

Если однажды вам понадобится восстановить те же изменения, внесенные в нижний колонтитул, фиксация покажет гораздо меньше модификаций.

Помимо того, что их легче читать, коммиты меньшего размера легче откатывать. Исправить ошибку в заголовке здесь гораздо проще.

Вот и все! Вы знаете, сколько файлов нужно поместить в коммит. Вот советы о том, как на самом деле совершить его.

Советы по использованию команды Git Commit

Пришло время закрыть пакет.

Внеся некоторые изменения и поместив их в stage с помощью git add ., вы можете зафиксировать их несколькими способами.

Базовая фиксация в Git

Самая основная команда — это:

git commit

Это откроет ваш текстовый редактор (Nano, Vim или сам VS Code) для ввода сообщения о фиксации. Как только вы введете сообщение о фиксации, сохраните и выйдете из файла, фиксация будет выполнена.

Другой способ — ввести сообщение о фиксации прямо в командной строке:

git commit -m "Minha mensagem de commit"

Эта команда хороша тем, что все выполняется за один «выстрел». Это избавит вас от необходимости открывать текстовый редактор.

«Git add + Git commit

С помощью этой команды вы добавляете файлы и фиксируете их одновременно:

git commit -am "Minha mensagem de commit"

Но берегитесь! Эта команда не добавляет в коммит неотслеживаемые файлы, то есть файлы, созданные после последнего коммита.

В этом случае сделайте вот так:

git add .
# ou git add --all
git commit -m "Minha mensagem de commit"

Если какой-то файл остался незамеченным, не волнуйтесь и смотрите следующий совет по фиксации:

Внести изменения в обязательства

Здесь, вместо создания нового, файлы вставляются в последний коммит.

Вот пример. В вашей истории есть два обязательства:

[28ea8b4] Alterar script.js
# Changes to be committed:
#       modified:   script.js

[bfbfff1] Alterar style.css
# Changes to be committed:
#       modified:   style.css

И вы готовы добавить два файла в третьем коммите: index.html и about.html. Затем выполните:

git commit -am "Criar página index e about"

Однако, поскольку about.html был создан после последнего коммита, он был оставлен без внимания (забыт на барбекю). А его история выглядит следующим образом:

[28ea8b4] Alterar script.js
# Changes to be committed:
#       modified:   script.js

[bfbfff1] Alterar style.css
# Changes to be committed:
#       modified:   style.css

[c23a7cb] Alterar index.html e about.html
# Changes to be committed:
#       modified:   index.html

Затем просто выполните два действия:

1. Добавьте about.html на этапе
2. И выполнить изменение

git add . 
# ou git add --all
# ou git add about.html

git commit --amend

В этот момент текстовый редактор откроет сообщение от последнего коммита (c23a7cb). После сохранения и закрытия файла в него будет добавлен about.html. И ваша история будет выглядеть следующим образом:

[28ea8b4] Alterar script.js
# Changes to be committed:
#       modified:   script.js

[bfbfff1] Alterar style.css
# Changes to be committed:
#       modified:   style.css

[c23a7cb] Alterar index.html e about.html
# Changes to be committed:
#       modified:   index.html
#       modified:   about.html

Помните пример с Google Drive, который я приводил? Вместо того чтобы создавать несколько переименованных файлов таким неудобным способом (work.docx, work_final.docx, work_final_now_going_to.docx), вы изменяете один и тот же файл и сообщаете в сообщении об изменениях (и версиях).

И именно об этих посланиях я сейчас и расскажу.

Советы о том, как составить хорошее сообщение о фиксации

Если вы поищете в Интернете, вы найдете несколько конвенций о том, как написать хорошее сообщение о фиксации.

Главный совет: не тратьте лишнее время на сообщение о фиксации, если оно не приносит пользы проекту.

• Обычные фиксации
• Семантическая версия
• Название и описание обязательств

Все это очень хорошо, если только это имеет смысл для проекта, команды, объема и т.д.

Помните, что когда вы завершаете фиксацию, вы находитесь в идеальном пространстве-времени для создания его сообщения. Другими словами:

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

Поэтому пишите хорошие сообщения для своих коллег и для себя в будущем. Они будут вам благодарны.

Что не должно отсутствовать в сообщении о фиксации

Выразите основную мысль с помощью хорошего глагола.

Когда я пишу свои сообщения, «главная мысль» такова:

• Исправление: что-то работает одним способом, а должно работать по-другому (или не работает вообще)
• Добавить: создать или внедрить что-то новое. Это относится к компонентам, страницам и новым функциям
• Remove: очень удовлетворительная часть, которая заключается в том, чтобы выбросить то, что больше не используется
• Рефакторинг: то, что больше сосредоточено на лучших практиках кода, чем на создании ценности для клиента

Я могу думать о других ситуациях как об улучшении или изменении. Но оба подходят под понятия исправления или рефакторинга. И, конечно же, очень приветствуются глаголы-синонимы.

Если вы знаете другие глаголы, которые не подходят под эти, дайте мне знать в комментариях, потому что я хочу знать.

Выяснив глагол, дополните его частью кода или приложения, с которым вы столкнулись. Смотрите другие примеры:

• Исправьте модальность
• Добавить кнопку
• Удалить компонент
• Рефакторинг кода

Как видите, эти посты «почти» интересны. Проблема в том, что каждый из них оставляет сомнения в сознании того, кто их читает.

Какой модал? Какая кнопка? Какой компонент был удален? Код?

Поэтому я обычно дополняю его более подробной информацией:

• Исправьте не открывающийся модал оплаты
• Добавьте CTA-кнопку о герое на главную страницу
• Удалите старый видеокомпонент
• Рефакторинг кода функции параллакса

На данный момент я думаю, что послание достаточно ясно. Но что, если детали слишком велики?

Длина сообщения о фиксации

50 символов.

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

В этом случае я рекомендую вам добавлять меньше файлов на сцену и делать меньшие коммиты.

Если сообщение все еще слишком большое, вы можете разделить его на title и description. Оставьте вторую строку пустой:

Remover revalidate do repositório 

O revalidate foi removido das seguintes páginas:
- about
- contact
- index
- [page]
- [slug]
# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
#
# On branch main
# Your branch is up to date with 'origin/main'.

А вот как это выглядит на Github:

Теперь вот что я считаю не рекомендуемыми сообщениями для фиксации (будучи легкомысленным).

Что не следует писать в сообщении о фиксации

Злодейские советы.

Короче говоря, если некоторые из перечисленных выше пунктов отсутствуют, мне трудно написать хорошее сообщение.

Если в нем не проясняется, что произошло, он идет тем же путем.

После написания прочитайте свое сообщение. Если в голову приходят какие-то вопросы, переосмыслите их.

• Изменения, запрашиваемые в ПР: что это за изменения?
• Отменить предыдущий коммит: что делать с тем, что было сделано в предыдущем коммите? Почему бы не сделать git reset?
• Несколько коммитов с одним и тем же сообщением (например, create about page): эй, сколько страниц about page вы создали?
• Случайные вещи типа m, test, add, one more commit: серьезно, мой освященный?

Если вы не большой поклонник команд терминала, вам может понравиться делать это с помощью ярлыков VS Code.

Выполнение фиксации с помощью ярлыка VS Code

Некоторое время назад я начал работать с Git’ом, используя только горячие клавиши.

Я нашел его настолько практичным, что не даю себе и месяца, чтобы забыть команды Git.

Для начала зайдите в свой VS Code FIle > Preferences > Keyboard shortcuts (или используйте сочетание клавиш CTRL + K + S). В поле поиска ярлыков введите:

git.commit

Дважды щелкните на опции Git: Commit и нажмите на ярлык, который вы хотите назначить для нее.

Эй, пссс!

Я слышал, вы любите короткие пути.

Вот еще 35 советов по использованию ярлыков VS Code!

Теперь, когда вы нажимаете на ярлык, просто введите свое сообщение в поле, которое появляется в верхней части VS Code:

Если это поле кажется вам слишком маленьким для ввода сообщения, как насчет того, чтобы использовать для этого вкладку VS Code?

Редактирование сообщений Git в VS Code

И с этим советом по фиксации вы закроете золотой ключик.

Вы можете редактировать сообщения, как если бы вы находились в файле кода. Перейдите в меню File > Preferences > Settings (или сочетание клавиш CTRL + ,). В поле поиска настроек введите:

Git: use editor As Commit Input

git commit -am "Minha mensagem"

git add .
git commit -m "Minha mensagem"