В каких случаях требуется создание отдельной ветви в репозитории?
Встречал разные рекомендации, например:
• Rule 1: The trunk branch must compile and pass regression tests at all times.
• Rule 2: A single commit must represent an entire changeset, and must not be so large to discourage peer-review.
• Rule 3: If rules 1 and 2 are in conflict, create a private branch.
Или:
• Always maintain a private branch for each developer or change.
Или:
• branches for maintenance,
• feature development isolation,
• integration,
• golden releases,
• release candidates,
• private workspaces,
• experimentation features,
• and more.
А вы для каких случаев создаёте отдельные ветви? Какой длины? Как часто синхронизируетесь с транком? Создаёте ли отдельный репозиторий (в случае DVCS)? Удаляете ли ветви после вливания в транк? Возникают ли проблемы независимой поддержки параллельных ветвей? Используете ли плагины и расширения системы контроля версий для наглядной визуализации топологии ветвления?
И вопрос, ради которого затевался топик: какие соглашения об именовании ветвей используете? Включаете ли версию, дату, имя разработчика, название фичи? Пробелы, точки, дефисы, CamelCasing? Какие есть naming best bractises?
Также очень рекомендую Practical Perforce (книга, платная, но... можно найти).
Мы работаем с Perforce, поэтому все ответы могут быть специфичны для этой SCM, или только для SCM с централизованным репозиторием.
Видимая мне часть репозитория ~60000 файлов; так или иначе работаем с подмножеством ~1000-2500 файлов (посчитать сложно )
Q>А вы для каких случаев создаёте отдельные ветви?
Для работы над экспериментальными фичами; длительными рефакторингами; просто над крупными кусками функциональности, при работе над которыми удобно часто коммитить в разрез с policy родительской ветки.
Q>Какой длины?
Не понял.
Q>Как часто синхронизируетесь с транком?
Trunk -> Branch — как можно чаще
Trunk <- Branch — в точках стабильности Branch (т.е. в таких, где код в Branch удовлетворяет policy Trunk; всё как в учебнике)
Q>Создаёте ли отдельный репозиторий (в случае DVCS)?
(Неприменимо)
Q>Удаляете ли ветви после вливания в транк?
Обычно нет.
Q>Возникают ли проблемы независимой поддержки параллельных ветвей?
Редко.
Q>Используете ли плагины и расширения системы контроля версий для наглядной визуализации топологии ветвления?
Здравствуйте, Qbit86, Вы писали:
Q>В каких случаях требуется создание отдельной ветви в репозитории?
Когда страшно в основную ветвь коммитить, но и не коммитить тоже страшно, чтобы не потерять.
Q>И вопрос, ради которого затевался топик: какие соглашения об именовании ветвей используете? Включаете ли версию, дату, имя разработчика, название фичи? Пробелы, точки, дефисы, CamelCasing? Какие есть naming best bractises?
Любая практика хороша если 1) по имени бранча можно понять, что это такое 2) имена используются консистентно
Здравствуйте, Qbit86, Вы писали:
Q>Добрый вечер, уважаемые коллеги!
Q>А вы для каких случаев создаёте отдельные ветви? Какой длины? Как часто синхронизируетесь с транком? Создаёте ли отдельный репозиторий (в случае DVCS)? Удаляете ли ветви после вливания в транк? Возникают ли проблемы независимой поддержки параллельных ветвей? Используете ли плагины и расширения системы контроля версий для наглядной визуализации топологии ветвления?
Q>И вопрос, ради которого затевался топик: какие соглашения об именовании ветвей используете? Включаете ли версию, дату, имя разработчика, название фичи? Пробелы, точки, дефисы, CamelCasing? Какие есть naming best bractises?
Здравствуйте, Qbit86, Вы писали:
Q>А вы для каких случаев создаёте отдельные ветви? Какой длины? Как часто синхронизируетесь с транком? Создаёте ли отдельный репозиторий (в случае DVCS)? Удаляете ли ветви после вливания в транк? Возникают ли проблемы независимой поддержки параллельных ветвей? Используете ли плагины и расширения системы контроля версий для наглядной визуализации топологии ветвления?
Могу рассказать как это организованно у нас. Все разработка ведется в транке. Что, кстати, совершенно не отменяет того факта что код в транке большую часть времени компилируется и проходит тесты. После каждого отгруженного релиза создается ветвь со стандартным именем вида release_19.260.17.18327. Если требуется поддержка именно этой версии в эту ветвь вносятся изменения. И сразу же эта ветвь мержится с транком. Ни в каких других случаях ветви не создаются. ИМХО, оверхед на мердж ветвей превышает все преимущества от из использования. В будущем планируем переходить на DVCS. Скорее всего это приведет к тому, что на новые фичи разработчики будут создавать локальные ветки, которые будут мерджится в транк по завершении работ. Теоретически это уменьшит количество мерждей и улучшит качество кода в транке.
Я встречал попытки более широко использовать бранчи, но они всегда приводили к одному из двух результатов: либо к большому оверхеду на войну с VCS либо к бардаку. В клинических случаях приходилось даже держать целую интеграционную команду, которая только и занималась тем что мерджила сотни веток в один продукт.
Здравствуйте, Miroff, Вы писали:
M> В клинических случаях приходилось даже держать целую интеграционную команду, которая только и занималась тем что мерджила сотни веток в один продукт.
Хммм.... По твоему, это плохо? Есть релизная ветка, есть десятки разработчиков и под сотню изменений... как, по-твоему, обойтись без выденной команды или хотя бы человека, который бы брал на себя интеграцию?
Кто будет мержить на релизную ветку? Девелоперы? Им делать больше нечего, как сращивать свои изменения с сотней таких же как он?
Я вот работал в такой команде — и именно интегратором. В ситуации, когда одна релизная ветка и десятки единовременных изменений для неё — без интеграторов нельзя обойтись. Используй ты хоть бы даже и DVCS — ситуация будет та же, изменения на релизную ветку должны вноситься централизованным и контролируемым образом, иначе действительно будет бардак в мёржах и в качестве полученного продукта.
Здравствуйте, Miroff, Вы писали:
M>Могу рассказать как это организованно у нас. Все разработка ведется в транке. Что, кстати, совершенно не отменяет того факта что код в транке большую часть времени компилируется и проходит тесты.
Но ставит крест на стратегии «commit often». Ходишь, как по минному полю; шаг влево, шаг вправо — и локальные изменения утеряны. Например, при апдейте, мерджевании и ошибке в разруливании конфликтов.
M>После каждого отгруженного релиза создается ветвь со стандартным именем вида release_19.260.17.18327. Если требуется поддержка именно этой версии в эту ветвь вносятся изменения. И сразу же эта ветвь мержится с транком.
При этом же приходится пересоздавать ветвь? В том смысле, что при «reintegrate branch into trunk» ветку надо закрывать, согласно рекомендациям svn-book'а. Если её продолжать, то могут быть проблемы с синхронизацией с транком.
Кстати, а почему для этих целей создаётся ветвь, а не тэг? (Впрочем, в Subversion это одно и то же.)
По какому принципу строится номер 19.260.17.18327? Он генерируется автоматически или прописывается руками согласно какому-то соглашению?
Здравствуйте, Qbit86, Вы писали:
M>>После каждого отгруженного релиза создается ветвь со стандартным именем вида release_19.260.17.18327. Если требуется поддержка именно этой версии в эту ветвь вносятся изменения. И сразу же эта ветвь мержится с транком.
Q>При этом же приходится пересоздавать ветвь? В том смысле, что при «reintegrate branch into trunk» ветку надо закрывать, согласно рекомендациям svn-book'а. Если её продолжать, то могут быть проблемы с синхронизацией с транком.
Это личные интимные проблемы svn
Q>Кстати, а почему для этих целей создаётся ветвь, а не тэг? (Впрочем, в Subversion это одно и то же.)
Потому что в процессе тестирования релиза может возникать необходимость фиксить баги в релизной ветке, не прекращая коммитить фичи в транк.
Здравствуйте, Qbit86, Вы писали: Q>Добрый вечер, уважаемые коллеги! Q>А вы для каких случаев создаёте отдельные ветви?
Если фича: долгая/ломающая/ее делают несколько человек/нужно иметь возможность собрать проект без нее — то ветка. Ну по сути — что-то вроде первой пары правил.
Q>Какой длины?
В каких единицах?
Q>Как часто синхронизируетесь с транком?
Из транка в ветку почаще, из ветки в транк — когда фича более-менее готова. Далее фича докручивается уже в транке.
Q>Удаляете ли ветви после вливания в транк?
Да, svn же.
Q>Возникают ли проблемы независимой поддержки параллельных ветвей?
Да, бывало. На мой взгляд, типичные источники проблем:
— В бранче было сделано нечто, не относящееся непосредственно к реализуемой в нем фиче.
— Фичи, вынесенные в разные бранчи, оказались связаны между собой.
Q>Используете ли плагины и расширения системы контроля версий для наглядной визуализации топологии ветвления?
Пока не было необходимости.
Q>И вопрос, ради которого затевался топик: какие соглашения об именовании ветвей используете?
Обычно пара слов, кратко обозначающая назначение.
Здравствуйте, Qbit86, Вы писали:
Q>Но ставит крест на стратегии «commit often». Ходишь, как по минному полю; шаг влево, шаг вправо — и локальные изменения утеряны. Например, при апдейте, мерджевании и ошибке в разруливании конфликтов.
Во-первых, не ставит. Разбивайте задачу на мелкие фичи которые можно комиттить. Заодно и управляемость проекта повысится. Во-вторых, современные IDE умеют хранить локальную историю без всяких VCS. В-третьих, разбивайте проект на отдельные независимые модули и проблем с мерджем будет в разы меньше.
Q>При этом же приходится пересоздавать ветвь? В том смысле, что при «reintegrate branch into trunk» ветку надо закрывать, согласно рекомендациям svn-book'а. Если её продолжать, то могут быть проблемы с синхронизацией с транком.
Сугубо проблемы SVN, да. Честно говоря, ни разу не сталкивался.
Q>Кстати, а почему для этих целей создаётся ветвь, а не тэг? (Впрочем, в Subversion это одно и то же.)
Потому что в этот бранч наверняка пойдут изменения, в том числе и локальные фиксы, которые по разным причинам не должны попасть в транк.
Q>По какому принципу строится номер 19.260.17.18327? Он генерируется автоматически или прописывается руками согласно какому-то соглашению?
Банальный номер версии. major.minor.hotfix.build Интересует как номера версиям назначать?
Здравствуйте, Miroff, Вы писали:
Q>>Но ставит крест на стратегии «commit often». Ходишь, как по минному полю; шаг влево, шаг вправо — и локальные изменения утеряны. Например, при апдейте, мерджевании и ошибке в разруливании конфликтов.
M>Во-первых, не ставит. Разбивайте задачу на мелкие фичи которые можно комиттить.
Не-не-не, так нельзя. «Коммит» выполняет функции кнопки «Save» в редакторах. Она всегда должна быть доступна, причём быстро, сохранение не должно быть многоэтапным. Сделал коммит, и ушёл домой. Сделал коммит, и приступаешь к рискованным операциям в рабочей папке. Сделал коммит — и спишь спокойно.
Но в случае работы в транке, «Коммит» оказывается перегруженным, он выполняет ещё и функцию publishing'а кода. Со всеми вытекающими. Даже в случаях «мелких фич» быстрый комит уже сделать нельзя. Приходится делать апдейт, мерджить, разруливать конфликты — высокий риск потери незакоммиченных («несохранённых») данных. Если коммит прошёл гладко, то всё равно надо дожидаться отклика CI-сервера, прогона тестов, инспекции кода.
Быстрые коммиты становятся невозможны.
M>Заодно и управляемость проекта повысится.
Это не управляемость. Это лишние, внешние, искусственные ограничения — учитывать ещё и гранулярность коммитов.
M>Во-вторых, современные IDE умеют хранить локальную историю без всяких VCS.
Как правило, эта история неглубока. Плюс пока что IDE не научились запоминать историю модификации файловой иерархии. На то есть системы контроля версий.
Q>>По какому принципу строится номер 19.260.17.18327? Он генерируется автоматически или прописывается руками согласно какому-то соглашению?
M>Банальный номер версии. major.minor.hotfix.build Интересует как номера версиям назначать?
Да, если не сложно. Это, наверное, ортогонально топику, но тем не менее.
Здравствуйте, Qbit86, Вы писали:
Q>Не-не-не, так нельзя. «Коммит» выполняет функции кнопки «Save» в редакторах. Она всегда должна быть доступна, причём быстро, сохранение не должно быть многоэтапным. Сделал коммит, и ушёл домой. Сделал коммит, и приступаешь к рискованным операциям в рабочей папке. Сделал коммит — и спишь спокойно.
Ну все-таки не совсем. Коммит должен вносить осмысленные изменения в код. Не "доработал до вечера и пошел спать", а "сделал фичу XXX" или "починил багу YYY". Иначе вы используете систему контроля версий просто в качестве бакапа, и не имеете осмысленной истории изменений.
Q>Но в случае работы в транке, «Коммит» оказывается перегруженным, он выполняет ещё и функцию publishing'а кода. Со всеми вытекающими. Даже в случаях «мелких фич» быстрый комит уже сделать нельзя. Приходится делать апдейт, мерджить, разруливать конфликты — высокий риск потери незакоммиченных («несохранённых») данных. Если коммит прошёл гладко, то всё равно надо дожидаться отклика CI-сервера, прогона тестов, инспекции кода.
Это значит, что у вас слишком много бюрократии в текущей ветке. Разработчики должны свободно коммитить в текущую ветку при условии, что они предпринимают разумное количество усилий не сломать программу. Т.е., как минимум, перед коммитом надо убедиться в том, что программа собирается, и если изменения затрагивают уже работающий код, хоть слегка его оттестировать.
Здравствуйте, Pzz, Вы писали:
Pzz>Ну все-таки не совсем. Коммит должен вносить осмысленные изменения в код. Не "доработал до вечера и пошел спать", а "сделал фичу XXX" или "починил багу YYY". Иначе вы используете систему контроля версий просто в качестве бакапа, и не имеете осмысленной истории изменений.
«Сделанная фича» может быть на разных уровнях готовности. Между «собирается и вроде как работает» и «вычищена так, что FxCop носа не подточит» может пролегать много времени. Запрет не коммит до выполнение этих задач — это как запрет автору статьи нажимать Save в Word'е, пока текст не прочитает корректор. Вы предлагаете, перед уходом работы не сохранять рабочую копию? Я не хочу так рисковать дневными наработками.
Q>>Но в случае работы в транке, «Коммит» оказывается перегруженным, он выполняет ещё и функцию publishing'а кода. Со всеми вытекающими. Даже в случаях «мелких фич» быстрый комит уже сделать нельзя. Приходится делать апдейт, мерджить, разруливать конфликты — высокий риск потери незакоммиченных («несохранённых») данных. Если коммит прошёл гладко, то всё равно надо дожидаться отклика CI-сервера, прогона тестов, инспекции кода.
Pzz>Это значит, что у вас слишком много бюрократии в текущей ветке. Разработчики должны свободно коммитить в текущую ветку при условии, что они предпринимают разумное количество усилий не сломать программу. Т.е., как минимум, перед коммитом надо убедиться в том, что программа собирается, и если изменения затрагивают уже работающий код, хоть слегка его оттестировать.
В изолированной ветке разработчика бюрократии нет, она прикручена только к транку. Но при желании допустимо прикрутить бюрократию к какой-нибудь feature branch. И это называется не бюрократия, а планка качества.
Pzz>...при условии, что они предпринимают разумное количество усилий не сломать программу. Т.е., как минимум, перед коммитом надо убедиться в том, что программа собирается, и если изменения затрагивают уже работающий код, хоть слегка его оттестировать.
«Убеждаться» должна машина. Проверка условий должна выполняться автоматически. Как я могу доверить коллегам не забывать следить за качеством их кода, если я не доверяю даже себе?
Здравствуйте, Qbit86, Вы писали:
Q>В изолированной ветке разработчика бюрократии нет, она прикручена только к транку. Но при желании допустимо прикрутить бюрократию к какой-нибудь feature branch. И это называется не бюрократия, а планка качества.
А расскажи тогда, как при такой концепции разруливается ситуация исключающих друг друга изменений одних интерфейсов в двух бранчах? Вот, например, есть у тебя 5-6 тесно связанных проектов (и в каждом — несколько поддерживаемых версий), использующих несколько десятков общих библиотек. И вот в двух проектах в head'е branch'а в интерфейсы одной (а лучше — двух-трёх) библиотек вностятся противоречащие друг другу изменения. И там и там в итоге имеется нехилый профит в функциональности — все довольны... до момента, когда это всё надо слить в trunk.
ЗЫ. В случае разработки в транке такая ситуация разруливается автоматически — кто первый закоммитил — того и тапки. Причём в 99% случаев такой конфликт обнаружится на раннем этапе — при первой же попытке коммита второго изменения.
Курица — это инструмент, с помощью которого одно яйцо производит другие.
Здравствуйте, frogkiller, Вы писали:
F>ЗЫ. В случае разработки в транке такая ситуация разруливается автоматически — кто первый закоммитил — того и тапки. F>Причём в 99% случаев такой конфликт обнаружится на раннем этапе — при первой же попытке коммита второго изменения.
Ну и чем, в указанном тобой смысле, отличается «апдейт/коммит» от «синхронизация бранча с транком/синхронизация транка с бранчем»?
F>А расскажи тогда, как при такой концепции разруливается ситуация исключающих друг друга изменений одних интерфейсов в двух бранчах?
Во-первых, изменения интерфейсов (как наиболее уязвимых частей библиотеки, см. пункт Abstractions) всегда должны продумываться и согласовываться до внесения ломающих изменений.
Во-вторых, разруливаются примерно так же, как и при наличии исключающих друг друга изменений в разных рабочих копиях разных разработчиков при работе с единственным транком. В литературе по VCS такая штатная ситуация называется «Конфликт». Странно, что ты не слышал.
F>И там и там в итоге имеется нехилый профит в функциональности — все довольны... до момента, когда это всё надо слить в trunk.
Нет. Проблемы всплывут не во время вливания brahch→trunk, а во время синхронизации trunk→brahch. Последнее рекомендуется делать как можно чаще.
Здравствуйте, Qbit86, Вы писали: Q>Не-не-не, так нельзя. «Коммит» выполняет функции кнопки «Save» в редакторах. Она всегда должна быть доступна, причём быстро, сохранение не должно быть многоэтапным. Сделал коммит, и ушёл домой. Сделал коммит, и приступаешь к рискованным операциям в рабочей папке. Сделал коммит — и спишь спокойно.
Ну да, по идее, как-то так, поэтому когда делать коммит в ветку становится опасно, все необходимые разработчики переезжают в отдельную. Получается, что с веткой ассоциируется некий ожидаемый уровень качества.
Q>Но в случае работы в транке, «Коммит» оказывается перегруженным, он выполняет ещё и функцию publishing'а кода.
Ну если в ветке работают несколько разработчиков, то паблишинг все равно имеет место же.
Q>Со всеми вытекающими. Даже в случаях «мелких фич» быстрый комит уже сделать нельзя. Приходится делать апдейт, мерджить, разруливать конфликты — высокий риск потери незакоммиченных («несохранённых») данных. Если коммит прошёл гладко, то всё равно надо дожидаться отклика CI-сервера, прогона тестов, инспекции кода.
Тут, полагаю, опять же играет роль ожидаемый уровень качества.
Здравствуйте, Mr.Cat, Вы писали:
Q>>Но в случае работы в транке, «Коммит» оказывается перегруженным, он выполняет ещё и функцию publishing'а кода. MC>Ну если в ветке работают несколько разработчиков, то паблишинг все равно имеет место же.
Ветки могут использоваться как с целью sharing, так и с целью isolation. Т.е. если в ветке работают несколько разработчиков (feature branch) и возникают проблемы, то всегда можно создать подветки, изолирующие каждого разработчика (workspace branch). Причём изолируют в одну сторону: изменения из родительской ветки в дочернюю должны сливаться как можно чаще, а обратно — по достижению «полноты и непротиворечивости». Разумеется, это всё сложновато, ещё сложнее физически запретить одному разработчику апдейтить изолированную ветку другого. Не знаю даже, можно ли в Subversion раздавать разные права на разные подветки файловой иерархии (а бранчи в Svn являются не более чем ветками в файловой иерархии).
Это как раз является одной из причин, по которым я агитирую свою контору на миграцию с Subversion на Mercurial. Там политика бранчевания может использовать два механизма ветвления — клоны репозитория и именованные бранчи.
MC>Тут, полагаю, опять же играет роль ожидаемый уровень качества.
Уровень качества высокий :) Недавно поднимал рядом ветку
На главной ветке никакой разработки нету.
Там только стабильные, оттестированные версии.
Как только начинается проект, делаем отдельную ветку на проект.
Далее смотрим какие фичи планируется реализовать.
Фичи группируем так, чтобы их можно было реализовывать относительно параллельно и независимо.
Для каждой такой группы фич создается ветка.
Каждый девелопер, работающий над группой фич, создает свою ветку и работает только в ней.
Т.е. в итоге получается иерархия из 4-х веток:
* главная ветка
** ветка проекта
*** ветка группы фич (по одной ветке на группы)
**** личная ветка разработчика
Синхронизация с родительских веток в дочерние происходит как можно чаще.
Из дочерних в родительские — как только достигается стабильность в дочерней ветке.
Т.е. если девелопер видит, что у него все стабильно,
то он может смерджить свою часть в родительскую ветку группы фич.
Если группа фич достигла стабильности, то ее можно смерджить в ветку проекта.
Прежде чем мерджить что-то с дочерних веток в родительские обязательно нужно
все смерджить все с родительской ветки в дочернюю.
На всех ветках для группы фич настроен "ночной билд" с запуском всех тестов.
Несмотря на кажущееся обилие мерджей, оверхед минимальный.
Работает это все дело только потому что заранее планируются версии продукта и
фичи, которые планируются реализовать.
)
