Я новичок в git и пытаюсь использовать его следующим образом (AFAIK, это довольно распространенный рабочий процесс для одного разработчика):
- Создайте ветку функций и поработайте над нейэто, с некоторыми WIP-коммитами.
- Когда закончите, реорганизуйте эти WIP-коммиты в хорошо согласованные (те, которые проходят компиляцию и тестирование), чтобы иметь чистую историю.
- Объединить ветвь функции в master .
Теперь я собираюсь перенести некоторые из моих проектов (связанных с одним рабочим пространством, т.е. рабочим деревом) в новую версию компилятора.В ветке функций msvc90 я подготовил много работы для выполнения.У меня есть два варианта:
- Создание одного большого коммита (-m "миграция на MSVC 9.0").
- Создание нескольких коммитов, чтобы сохранить несколько шагов миграции в истории(создание новых файлов проекта, удаление старых, настройка исходного кода, чтобы избавиться от предупреждений компилятора, исправление ошибок и т. д.).Обратите внимание, что эти коммиты сами по себе не могут быть согласованными (например, использование нового файла проекта с ненастроенным исходным кодом приведет к ошибкам компиляции).
Мой вопрос довольно философский.Второй вариант кажется мне немного более предпочтительным, поскольку он хранит больше деталей в истории.С другой стороны, я прочитал некоторые учебники по git, которые рекомендуют хранить только согласованные коммиты (например, использовать bisect).
Кто-нибудь знает примеры больших проектов, политика которых позволяет хранить непоследовательные коммиты такого рода (onфункция ветки)?