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

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

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

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

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

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

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

Ответы [ 4 ]

2 голосов
/ 10 сентября 2008

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

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

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

0 голосов
/ 14 сентября 2008

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

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

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

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

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

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

0 голосов
/ 10 сентября 2008

Примерно так: git stash && ./bootstrap.sh && make tests:)

0 голосов
/ 10 сентября 2008

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

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...