Разве нормально иметь нарушенные промежуточные коммиты, пока работает финальный коммит в любом пуше?

Связано: должен ли каждый git коммит оставлять проект в рабочем состоянии?

Предположим, я делаю следующие коммиты локально:

• Модифицировать схему базы данных, ломая приложение.

• Обновите приложение, чтобы оно снова было совместимо со схемой базы данных.

Пока я нажимаю обе коммиты, masterостается в рабочем состоянии. Однако историческая версия нарушена.

Я знаю, что я могу использовать, git rebase -iчтобы раздавить коммиты вместе. Однако итоговый коммит будет большим и менее описательным. Если мне нужно будет просмотреть историю коммитов, чтобы выяснить, почему я что-то изменил, я бы предпочел найти исходный коммит, показывающий, что я сделал и почему.

Мои вопросы:

• Кто-нибудь сталкивался с трудностями из-за сломанных исторических коммитов в мастере?

• Если так, есть ли простой способ избежать таких трудностей, не отбрасывая отдельные сообщения о коммитах и ​​изменения?

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

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

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

Модель Git, получившая высокую оценку ветвления, позволяет не допускать прерывания коммитов в определенных ветвях, например, если ваша команда использует gitflow или его упрощенную версию. Что-нибудь с политикой "чистого хозяина". В этом случае вы могли бы отметить окончательную рабочую версию как коммит слияния, где (неработающие) исторические версии доступны в репозитории, но не в основной строке.

Если ваша команда не приняла такую ​​модель ветвления, то у вас есть веское оправдание, чтобы просто подтолкнуть весь участок к освоению и покончить с этим.

Нет, это не хорошо.

Если вы когда-либо делали git bisect(и кто не любит эту убийственную особенность), вы знаете ценность истории, в которой строится каждый коммит.

Если у вас есть много коммитов, bisectкоторые не строятся, у вас будет много git bisect skips, которые затруднят поиск последнего хорошего коммита.

Если вы завершили ветвь объектов и слили ее с master, очистите ветку перед слиянием, чтобы ваша история была чистой и строительной.

Кто-нибудь сталкивался с трудностями из-за сломанных исторических коммитов в мастере?

Да. Backports, возврат и деление сложнее. Так читает историю (см. Ниже).

Если так, есть ли простой способ избежать таких трудностей, не отбрасывая отдельные сообщения о коммитах и ​​изменения?

Не то, чтобы я знал, хотя филиалы - достойное решение.

Тем не менее, я думаю, что отмена (или, скорее, раздавливание) отдельных коммитов - это правильная вещь.

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

Однако, как только функция / изменение готово к отправке, фиксация представляет собой пакетное изменение - в идеале атомарное, поэтому его можно [просмотреть, перебазировать, объединить, выбрать вишню, отменить, просмотреть в аннотации] независимо от других изменений, насколько это возможно. ,

Глядя на историю проекта, изменение программного обеспечения должно оцениваться само по себе. Это строит? Это идет с тестами? Это работает? Что оно делает? Какие файлы необходимо изменить, чтобы предоставить эту функцию?

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

Краткий ответ: да

Тестирование:

Разработка через тестирование означает, что вы пишете тесты, которые ломаются (то есть показывают неудачу).
Затем вы пишете код, чтобы тесты работали.

Разработка:

Фиксация малая, Фиксация часто.
Каждый коммит является точкой отката. Если вы понимаете, что находитесь на неправильном пути, вы можете относительно легко вернуться к предыдущему пункту. Если коммиты достаточно мелкие, вы можете вернуться к правильной точке.

Предостережение:

Это не значит

1) Вы проверяете неработающий код в мастере.
2) Вам нужно нажать на все микро коммиты, чтобы все могли их просмотреть.

Используйте ветки, чтобы делать свою работу. Потенциально сжимать микроммиты для процессов обзора, чтобы они были в логически различных единицах с соответствующими комментариями. Если вы используете git, вы не потеряете первоначальный набор коммитов, вы можете просто создать новый, более логичный набор коммитов для процедур рецензирования, которые будут объединены с мастером.

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