Каковы хорошие стратегии проверки исходного кода для больших задач?

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

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

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

Я использую git, поэтому мой ответ - "ветка". Разветвитесь и сделайте кусочек еды, выполняя различные биты.

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

Когда все довольны кодом, объединяйтесь, и все готово!

(То, что я склонен делать для относительно длительных веток, это периодически объединять магистраль (master, в терминологии git) с моей веткой, поэтому две ветви не слишком сильно расходятся.)

Я думаю, что ответ будет варьироваться в зависимости от того, какую систему управления версиями вы используете: централизованную (например, subversion) или распределенную (например, git). У меня нет реального опыта использования распределенной системы контроля версий, поэтому мой ответ основан на том, что мы делаем с Subversion.

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

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

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

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

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

Точно так же, как обычный комментарий от людей на сервере SQL "это зависит"

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

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