Одним из моих первых шагов в разработке iOS с моим наставником, помимо простого написания кода, было создание приемлемого запроса на включение (PR). Первый действительно не был похож на что-то хорошее. Серьезно. Даже после года обучения веб-разработке.

PR состоит в основном из двух элементов, скажем, головы и тела. Тело — это весь код, представленный в коммитах, а заголовок — это заголовок и описание.

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

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

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

#DP-15 [Добавить] фильтр в tableView

Для моих коммитов в коде я сократил типы модификаций до 5 категорий: Init, Add, Remove, Fix, Change. Когда коммит больше, чем, по моему мнению, должен быть, я также добавляю «Major».

  • Init — всегда относится к начальной фиксации
  • Добавить — относится к добавлению нового кода, который не влияет на уже существующий код.
  • Изменение — используется, когда какой-то код изменен для лучшей читабельности или добавлен новый код, который потребовал изменения существующего.
  • Удалить — всегда связано с удалением кода, комментариев и т. д.
  • Исправить — всякий раз, когда изменение рассматривается как проблема, будь то неправильное название или возможный результат ошибки, но в основном изменения, запрошенные рецензентом.
  • Major — я использую каждый раз, когда затрагивается большой фрагмент кода, будь то любая из категорий. Он предупреждает рецензента о значительных изменениях содержания. Но сведите его к минимуму, только когда это необходимо, если вы не можете создать функциональный короткий коммит.

например: #DP-20 [Основное изменение] добавить идентификатор ко всем объектам

Когда у вас правильно установлено тело, голова становится легче.

Откуда я это узнал (для более подробного PR):



Как создать хороший запрос на слияние — с примерами и шаблонами
По мере роста бизнеса команды становятся больше, кодовая база тоже растет, и возникает необходимость отслеживать изменения…oumaima-dahhoum.medium.com



Очень полезно привязать PR-заголовок к предоставленному билету. С типом вашей ветки в квадратных скобках, будь то целое приложение или элемент. И имя/заголовок вашего запроса на включение. Например:

#LI-50 [Приложение iOS] ‹Название вашего приложения›или#CS-15 [Компонент React] ‹имя компонента›для‹названия веб-сайта›

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

Лично я предпочитаю разделить его на пять разделов с соответствующими названиями.

  • Что? — Что делает кусок кода в вашем PR. Это только часть какого-то приложения или целое приложение, интерфейс или сервер? Небольшое описание кода.
  • Почему? — Какова цель вашего пиара. Что-то исправить в существующем коде, добавить что-то новое? Какова цель и результат вашего кода.
  • Как? — Какие изменения были внесены, используемые фреймворки, изменения в UI. Добавлено новое, старое исключено.
  • Влияние? — Если код влияет на существующий код, вы действительно должны определить это здесь. Избегает больших проблем в случае конфликтов слияния, упрощает их поиск. Хорошо отметить, в каких существующих файлах был изменен код.
  • Тестирование? — Все анализы ты сделал. Будь то симуляция или физическое устройство, тестирование фреймворков с обратной связью. Где тестировалось приложение, на каком устройстве, с какой ОС или ПО.

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

Спасибо за чтение! Надеюсь, он окажется полезным для вас и вашей команды! Удачи!