Как часто фиксировать изменения в контроле источника?

Ответ 1

В любое время, когда я завершаю "полную мысль" кода, который компилирует и запускает мою регистрацию. Обычно это заканчивается между 15-60 минутами. Иногда это может быть больше, но я всегда пытаюсь проверить, есть ли у меня много изменений кода, которые я бы не хотел переписывать в случае сбоя. Я также обычно проверяю, что мой код компилируется, и я регистрируюсь в конце рабочего дня, прежде чем я вернусь домой.

Я бы не стал беспокоиться о том, чтобы "слишком много" совершать/регистрировать. Это действительно отстой, когда вам нужно что-то переписывать, и приятно иметь возможность отката с небольшими приращениями на всякий случай.

Ответ 2

Когда вы говорите, что вас беспокоит, что ваши "коммиты влияют на весь репозиторий" --- вы ссылаетесь на то, что весь номер ревизии репозитория увеличивается? Я не знаю, сколько бит Subversion использует для его хранения, но я уверен, что у вас не останется номеров версий! Многие коммиты не являются проблемой. Вы можете совершать в десять раз чаще, чем парень по соседству, и вы не увеличите свой углеродный след вообще.

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

Ответ 3

Мне нравится эта маленькая статья от Джеффа Этвуда: Заходите рано, часто заходите

Ответ 4

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

Ответ 5

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

Ответ 6

Я выполняю каждый раз, когда выполняю задачу. Это обычно занимает от 30 минут до 1 часа.

Ответ 7

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

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

Ответ 8

Я следую мантрам с открытым исходным кодом (перефразированный) - совершает ранний, фиксирует часто.

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

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

Ответ 9

Если ваш комментарий к управлению версиями длиннее одного или двух предложений, вы, вероятно, недостаточно часто совершаете.

Ответ 10

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

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

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

Ответ 11

Я не думаю, что вы должны так беспокоиться о том, как часто. Важно то, что, когда и почему. Говорить, что вы должны совершать каждые 3 часа или каждые 24 часа, на самом деле не имеет смысла. Зафиксируйте, когда у вас есть что-то зафиксировать, не делайте этого.

Здесь выдержка из моего рекомендовала лучшие методы контроля версий:

[...] Если вы делаете много изменений в проекте одновременно, разделите их на логические части и зафиксируйте их в нескольких сеансах. Это значительно облегчает отслеживание истории отдельных изменений, что позволит вам сэкономить много времени, пытаясь найти и исправить ошибки позже. Например, если вы реализуете функции A, B и C и исправляете ошибки 1, 2 и 3, это должно привести к сумме не менее шести коммитов, по одному для каждой функции и по одному для каждой ошибки. Если вы работаете над большой функцией или выполняете обширный рефакторинг, подумайте о том, чтобы разделить вашу работу на еще более мелкие части и совершить фиксацию после завершения каждой части. Кроме того, при внедрении независимых изменений в несколько логических модулей фиксируйте изменения для каждого модуля отдельно, даже если они являются частью более значительного изменения.

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

Ответ 12

Ваш текущий шаблон имеет смысл. Имейте в виду, как вы используете этот источник управления: что делать, если вам нужно откат, или если вы хотите сделать diff? Описанные вами фрагменты кажутся точно подходящим дифференциалом в этих случаях: diff покажет вам, что именно изменилось при реализации ошибки # (указано в журнале регистрации) или точно, что новый код для реализации функции. Откат, аналогично, будет касаться только одной вещи за раз.

Ответ 13

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

Вот связанное сообщение в блоге: Ужас кодирования: заходите рано, часто заходите

Ответ 14

Как утверждали другие, попробуйте зафиксировать один "полный" логический фрагмент, который не будет доступен другим разработчикам (например, он строит и передает автоматические тесты).

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

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

Ответ 15

Момент, когда вы думаете об этом.

(пока вы проверяете безопасность)

Ответ 16

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

Ответ 17

Я согласен с несколькими ответами: не проверяйте код, который не будет компилироваться; используйте личную ветку или репозиторий, если у вас есть "резервная копия" кода или его изменений; проверьте, завершены ли логические блоки.

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

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

Ответ 18

Мне нравится фиксировать изменения каждые 30-60 минут, если они компилируются чисто и в модульных тестах нет регрессий.

Ответ 19

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

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

Конечно, я никогда не совершаю то, что не компилируется.

Ответ 20

Не реже одного раза в день.

Ответ 21

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

Ответ 22

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

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

Мы использовали 2 полностью отдельных репозитория: один из них - это общий репозиторий проекта, а другой - наш собственный репозиторий (мы использовали rcs в то время).

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

Как только у нас был кусок кода, который бы скомпилировал, протестировал ok и был принят как готовый для общего использования, он был проверен в репозитории проекта.

К сожалению, эта система полагалась на использование различных технологий VCS для обеспечения работоспособности. Я не нашел удовлетворительного метода достижения тех же результатов при использовании двух из VCS того же типа (например, двух хранилищ подрывной деятельности)

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

Ответ 23

Если вы работаете над веткой, которая не будет выпущена, фиксация всегда безопасна.

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

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

Ответ 24

Я все еще верю в фразу "совершать часто, совершать раньше". Я предпочитаю децентрализованный VCS, например Mercurial, и нет никаких проблем, чтобы совершить несколько действий и нажать его вверх по течению позже.

Это действительно общий вопрос, но реальный вопрос: можете ли вы сделать незавершенный код?

Ответ 25

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

И убедитесь, что вы правильно комментируете.

Ответ 26

Я также хочу регулярно регистрироваться. Это каждый раз, когда я завершаю шаг к своей цели.

Это обычно каждые пару часов.

Моя трудность заключается в поиске кого-то желающего и способного выполнять так много обзоров кода.

Наша политика компании заключается в том, что нам нужно иметь обзор кода, прежде чем мы сможем проверить что-нибудь в нем, что имеет смысл, но не всегда есть кто-то из отдела, у которого есть время, чтобы немедленно выполнить обзор кода. Возможные решения:

• Больше работы за проверку; меньше проверок == меньше отзывов.
• Измените политику регистрации компании. Если я только что переработал рефакторинг, а модульные тесты запускаются зелеными, возможно, я смогу ослабить правило?
• Поставьте изменения, пока кто-то не сможет выполнить обзор и продолжить работу. Это может быть проблематично, если рецензент не нравится, когда вы код, и вы должны перепроектировать. Жонглирование различными этапами задания путем "отложенных" изменений может стать беспорядочным.