Параллельный Dev: разработчики должны работать в рамках того же ответвления?
Несколько разработчиков должны работать в рамках того же ответвления, и обновление - изменяет - фиксация? Или у каждого разработчика должно быть его собственное каждое ответвление исключительно? И как совместное использование ответвлений повлияло бы на среду, где Вы делаете регламентное техобслуживание в противоположность несохраняемым потокам кода? Кроме того, как это работало бы при развертывании каждого, разработчики работают, как только это сделано и тестирование передач (быстро, в противоположность помещению всей их работы в единственный выпуск).
4 ответа
В общем, я обнаружил, что разработчики ( которые работают над одним и тем же проектом), используйте одну и ту же ветку, чтобы быстрее найти проблемы интеграции. Если каждый разработчик использует отдельную ветвь, то вы просто откладываете возможные проблемы интеграции на потом, когда объедините ветки.
Конечно, наличие разработчиков, работающих в одной ветке, означает, что вам необходимо иметь реальную связь между этими разработчиками, но это социальная проблема, а не техническая.
Разработчики будут работать над отдельными ветвями, когда есть веская причина для того, чтобы эта ветка существовала в первую очередь (например, выпуск исправлений для предыдущей версии программного обеспечения или специальная сборка для конкретного клиента).
Обратите внимание, что такие инструменты, как Git и Mercurial, позволяют разработчикам легко создавать свои собственные частные ветки для организации своей работы. Это отличается от ситуации, когда несколько разработчиков используют ветку, и следует поощрять (обычно недолговечные) частные ветки.
В некоторой степени, программное обеспечение для контроля версий, которое вы , которые вы используете, подтолкнет вас к определенному подходу. GIT ориентирован на участников с открытым исходным кодом и напоминает модель «одного разработчика» (ветвление даже не является концепцией GIT. GIT больше касается управления изменениями). Clearcase более корпоративен, поэтому у вас действительно есть несколько разработчиков в ветке, но каждый разработчик может играть в своем собственном представлении.
Я согласен с ответом Грега, это скорее проблема социального планирования. Многие разработчики на одной ветке будут наступать друг другу на пятки. Я был в проекте, где разработчиков было больше, чем отдельных исходных файлов :)
Ветви предназначены для управления версиями любой функции или экспериментальный фрагмент кода, который может нарушить работу mainline / trunk.
В то время как разработчики обычно имеют свои собственные личные ветки для глубоких экспериментов, часто ветки сосредоточены вокруг добавляемой новой функции. Эти новые функции часто требуют, чтобы их выполняло более одного человека.
Например, в веб-проекте два разработчика и дизайнер могут обновлять веб-сайт своей компании. Им по-прежнему необходимо содержать в чистоте свой основной / магистральный код на случай, если им потребуется внести в него быстрые изменения до завершения фейслифтинга. Поэтому они создают ветку «подтяжки лица» и вместо этого работают над этим. Пока разработчики фиксируют javascript, дизайнер может фиксировать CSS и изображения. Как только функция фейслифтинга будет завершена, они могут объединить ее с основной линией и отправить вживую.
Единственная причина, по которой кому-либо из них понадобятся личные ветки, - это эксперименты. Возможно, дизайнер пытается реализовать вкладки типа «раздвижная дверь» и, например, не может правильно настроить отступы в IE6. Если он решит проблему, он может объединить ее в ветку подтяжки лица, если не может, он просто игнорирует ее и продолжает остальную часть дизайна обратно в ветку подтяжки лица.
Я думаю, что слияние ветвей может быть проблематичным (выпадение или непоследовательная функциональность), независимо от того, насколько хороши инструменты контроля исходного кода. Я бы охотнее выбрал вариант, когда несколько разработчиков работают над одной основной веткой. Могут быть и другие ветки для таких вещей, как исправления ошибок на производстве или пробные версии (POC), где слияние может/должно произойти очень скоро после изменения (исправления ошибок) или велика вероятность, что слияние может и не понадобиться (POC).