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

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

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

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

(если то, что вы регистрируете, безопасно)

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

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

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

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

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

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

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

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

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

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

Хотя бы раз в день.

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

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

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

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

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

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

Вот соответствующее сообщение в блоге: Coding Horror: заезжай раньше, заезжай почаще

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

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

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

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

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

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

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

Однако я добился приемлемых результатов, создав «личные» ветки разработки в репозитории Subversion - регулярно проверяя ветку, а затем сливаясь с основной веткой по завершении.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[...] If you are doing many changes to a project at the same time, split them up into logical parts and commit them in multiple sessions. This makes it much easier to track the history of individual changes, which will save you a lot of time when trying to find and fix bugs later on. For example, if you are implementing feature A, B and C and fixing bug 1, 2 and 3, that should result in a total of at least six commits, one for each feature and one for each bug. If you are working on a big feature or doing extensive refactoring, consider splitting your work up into even smaller parts, and make a commit after each part is completed. Also, when implementing independent changes to multiple logical modules, commit changes to each module separately, even if they are part of a bigger change.

Ideally, you should never leave your office with uncommitted changes on your hard drive. If you are working on projects where changes will affect other people, consider using a branch to implement your changes and merge them back into the trunk when you are done. When committing changes to libraries or projects that other projects—and thus, other people—depend on, make sure you don’t break their builds by committing code that won’t compile. However, having code that doesn’t compile is not an excuse to avoid committing. Use branches instead. [...]

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

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

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

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

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

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

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

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

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

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

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