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

Question

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

И, конечно, у меня есть свой собственный компьютер с десятками файлов в состоянии "в процессе выполнения".

Часто мне нужно создать свое приложение только с одним изменением на месте.Например, я закончил задачу ABC, и я хочу создать EXE-файл с Только это изменение.

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

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

@Мэтт би:Итак, пока вы ждете отзывов о ваших изменениях, что вы делаете?Вы всегда работаете только над чем-то одним?

Answer 1

Итак, вы спрашиваете, как справиться с работой над несколькими "задачами" одновременно, не так ли?Кроме ветвления.

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

Смешивание нескольких задач в одной рабочей копии / фиксации может привести к большой путанице, особенно если кому-то понадобится просмотреть вашу работу позже.

Answer 2

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

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

Answer 3

Что - то в этом роде:git stash && ./bootstrap.sh && делать тесты :)

Answer 4

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

Когда это сделано хорошо, вы получаете ряд преимуществ:

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

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

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

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