Должен ли временный код находиться под контролем версий и как?

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

1. Файлы проекта. Пути, возможно, должны быть отредактированы, чтобы отразить расположение на текущем ПК.
2. Makefiles. Например, оптимизация может потребоваться отключить во время отладки, но не для CI-сервера.
3. Грязные уродливые хаки. Например, return 7в середине функции, чтобы протестировать что-либо, в зависимости от функции, и предположительно сломаться при значении 7. Или 7 - это код еще не реализованной кнопки, которую я внедряю и которую нужно тестировать на протяжении всего жизнь моей ветки.

Я попытался сохранить те в git commit, которые я всегда перебрасываю наверх, прежде чем нажать на репо, а затем нажать HEAD~. Это довольно неудобно и не работает с SVN. Скрытность пугает меня еще больше - «я помню всплывающие после нажатия ??».

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

Что было бы разумным решением для такого одноразового кода?

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

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

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

PS. Действительно временные файлы (например, .obj или артефакты сборки) не имеют места в вашем SCM. Это вещи, которые ни для кого не имеют значения. Вы можете сказать, что они - если вы удалите их, вы не возражаете, или даже заметите, что они ушли.

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

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

Makefiles. Например, оптимизация может потребоваться отключить во время отладки, но не для CI-сервера.

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

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

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

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

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

Это значит, что:

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

• Локальные файлы, относящиеся к конкретной машине, могут храниться в ветке.

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

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

  Следите за возможностью устранить особенности между машинами. Это может означать:

  • Предоставление доступа к dev-серверу SQL для замены локальных экземпляров на машинах разработчиков,

  • Использование служб распространения пакетов, таких как Pypi или npm для общедоступных пакетов и их частных аналогов для внутренних пакетов,

  • Попросите членов команды установить те же версии программного обеспечения,

  • Сделать обновления программного обеспечения максимально прозрачными,

  • Или сделайте возможным развертывание ОС и необходимого программного обеспечения на компьютере одним щелчком мыши (плюс время для каждого разработчика, чтобы установить свой предпочтительный Vim против Emacs, Chrome против Firefox и т. Д.)

Так:

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

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

Пример:

В проекте, созданном с помощью Visual Studio, вы можете найти:

• Сами файлы. Пути относительны, не имеет значения, находится ли на моей машине проект, в H:\Development\Hello World Project\то время как другие члены команды проверяли проект C:\Work\HelloWorld\.

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

  Обратите внимание, что крайне важно также хранить собственные библиотеки в частном NuGet. Наличие нескольких библиотек, хранящихся в общей папке или отправленных по электронной почте в рамках группы, приводит к анархии и депрессивным CI-серверам.

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

• Настройки утилит. Это сложно, потому что некоторые члены команды, возможно, установили некоторые утилиты, а другие нет.

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

Makefiles. Например, оптимизация может потребоваться отключить во время отладки, но не для CI-сервера.

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

Грязные уродливые хаки. Например, верните 7 в середине функции, чтобы протестировать что-либо, в зависимости от функции, и предположительно сломаться при значении 7.

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

Как вы описываете это, вы должны написать тест. Например, если вы хотите быть уверены, что:

class TemperatureConverter
{
    public int CelsiusToFahrenheit(int temperature)
    {
        ...
    }
}

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

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

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

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

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

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

В качестве дополнительного преимущества эти задачи (обычно мелочи) всегда присутствуют в коде. Разработчик, работающий над ними, может быстро обойти их, и нет необходимости вести отдельные списки.
Вы знаете, как идет разработка: вы работаете в одном месте, но вы постоянно используете свой ум в качестве стека (« Я должен изменить это там, когда я закончу здесь »). Просто сделав краткое @@замечание, вы избежите переполнения стека.

Я даже использую @@nameдля обозначения вопросов, которые мне нужно обсудить с «именем».

2 решения HAMSTER:

• Вы можете использовать ловушку перед фиксацией, чтобы проверить код на наличие необычного ключевого слова, такого как HAMSTER. Только не позволяйте людям фиксировать код, который был ХАМСТЕР, и использовать его всякий раз, когда вы делаете грязные хаки.

• Другой вариант, например, в C - использовать #ifdef HAMSTER, тогда код будет работать только на вашей машине, где у вас есть флаг компилятора HAMSTER.

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

Это относится даже к шипам http://www.extremeprogramming.org/rules/spike.html , как те, которые вы описали; мы просто размещаем их в другом поддереве.

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

1. Легкие ветви, которые можно сдавить.

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

2. Используйте очередь патчей поверх вашего SCM.

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

3. использование RCS в качестве внеполосного СКМ для небольших экспериментов.

   Иногда вы просто хотите проверить доступ к файлу одноразовым способом без необходимости впоследствии очищать историю. Я обычно использую RCS для этого внутри Git или SVN. Я говорю Git игнорировать артефакты RCS, проверять мою работу в RCS и, когда мне нравятся результаты, я просто бросаю*,v файлы или весь каталог RCS. Просто не запускайте git clean -fdxи т.п., пока не посвятите свою работу своему «настоящему» СКМ, или вы пожалеете об этом.

4. Именные тайники.

   Другой Гитизм, но удобный: git stash save --include-untracked <some-cool-title>может быть полезен в крайнем случае. Таким способом вы можете сохранять, извлекать и применять текущую работу, а также просматривать различные контрольные точки через git stash listили git reflog --all. Другие SCM могут иметь аналогичные функции, но ваш пробег может сильно отличаться от этого.

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

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

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

Я считаю, что некоторые системы будут выдавать предупреждения о появлении TODO в комментарии, поэтому

// TODO: remove this hack.

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

Это проще, чем организовывать ваш код определенным образом и надеяться, что люди будут помнить, чтобы он не использовался. Это также делает более безопасным следовать советам @gbjbaanb (если вы можете убедиться, что все видят предупреждения!).

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

Никогда не вредно помещать код в систему контроля версий.

Каждый из упомянутых вами предметов должен находиться в системе контроля версий.