Как я могу управлять слиянием обновлений от нескольких разработчиков? - PullRequest
Новая
       33

Как я могу управлять слиянием обновлений от нескольких разработчиков?

3 голосов
/ 31 июля 2009

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

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

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

Ответы [ 2 ]

4 голосов
/ 31 июля 2009

Этот вопрос не имеет никакого отношения к DVCS или нет. Это проблема ПРОЦЕССА, а не проблема технологии. Вот мой взгляд на то, что делают многие люди, и процесс, который продвигает ClearCase UCM: 

/project/trunk 
        /branches 
            /release-1.0-JIRA1023
            /release-1.0-darthcoder-JIRA1029 
            /darthcoder-JIRA1029

        /branches/release-1.0-tfix   <- This is the patch trunk.  Main trunk is future dev

Когда я исправлю свою ошибку, я переведу ее обратно в транк или в конкретную версию, которую пытаюсь исправить. Я объединюсь с release-1.0-tfix и транком, потому что это нужно исправить в нескольких местах. Когда я закончу, я удаляю ветку и перехожу к следующему вопросу. Поэтому у меня есть две ветви кода с исправлением JIRA, пока я тестирую его и работаю над проблемами (если исправление сильно отличается).

Но ничто не продвигается к стволам или деревьям -tfix, если не выполняется успешный цикл сборки / тестирования, и у него есть свойство JIRA для отслеживания. Таким образом, вы можете привязать каждое отдельное исправление к разработчику и ветви и убедиться, что все исправлено правильно. Кроме того, эти проблемы не теряются (о, JIRA1029 сделал это в версии 1.2? Ну, вы можете проверить это, посмотрев JIRA1029 в своем хранилище. Вам никогда не придется GUESS, и это делает разработку программного обеспечения повторяемой и приближает нас к ошибкам == 0.

0 голосов
/ 31 июля 2009

Вы работаете над параллельными выпусками? Для всех моих проектов, в которых нет параллельной разработки релизов (обычно <10 разработчиков), мы работаем в транке. Один заезд должен применяться только к одному билету. Если случится исправить еще один тикет, тикет обновляется и помечается для проверки. </p>

Почему вы сливаетесь? Это ваш обзор кода или ваш способ убедиться, что сборка не сломана. Я лично настроил бы некоторую непрерывную интеграцию и пропустил бы этот шаг. Вы должны быть в состоянии доверять своим разработчикам, чтобы они не ломали сборку и чтобы CI их ловил, если они это делают.

...