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

Давайте рассмотрим реальный сценарий. Представьте, что вы работаете в компании и вам нужно исправить ошибку во внешнем интерфейсе их основного веб-сайта с помощью стека HTML, CSS и Javascript. При исправлении этой ошибки вам, возможно, придется изменить CSS, javascript или HTML. Теперь ошибка исправлена, вы должны отправить эти изменения в удаленный репозиторий компании, у компании есть правило писать подробное описание в сообщении о коммите, что вы изменили, почему вы это изменили и почему вы считаете это лучшим подход к исправлению ошибки.

Затем вам понадобится способ разделить каждое сделанное изменение, чтобы вы могли дать им индивидуальные описательные сообщения фиксации, и именно здесь в игру вступает git hunk.

Прежде чем я углублюсь в детали того, как использовать git hunk, я сосредоточусь на CLI (интерфейсе командной строки), ниже приведены термины (определенные в моих терминах, чтобы упростить их), о которых вам нужно знать.

Что такое кусок? Кусок – это кусок чего-то, отрезанный или отколотый от большего куска.

Что такое фрагмент Git? Это фрагмент измененного/неотслеживаемого кода или содержимого в файле, вырезанного из более крупного измененного/неотслеживаемого кода или содержимого в более крупном.

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

Демонстрация коммита без использования ханка и другого с использованием ханка

Код ошибки (main_code)

Демонстрация без git hunk

Из изображения main_code выше вы можете видеть, что это ошибки в строке 2 и строке 6, отображающие неверный вывод сообщений для мамы и папы соответственно.

исправленный код (ошибка исправлена)

Ниже приведена команда git для фиксации изменений после исправления ошибок.

Ниже приведен запрос на вытягивание на Github, обратите внимание, хотя я пытался сделать сообщение фиксации описательным. Всякий раз, когда я нажимаю на сообщение о коммите, оно перенаправляет меня ко всем внесенным изменениям, не правда ли, было бы неплохо, если бы оно привело вас именно к тому месту, где было сделано это конкретное изменение?

Пришло время увидеть преимущества ханка

Я все еще использую указанный выше код main_code, но способ фиксации изменений будет другим.

Ниже приведена команда git.

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

Шаг 1:git add -p ‹имя файла›

-p — это сокращение от patch, которое является флагом git. Вы увидите некоторые символы сразу после того, как поместите этот фрагмент, это доступные варианты, а ниже их значение.

  • y — поставить этот кусок.
  • n — не ставить этот кусок.
  • д — выйти; не ставить ни этот кусок, ни любой из оставшихся.
  • a — поместить этот фрагмент и все последующие фрагменты в файл.
  • d — не размещать ни этот ханк, ни какие-либо из последующих ханков в файле.
  • / — поиск фрагмента, соответствующего заданному регулярному выражению.
  • s — разделить текущий чанк на меньшие ханки.
  • e — редактировать текущий ханк вручную.
  • ? — распечатать справку.

Мы сосредоточимся на опции «s» (разделить текущий фрагмент на более мелкие фрагменты).

), поэтому мы можем выбрать, какой чанк использовать, а какой нет, используя опцию «y» или «n» соответственно.

Шаг 2. введите «s» и нажмите Enter (без кавычек).

Вам будут предложены меньшие фрагменты, разделенные на основе отредактированных / измененных файлов. В нашем случае он будет разделен на 2 фрагмента, теперь мы можем выбрать, какой фрагмент мы хотим разместить. Как показано ниже.

Изображение выше показывает нам, что ханк разделен на две части, и мы можем выбрать, какой ханк мы хотим обработать. Он показывает первый кусок, который представляет собой изменения, внесенные в функцию приветствия_мом, мы можем инсценировать его, просто введя «y».

Посмотрите на изображение ниже, я выбрал функцию welcome_mom для стадии, введя «y», а не функцию «greet_dad» для подготовки, введя «n», затем зафиксировал поэтапный кусок с описательным сообщением фиксации, а затем отправил его в мою удаленную ветку в другой, чтобы создать запрос на вытягивание.

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

Теперь давайте совершим коммит функции welcome_dad и напишем описательное сообщение коммита.

Поскольку функция welcome_dad — это единственный оставшийся модифицированный код, мы просто выбираем его и фиксируем, написав наше сообщение о коммите, и нажимаем. Ниже приведен коммит GitHub для обоих коммитов.

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

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

Теперь у вас есть новая суперсила (красавчик), используйте ее во благо 😃.

Не стесняйтесь оставлять комментарии или обращаться ко мне через LinkedIn по любым вопросам.