Как провести рефакторинг в ветке, не теряя рассудок?

Question

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

Решения, которые я знаю:

1. Постоянное слияние с магистралью и обратно - уменьшает болезненные слияния, но тогда зачем вообще работать в ветке?
2. Всякий раз, когда вам нужно что-то реорганизовать, переключитесь на Trunk, проведите там рефакторинг и объединитесь с вашей веткой - я не считаю это очень практичным, поскольку реальная стоимость переключения сред для каждого рефакторинга огромна.

Что ты делаешь?

Answer 1

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

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

Зачем вообще работать в ветке в таком случае? Потому что у вас больше контроля (вы можете прекратить слияние с транком, чтобы стабилизировать его для выпуска, например, без остановки регистрации в вашей ветке разработки). Потому что вы можете установить высокий уровень проверки при слиянии с транком, не сильно влияя на скорость регистрации в ветке разработки.

Answer 2

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

Answer 3

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

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

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

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

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

Answer 4

Я бы предложил следующую стратегию для сценариев, когда промежуток времени между выпусками составляет не менее 2 месяцев.

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

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

Answer 5

Непрерывная интеграция - это ключ ... 1 небольшая партия изменений за раз ...

Answer 6

Фиксация рано, коммит часто.

Или в этом случае ... Объединяться рано, часто сливаться.

Answer 7

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

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

Answer 8

Это то, где хороший распределенный VCS превосходит. Но я предполагаю, что вы уже преданы SVN.

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

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