Как часто совершать изменения в системе контроля версий? [закрыто]

Как часто мне следует вносить изменения в систему контроля версий? После каждой маленькой функции или только для больших функций?

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

Тем не менее, я обеспокоен этой картины. В продуктивный рабочий день я мог бы сделать 10 коммитов. Учитывая, что я использую Subversion, эти коммиты влияют на весь репозиторий, поэтому мне интересно, действительно ли это хорошая практика - делать так много?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вот выдержка из рекомендуемых мной рекомендаций по управлению версиями :

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

По крайней мере, один раз в день.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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