Если вы улучшите качество кода во время работы над функциональной ветвью

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

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

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

Такое ощущение, что есть несколько недостатков, чтобы исправить это:

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

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

Меня предупредили, что это основано на мнении (я думаю, что это не входит в название should), но я чувствую, что ответ есть (конечно, люди используют оба этих подхода, поэтому у них должен быть ответ). Кроме того, вопросы development methodologiesпо теме, и я думаю, что они требуют определенного мнения.

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

Например. Я работаю над функцией «печатать кроликов» и нахожу код принтера

Public class Printer(string type)
{
    If(type=="bunnies")
    {
        //print a bunny
    }
.....
}

Я изменяю это на:

Public class Printer(string type)
{
     PrintFunctionDictionary[type].Print();
}

Зачем:

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

Я не случайно выбираю какую-то другую часть базы кода и «делаю ее лучше», как это будет:

• Столкновение с людьми, работающими над другими функциями.
• Используйте время, которое должно быть выделено на разработку функции.
• Добавьте произвольный код в ветку, которая, если функция не завершена, не может быть объединена с основным продуктом. Точно так же, если я откатю функцию, я потеряю рефакторинг.

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

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

Цель branchтипов состоит в том, чтобы обеспечить намерение обращаться с ними. Если вы придерживаетесь стиля ветвления в GitFlow, то, скорее всего, у вас есть такие типы, как feature, hotfixи releaseт. Д. В случае ветки объектов ее намерением является инкапсуляция слияния в другую ветвь (т.е. develop), которая показывает разработчика, ответственного за Слияние, что это за функция. Если код, который вы очищаете, не является частью этой функции, не меняйте его.

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

Вот довольно хорошее объяснение различных стратегий: https://www.atlassian.com/git/tutorials/comparing-workflows/

если я работаю над веткой функций и обнаруживаю некрасивый код, я должен это исправить?

Вероятно, можно исправить «некрасивый код» на месте, в зависимости от темпа проекта, «уродливости» кода и т. Д., Но старайтесь не делать этого в самой ветви функций.

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

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

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