Я искренне верю, что иметь один коммит по одному вопросу - хорошая практика. Я уверен, что я прочитал это где-то в статье, как «Лучшие практики».

Таким образом, мой рабочий процесс был следующим:

Для нового выпуска я создаю новую локальную ветку сgit checkout -b new-issue.Зафиксируйте все изменения в нем. Иногда это включаетмного коммитов.Когда я закончуsquash совершает иrebase их в текущую тематическую ветку.Если что-то пойдет не так, я могуgit revert зафиксировать, найти ошибку, исправить ее и зафиксировать новый патч в тематической ветке. Я не буду изменять историю удаленного хранилища.

Но сегодня я был удивлен, услышав следующий рабочий процесс:

Создайте новую ветку для нового выпуска.Передайте все в это.использованиеmerge --no-ff объединить ветку проблемы с тематической веткой (поэтому у нас будет «merge-commit», который мы можемrevert).Если что-то пойдет не так, мы можем использоватьgit bisect найти ошибку.

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

Согласно второму подходу, у нас будет очень грязная история, с большим количеством уродливых, ненужных слияний и коммитов только для одной проблемы. Тем не менее, мы можем использоватьgit bisect чтобы найти ошибки. (Возможно, это лучше для рефакторинга?)

Какие плюсы и минусы вы видите для обоих подходов?

Какой подход вы используете и почему?

На практике вы использовалиgit bisect найти ошибки? (У меня нет ...)