Тип фиксации перед выполнением функции

Question

Обычные коммиты определяет несколько типов сообщений коммитов, таких как feat, fix, chore, ci et c.

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

feat: коммит типа feat вводит новую функцию в кодовая база (это коррелирует с MINOR в semanti c версиях).

Таким образом, этот тип фиксации должен использоваться только один раз (в противном случае CHANGELOG, сгенерированный из этих фиксаций, перечислит много функции, которые действительно являются только частями определенной функции).

Мне интересно, каков общий рабочий процесс для решения коммита (и pu sh) на ранней стадии и часто с использованием обычных коммитов?

каждый squa sh их коммиты в коммит типа feat: ...? Существуют ли другие рабочие процессы?

Какие типы сообщений используются до фиксации feat?

Answer 1

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

Answer 2

Как хороший разработчик, я хочу фиксировать рано и часто

То есть "release / publi sh рано и часто", а не коммитить. Когда ваш коммит не имеет отношения к стандартному рабочему процессу Git, потому что коммиты являются локальными, поэтому они могут быть изменены до того, как вы опубликуете sh (и вы должны изменить их, см. Ниже ).

Все ли в клетке sh свои коммиты совершают в умение: ... тип коммита? Существуют ли другие рабочие процессы?

Есть много рабочих процессов, и не все хороши. Например, и сжатие всех коммитов в один, и оставление временных / WIP-коммитов - неправильные подходы.

Коммиты должны быть независимыми единицами работы с течением времени. Если ваша функция может быть разделена на 5 коммитов, которые имеют смысл сами по себе, то вам следует это сделать. Смысл в том, чтобы сделать их как можно более простыми для понимания и максимально обратимыми.

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

---

Я предлагаю вам взглянуть на сам проект Git, а также Linux ядро (проект, для которого он был создан) делает это.

Answer 3

Все ли сква sh свои коммиты совершают на умение: ... тип коммита?

Да. Ну, я делаю. На самом деле, я работаю в частном порядке над функцией, используя две ветви. Одна из них - это ветвь функций, которую я расскажу позже. Другой - это временная рабочая ветка, где я часто сохраняю. Время от времени я сква sh сливаюсь с темпом до конца функции. Таким образом, у temp есть 30 коммитов, а у функции 2 или 3. В вашем случае звучит так, как будто вы хотите, чтобы он был только один!

Также имейте в виду, что вы можете вносить поправки, интерактивно rebase / squa sh , сброс, и т. д. c., чтобы переписать вашу ветку до того, как она будет нажата в первый раз. Таким образом, вам на самом деле не нужно две ветви; Вы можете использовать одну ветку для раннего и частого сохранения, а затем полностью переписать свою историю перед нажатием.