Каковы хорошие критерии для внесения изменений в хранилище? - PullRequest
3 голосов
/ 28 марта 2009

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

Ответы [ 9 ]

6 голосов
/ 28 марта 2009

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

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

Однако, перед тем как опубликовать их, перепишите коммиты (например, git rebase -i origin / master #). Найдите смысл в беспорядке, который вы создали, и создайте набор понятных и чистых коммитов с хорошими сообщениями коммитов и убедитесь, что каждый из них проходит любые проверки качества, которые у вас могут быть. Тогда опубликуйте это.

3 голосов
/ 28 марта 2009

Это действительно зависит от того, является ли это вашим личным репо или репо, которым пользуются многие разработчики? Как далеко вы в проекте?

Лично я фиксирую свои репозитории subversion, когда я заканчиваю с одним аспектом, и все компилируется. Оно не должно быть полным, просто не сломанным. Я предпочитаю не оставлять вещи сломанными в первую очередь.

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

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

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

2 голосов
/ 28 марта 2009

Некоторые основные вещи:

  1. Стремитесь совершить за «логическое изменение»; исправление ошибки, рефакторинг, функция, ...
  2. Запустите свои модульные тесты перед передачей кода; убедитесь, что вы ничего не сломали (у вас есть юнит-тесты, не так ли).
  3. Если в среде нескольких разработчиков; обновите репозиторий и снова запустите модульные тесты, чтобы убедиться, что никакие конфликтующие изменения не сломали чей-то код (ваш или их).
  4. Исправьте при необходимости и повторите с 3 до тех пор, пока ничего не сломается.
  5. Немедленно совершите коммит и скрестите пальцы.
  6. Положитесь на свои тесты непрерывной интеграции, чтобы сказать, сломалось ли что-то еще.
1 голос
/ 28 марта 2009

Зафиксируйте только один тип изменения за раз.

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

1 голос
/ 28 марта 2009

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

1 голос
/ 28 марта 2009

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

0 голосов
/ 28 марта 2009

Зафиксируйте любой код, который вы не хотите писать снова:)

0 голосов
/ 28 марта 2009

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

Примечание: это просто тесты дыма, которые я автоматизирую / запускаю перед фиксацией. Регрессионные тесты оставлены для непрерывной интеграции.

0 голосов
/ 28 марта 2009

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

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

Если скомпилировать + функции должным образом + хорошо протестировано == 'зафиксировать, когда это работает', тогда это похоже на соответствующее правило.

...